I setup quite a few IPSEC site-to-site VPNs. Hundreds maybe. Most go fine. 10 minutes on the line, bing, bam boom, we have a working IPSEC tunnel.
My company uses Cisco router/ASRs for our termination points for IPSEC VPNs. We also have Checkpoint firewalls doing the filtering. Why the separation? Because we love a good headache.
My biggest headache comes from when a third party is using a Checkpoint firewall as the VPN termination point and I am using my Cisco router. Checkpoint firewalls, often by default, will super-net the encryption domain. So, I might be using a /32 host ACL on my Cisco, the Checkpoint is sending a /24 or larger ACL. This does not play well in Cisco land and Phase 2 usually fails.
The hard part with this is figuring out this is happening, because it’s not obvious. What I have found is turning on a single debug command makes all the difference in the world.
debug crypto ipsec
This shows all kinds of nasty IPSEC messages when a tunnel is negotiating. You try finding the error on a box that has 75 tunnels terminating on it. It is not easy! But, as the debug messages are scrolling by, one little entry can give you all the help you need:
Feb 1 17:20:39: Crypto mapdb : proxy_match
src addr : 18.104.22.168
dst addr : 22.214.171.124/25
protocol : 0
src port : 0
dst port : 0
On this particular tunnel (IPs changed to protect the innocent) the third party was supposed to be NATing behind a /32 address on the 126.96.36.199 network. But, his Checkpoint box was super-netting behind the /25 network. Bad Checkpoint.
I was able to pick it up from that debug message and let him know to change his config. Five minutes later, IPSEC tunnel was up, Phase 1 and Phase 2 setup and communication was clean.