Check Point to Sonic Wall VPN tunnel

10 03 2013

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.

Advertisements




Check Point Learning materials

3 03 2013

Had to give a mention to eLearnCheckPoint – I’ve been trying for ages to find a decent Check Point book, but this is easier said than done.

The EBooks available on this site have quality, up-to-date info (R75.20 at the time of writing), and are incredibly good value for money, well worth it.





Checkpoint policy pushes

20 08 2012

Noticed a weird issue on one of my Checkpoint clusters. Policy pushes to one of the involved clusters would result in an outage of the VPN tunnel between two locations. I’d had similar, but not identical symptoms, before. Pushing to the other involved cluster didn’t have the same effect. Nothing had changed on an appliance level, but policy changes had been made; all changes were recorded in a change log.

Found that this was caused by my enthusiastic Business Continuity efforts – I’d filled the /opt directory to 79% as a result of not deleting “upgrade_export” files after shipping them off to a backup server. Removing these files (they had been backed up to said server straight after generation, but not deleted from the manager) resulted in successful policy pushes that didn’t cause tunnel outages.