CP to Sonicwall VPN

[lammbo]

I'm trying to setup a site-to-site VPN tunnel between one of my CheckPoint clusters (at a hosting center) to a Sonicwall appliance. As I setup many VPN tunnels, I am quite well versed in in CheckPoint configuration and know most of the 'gotchas' and such.

My side:
Interoperable device has been configured using my client's public IP.
A network object has been created defining the client's encryption domain - no private IP overlap exists in my topology, this is a unique subnet
Phase I/II are 3DES/SHA1/G2 across the board.
Timers are default times - 1440 min. (Phase1) and 3600 sec. (PhaseII)
Manual encryption rules (NOT VPN communities) are in place and phase II properties are set correctly on the rules to use 3DES/SHA1.
I have many other clients using a multitude of other firewall types all setup the same as this one on my side.
There are no resource or licensing issues on my gateways
There are no-NAT rules in place so the traffic stays between the private IPs through the tunnel.

Client side:
A sonicwall appliance, just recently upgraded to the latest version while the sonicwall support team had us (me and client) in conference trying to help us. I don't know sonicwall so can't tell you what that 'latest' version is. Their tech support was most unhelpful and immediately broke the 'change 1 thing and retest rule' almost immediately. He wanted to use 300 second timers for Phase I and II - I knew they were going to be no help once he said that. After 2 hours on this call, I made an excuse to stop and put everything back to where I started. Except for the new software, so did the IT guy who runs the sonicwall.

Testing the tunnel:
Phase I negotiates fine and keys are exchanged using 3DES/SHA1/Pre-shared secrets.

Phase II negotiates fine from his side, ie my firewall accepts it and he can ping me through the tunnel.

Phase II from me to him is failing. Of course, I get the generic "quick mode - no proposal chosen" followed by another DROP log entry with the equally generic "no valid SA... refer to sk19423" message. So my ping never makes it to him.

I do see packets destined for the other site leaving the external interface if I do a tcpdump on that interface. And since Phase I and half of Phase II is successful, I know we have good routing between.

I have setup 7 other clients using non-checkpoint firewalls and have had this same problem every time with other devices. ALL 7 of those were resolved by something that needed to be done on the other side of the tunnel, with no changes on my side. I suspect the same is true here also. None of the clients using CP VPN-1 Edge devices ever have an issue and I can get the tunnel up in less than 10 minutes talking them through the setup blindly on the phone (from memory alone).

It must be a 'gotcha' on the sonicwall side. I read the only CP to Sonicwall VPN guide on Sonicwall's website to no avail. I would like to note that Sonicwall's doc was written for NG FP3 using VPN communities, but as I stated earlier, I know enough about CP's VPN setup that it was easy for me to make the transition to NGX and Traditional VPN mode for my side of the config.


I do not have access to the client firewall. Anyone know enough about tunnels between the 2 types to help?

[lammbo]

For any interested, I solved my own problem. Here's the solution:

Per CP Knowledgbase article sk26336:
-------quoted from article-------------- (hope this doesn't break any rules, so I'm not including the fix they list, just the example)
By default, when computing ranges for Quick Mode ID, VPN-1 combines several subnets into one whenever possible. For example, if the encryption domain includes two adjacent networks, 172.30.32.0/22 and 172.30.36.0/22, VPN-1 will negotiate the QM for one subnet 172.30.32.0/21. If the peer is a non-Check Point gateway, it will fail the key exchange because of the unexpected ID, since it computes the ranges differently.
--------end quote---------------------

In my case, my firewall was sending 172.28.2.0/24 and the remote firewall only had 3 HOST entries listed for the tunnel and not the whole subnet. Since my traditional mode encryption rules only include the 3 web server IPs involved on my side + the other side's single HOST ip, we assumed incorrectly that it would be OK to just use the host entries on the Sonicwall side (or almost any other non-checkpoint firewall for that matter).

In SmartCenter, under VPN Advanced (at least in NGX), there is are 3 options for VPN tunnel settings:
1) One VPN trunnel per each pair of Hosts
2) One VPN tunnel per subnet pair
3) One VPN tunnel per Gateway pair

If I were using option 1, I would have never had the issue. I beleive it would have negotiated 3 different tunnels, one for each host pair just as it describes.

Since I am using option 2, the remote (sonicwall) firewall needed to be altered to use the subnet instead of the 3 host entries. This resolved the issue immediately.

Option 3 is probably insane unless you're only doing a full site-to-site encrypt and have no tunnels between 3rd parties.

Hope this helps someone else in the future.