New IP on Dynamic DNS IPSEC killed racoon
-
The timing is suspicious, but it's still hard to say. In that other thread it was a bad pre-release snapshot build that was the problem. If you're on 1.2.3-RELEASE that wouldn't be the issue.
You could backup your config and try a build of 2.0 beta to see if the behavior is better there.
-
Thanks for the reply jimp, I'll try & get a backup done of the current system - if I can find a way to quickly switch back to 1.2.3 in case of an emergency then I'll happily try 2.0 to see if the behaviour improves.
-
If you have a 1.2.3 CD and a USB stick handy, use this:
http://doc.pfsense.org/index.php/Automatically_Restore_During_Install -
Thanks for that, it's just what I was after. Racoon has begun going down on every IP change now so I'll most likely try this tonight after business closes, I'll let you know how things go. Wish me luck!
Edit: This may be a silly question, but is there a particular build of 2.0 Beta that's more stable than others?
-
Except in extremely rare occasions, the most recent beta build can be assumed to be the most stable.
-
Thanks submicron - I'll try the latest build.
-
Ok, running the latest build of PfSense 2.0 Beta 4 for i386 the results are in: Racoon is not going down completely on new IP at the remote site but the tunnel to that site is. Definitely a positive but for the other issues I'm having with the beta. The tunnel to the site with a dynamic dns is still going down on IP change and no amount of rebooting the router on the other end brings it up. The only way I've found to bring up the tunnel is to restart racoon.
-
This may be a shot in the dark, but are you sure you have exactly the same timeouts configured for both P1 and P2 on each end of the tunnel? This almost sounds like a security policy still exists on one side of the tunnel when the IP changes. When this happens again, check to see if you still have SPDs in place referencing the broken tunnel. If you do, kill them and re-init the tunnel. I think this may be the bug Jimp was talking about, and it was definitely fixed in 1.2.3-release, but it doesn't hurt to double-check.
-
2.0 still has an issue where DPD will fail to tear down a tunnel completely when the other end dies, despite printing messages to log saying it has removed the tunnel. I have to kill racoon on my 2.0 box with some regularity to regain connectivity to a remote site if it goes offline.
-
Thanks for the input guys, I've checked the lifetimes on both sides: phase1 and 2 are both set to 3600 on each side currently. The only slightly different timeout is the DPD as the routers have different fields. I've set PfSense to 10 second delay, 12 retries and the Snapgear to 10 second delay, 120 second timeout.
Ideally I'd be back with 1.2.3 release - I've had some issues with 2.0's stability - but it might be worth sticking with it if only one tunnel goes down instead of several. It's still a mystery to me why I'm having a problem with 1.2.3 release, I feel like PfSense & Snapgears don't get along too well… Maybe it's just the DPD thing jimp mentioned in 2.0b.
Thanks again for working with me on this. -
Hey jimp, I noticed something this morning - the IPSEC to the dynamic dns site had been down a few hours. Thing is the lifetime on both phases was set to 1 hour. Is this still part of the bug in 2.0? I could be wrong but I thought that if the SA was set to 1hr then PfSense would try to re-establish the connection after the lifetime expired even with the DPD bug.
