|
OpenBSD Installation and Upgrading Installing and upgrading OpenBSD. |
|
Thread Tools | Display Modes |
|
|||
ipsec/isakmpd tunnels dropping after upgrade
We recently upgraded to 5.0 on our main firewall. This upgrade had been postponed for a long time, mainly due to the changes that made newer versions of ipsec incompatible with older versions.
Our main firewall is the passive end of a series of tunnels that terminate in five other locations, and we have multiple tunnels to connect different subnets at each end in many cases. When we finally took the plunge and upgraded the main firewall, we knew we were going to have to upgrade the remote ends at the same time. In fact, the newer remote end units were configured over a year ago: they are at 4.8 We built the 5.0 system on a new PC, and replaced our old Soekris 4801s with PC Engine Alixs running 4.8 as mentioned. When we brought the new firewall online, we had some issues with some redirection rules we had, but we didn't touch the rules for the tunnels and all the tunnels came up the first time. Then, over the next few days, we started noticing that the tunnels would drop for a while, then reconnect. I looked at the ipsec.conf files on both ends and at the man pages and decided that they needed to be cleaned up. For each point-to-point set, they've been reduced to: ike esp from $local_gw to $remote_gw_a ike esp from $local_net1 to $remote_net1 peer $remote_gw_a ike esp from $local_net2 to $remote_net2 peer $remote_gw_a The main firewall's config also has the "passive" keyword for all the tunnels. The tunnels are initiated from the remote ends. Even after I did that we are seeing drop outs. The local end's daemon log is full of "isakmpd quick mode as responder" logs. We're trying to get the people looking after the network infrastructure at the site where we're seeing the most dropouts to check the integrity of their connections, but since this started with our upgrade to 5.0 locally and 4.8 remotely, I suspect the new stuff we've put in. What can I do to troubleshoot these intermittant dropouts? thx kmb |
|
|||
In all cases we've used the default authentication method.
My understanding was that this was originally HMAC-SHA2 and is now HMAC-SHA2-256. If that is correct, that means that delaying the upgrade wasn't necessary; we could have just changes the authentication mode. kmb |
|
||||
I'd thought SHA2 was inclusive of SHA256 and SHA512. But I could be wrong ... and often am.
There are few IPSec users here; I'm going to quote Ocicat. He often provides excellent advice: Quote:
|
|
|||
There was a bug causing problems like this around last summer. Seeing the versions you are running, you just might be affected by it. It was discussed briefly here
http://www.daemonforums.org/showthread.php?t=6299 |
|
|||
Quote:
|
|
|||
Based on denta's comment and link to the bug report, I've upgraded all five remote sites to 5.0 with no other changes. We'll see what happens over the next week or so.
kmb |
|
|||
It's been several weeks now, and my users aren't flagging me on any loss of connectivity to the remote sites. I still see lots of "quick mode" negotiation entries in the log files and I'm not sure if that is normal or not, but the links are staying up.
Thanks for all your help. kmb |
|
||||
From "How IPSec Works" part 4:
Quote:
|
|
|||
So, normal.
There are a few other error messages - some "invalid cookie" and "no route to host" but I believe I saw instances of those before that last round of upgrades. Thanks. kmb |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
IPsec/pf setup | denta | OpenBSD Security | 1 | 25th May 2012 09:08 PM |
isakmp to ipsec | badguy | OpenBSD Security | 3 | 17th November 2010 10:52 PM |
Need Help Please About IPsec | wong_baru | FreeBSD Security | 2 | 21st June 2010 08:00 AM |
Routing between site-to-site tunnels | docrice | OpenBSD General | 5 | 26th September 2008 09:21 AM |
Dropping an install on a fujitsu b142 | Azeitonense | OpenBSD Installation and Upgrading | 6 | 2nd May 2008 08:23 PM |