SUGGESTION/FEATURE: IPsec delete request when disabling IPsec

fthomasr

Today I noticed something pfSense 1.2.3 does gracefully that 2.0 does not and it would be nice if it did.

spoke HUB spoke
pfsense 2.0<–-----------Sonicwall----------->pfSense 1.2.3

I have over 40 'spokes' connected to the Sonicwall 2040 'hub'.

When I disable IPsec (i.e. I want to bring an active tunnel down, make a change and bring it back up later) on v1.2.3 it 'tells' my Sonicwall to tear down the tunnel; Sonicwall log shows 'Received IKE SA delete request'. Version 2.0RC3 does not do this so when I reenable the tunnel it argues with the Sonicwall or doesn't work at all UNTIL I manually disable the SA on the Sonicwall and reenable it.

I assume that the developers meant 2.0 to have the behavior 1.2.3 has but have not had anyone report it yet.

cmb

Our code does exactly the same thing on both, seems that's possibly an ipsec-tools regression in the newer version. DPD does work fine in the new version though so if you have that on, that'll take care of it.

fthomasr

CMB, I could write a book on what I've learned between Sonicwall Sonic OS Standard & pfSense IPSec tunnels. I've poured over whitepapers, RFCs, you name it to get it stable and I finally have. I thought about posting a sticky on the forum somewhere to help others…

First, unfortunately Sonic OS Standard, which came standard on all their firewalls until just last year, was developed(prior to 2003) before there were official RFC's for both DPD and NAT-T. The DPD they use is propietary and will NOT work with any other brand. It will work with Sonic OS Enhanced which does meet the RFC but Enhanced was like a $2000+ upgrade option at the time for the Sonicwall Pro 2040 for example so I never had any customer upgrade as I thought was cost prohibitive just to add a few features. Sonic OS Enhanced now is standard on all their units however ONLY v2.5 Enhanced or later has the DPD as prescribed by the RFC.

Furthermore the NAT-T is a first draft on Sonic OS Standard and I thought it would interopt with pfSense as both devices aknowledge each other in their logs. However I learned the hard way yesterday that their are in fact not compatible! I spent a day scratching my head at work when I could bring up the tunnel behind our own pfSense box with one I was testing for a customer and yet I couldn't ping across! It wasn't until I booted a 1.2.3 CF card I had which had a tunnel which worked until I figured out that it NAT-T was the culprit as 1.2.3 did not have it and that's why my 2.0 tunnel wouldn't work. One small checkbox and a day lost....

Bottom line, I can't turn on DPD, so I must rely on this feature.

Darkk

Thanks for the heads up on DPD and NAT-T stuff. I've had problems with IPSet Site to Site VPN with WatchGuards and Sonicwalls. The WatchGuards we use are XTM series so it's using the official standards. Took me awhile to get rid of the Sonicwalls out in the field and left with one left to swap out. I use PfSense 2.0 at home.

Least now I know I wasn't crazy as to why I was having stablity issues with the WG and Sonicwalls.

Thanks,
Darkk

cmb

Wow, well if the Sonicwall is that buggy…you sure it's not getting sent in a more proper way in the new ipsec-tools but it's ignoring it? May want to crank up the debug logging (2.0 has a checkbox for that under System>Advanced, Misc) and see what that shows. That's absurd they don't offer a standards-compliant solution as a no cost upgrade especially given they were shipping effectively a broken IPsec implementation for years. Paying that kind of money you ought to get something that works.