Jims' Network Diary – musings of a network admin

Had an issue recently with a VPN tunnel from my Check Point cluster to a Sonic Wall device, not managed by me.

I have quite a few tunnels to Sonic Walls and most of the time they work just fine.. the issues we’ve had with them have been related to the troublesome SG82 devices I’ve written about previously, which were replaced with Check Point 4207s.

However in this instance, despite using the same VPN Community, I couldn’t get the tunnels to come up.

A check on Smartview Tracker showed that although the outbound IKE packets were going to the configured address from the Check Points, they were being returned from another address. The Check Points were Rejecting these packets.

This turned out to be another interface on the same device. Changing the properties of the Interoperable Device to reflect the IP address the device was replying from didn’t work.

The fix was to define another IP address in the topology of the Interoperable Device. I used the IP address as the ‘Name’, and ‘IP address’ fields, and although I could have asked, I used a whois query to determine what the subnet mask of the public IP block that this second IP address belonged to was, and used that for the subnet mask value.

Doing this immediately granted IP access to the subnets at the other end.