From: Matthew S. <ma...@ap...> - 2008-05-28 23:59:54
|
List, I have an IPSEC tunnel on a dsl modem using the ppp0 interface. I find that whenever the ISP flaps my SA becomes stale then racoon tries to create a few more without whacking the first one. I defined DPD in the racoon config as 15 so I would expect it to detect the dead SA within a minute or two based on the default dpd values and remote the stale SA, but it doesn't work. Anyone know how to make my IPSEC tunnel recover gracefully without requiring a racoon restart every time my ISP flaps? Attached are my config files so that you can see what I'm doing. Thanks, schu ~ $ cat /etc/racoon.conf path pre_shared_key "/etc/psk.txt"; listen { isakmp x.x.x.x [500]; adminsock "/usr/var/racoon/racoon.sock" "root" "root" 0600; } remote y.y.y.y { exchange_mode main; dpd_delay 15; proposal { encryption_algorithm 3des; hash_algorithm sha1; authentication_method pre_shared_key; dh_group modp1024; } } sainfo address 192.168.x.0/24 any address 172.x.x.0/12 any { pfs_group modp1024; encryption_algorithm 3des; authentication_algorithm hmac_sha1; compression_algorithm deflate; } sainfo address 192.168.x.0/24 any address 192.168.x.0/16 any { pfs_group modp1024; encryption_algorithm 3des; authentication_algorithm hmac_sha1; compression_algorithm deflate; } ~ $ cat /etc/ipsec.conf #!/usr/sbin/setkey -f # # Flush SAD and SPD flush; spdflush; # omit local traffic from ipsec spdadd 192.168.x.0/24 192.168.x.0/24 any -P out none; spdadd 192.168.x.0/24 192.168.x.0/24 any -P in none; # Ipsec policies spdadd 192.168.x.0/24 172.x.x.0/12 any -P out ipsec esp/tunnel/x.x.x.x-y.y.y.y/unique; spdadd 172.x.x.0/12 192.168.x.0/24 any -P in ipsec esp/tunnel/y.y.y.y-x.x.x.x/unique; spdadd 192.168.x.0/24 192.168.x.0/16 any -P out ipsec esp/tunnel/x.x.x.x-y.y.y.y/unique; spdadd 192.168.x.0/16 192.168.x.0/24 any -P in ipsec esp/tunnel/y.y.y.y-x.x.x.x/unique; # racoonctl show-sa esp y.y.y.y x.x.x.x esp mode=tunnel spi=52257390(0x031d626e) reqid=16411(0x0000401b) E: 3des-cbc 0926bb69 bed774d0 75a58b98 e3cea21c f4109bf3 a7456f62 A: hmac-sha1 37c862ee 43765eee 8f790ec7 a4d78232 5f702f8a seq=0x00000000 replay=4 flags=0x00000000 state=mature created: May 28 15:22:17 2008 current: May 28 15:45:42 2008 diff: 1405(s) hard: 14400(s) soft: 11520(s) last: May 28 15:22:20 2008 hard: 0(s) soft: 0(s) current: 7884(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 12 hard: 0 soft: 0 sadb_seq=1 pid=9318 refcnt=0 y.y.y.y x.x.x.x esp mode=tunnel spi=222731207(0x0d469bc7) reqid=16411(0x0000401b) E: 3des-cbc 17f94111 3067bdbf a8c61e1c 9216069f c917ca7c d84b8468 A: hmac-sha1 a4b43e0f d3214485 2256eb32 6eb0bc61 01b5c9cc seq=0x00000000 replay=4 flags=0x00000000 state=mature created: May 28 11:31:43 2008 current: May 28 15:45:42 2008 diff: 15239(s) hard: 28800(s) soft: 23040(s) last: May 28 11:32:03 2008 hard: 0(s) soft: 0(s) current: 1951772(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 15042 hard: 0 soft: 0 sadb_seq=2 pid=9318 refcnt=0 x.x.x.x y.y.y.y esp mode=tunnel spi=1712284771(0x660f6463) reqid=16410(0x0000401a) E: 3des-cbc 101efd66 6ca2901f 8d843fc7 ad654064 69e2e58f 1ac82212 A: hmac-sha1 bedd370d 482650a7 b891aaed f442d206 dc9550ff seq=0x00000000 replay=4 flags=0x00000000 state=mature created: May 28 15:22:17 2008 current: May 28 15:45:42 2008 diff: 1405(s) hard: 14400(s) soft: 11520(s) last: May 28 15:22:20 2008 hard: 0(s) soft: 0(s) current: 221632(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 690 hard: 0 soft: 0 sadb_seq=3 pid=9318 refcnt=0 x.x.x.x y.y.y.y esp mode=tunnel spi=3319341258(0xc5d920ca) reqid=16410(0x0000401a) E: 3des-cbc 6c406f39 c06c24e8 823b3c65 98e180f1 abeb1055 80a9ca7e A: hmac-sha1 59e9f540 fc765467 882917ed ba718ee8 9482b9ca seq=0x00000000 replay=4 flags=0x00000000 state=mature created: May 28 11:31:43 2008 current: May 28 15:45:42 2008 diff: 15239(s) hard: 28800(s) soft: 23040(s) last: May 28 11:32:03 2008 hard: 0(s) soft: 0(s) current: 4130392(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 35198 hard: 0 soft: 0 sadb_seq=4 pid=9318 refcnt=0 y.y.y.y x.x.x.x esp mode=tunnel spi=15127292(0x00e6d2fc) reqid=16409(0x00004019) E: 3des-cbc 2385d7e3 deb5b438 c6ebcc85 731611bb 208983b5 5f24e68f A: hmac-sha1 42123b3c c8a70740 9e9977f7 89322c8e ad64a6e7 seq=0x00000000 replay=4 flags=0x00000000 state=mature created: May 28 10:49:40 2008 current: May 28 15:45:42 2008 diff: 17762(s) hard: 28800(s) soft: 23040(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 0 hard: 0 soft: 0 sadb_seq=5 pid=9318 refcnt=0 x.x.x.x y.y.y.y esp mode=tunnel spi=2754704595(0xa43174d3) reqid=16408(0x00004018) E: 3des-cbc ed079a11 4d5b214b dc2863ba 32f93914 672944e5 d54cb6e7 A: hmac-sha1 0531c28f 6476a68f 2f57d951 b13a09ad 570f46b3 seq=0x00000000 replay=4 flags=0x00000000 state=mature created: May 28 10:49:40 2008 current: May 28 15:45:42 2008 diff: 17762(s) hard: 28800(s) soft: 23040(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 0 hard: 0 soft: 0 sadb_seq=0 pid=9318 refcnt=0 ~ $ racoonctl show-sa isakmp Destination Cookies Created y.y.y.y.500 0c5e7d6847179e2e:5731646b7e887a67 2008-05-28 15:22:17 |
From: Mike <mi...@je...> - 2008-05-29 17:22:25
|
On Wed, 28 May 2008, Matthew Schumacher wrote: > List, > > I have an IPSEC tunnel on a dsl modem using the ppp0 interface. I find > that whenever the ISP flaps my SA becomes stale then racoon tries to > create a few more without whacking the first one. > > I defined DPD in the racoon config as 15 so I would expect it to detect > the dead SA within a minute or two based on the default dpd values and > remote the stale SA, but it doesn't work. > > Anyone know how to make my IPSEC tunnel recover gracefully without > requiring a racoon restart every time my ISP flaps? > > Attached are my config files so that you can see what I'm doing. > > Thanks, > schu > > this is not really the response you are looking for, but 'me too'. I ended up writing a script to ping down the tunnel once per minute, when the pings fail, it will flush the current SA's, then restart racoon. Mike |
From: Tore A. <to...@li...> - 2008-05-30 05:49:03
|
* Matthew Schumacher > I have an IPSEC tunnel on a dsl modem using the ppp0 interface. I > find that whenever the ISP flaps my SA becomes stale then racoon > tries to create a few more without whacking the first one. > > I defined DPD in the racoon config as 15 so I would expect it to > detect the dead SA within a minute or two based on the default dpd > values and remote the stale SA, but it doesn't work. > > Anyone know how to make my IPSEC tunnel recover gracefully without > requiring a racoon restart every time my ISP flaps? You're not saying if it's the IPSEC or the ISAKMP SAs that goes stale. I believe DPD only covers the ISAKMP SA. With racoon the lifetime of the IPSEC SA is allowed to exceed that of the ISAKMP SA it was generated from, so you can get in a situation where you have a legit IPSEC SA and no ISAKMP SA. Thus, no DPD monitoring. I don't really know how to best deal with this, I'm afraid. I don't know if a stale ISAKMP SA being torn down due to unanswered DPD pings will also tear down all related IPSEC SAs generated from it. Don't take anything I wrote above as facts without researching it yourself, I'm not an authority on IPSEC and racoon and this is just how I _think_ it works. Regards, -- Tore Anderson |
From: VANHULLEBUS Y. <va...@fr...> - 2008-05-30 08:25:34
|
On Fri, May 30, 2008 at 07:49:01AM +0200, Tore Anderson wrote: > * Matthew Schumacher [...] > You're not saying if it's the IPSEC or the ISAKMP SAs that goes stale. > I believe DPD only covers the ISAKMP SA. Yes, according to RFC 3706, DPD is here to detect "Dead IKE Peers". It has been in my TODO list for a long time to extend this RFC to aso be able to monitor IPSEC-SAs (it woudn't be too difficult to do "DPDv2" for that), but I'm affraid it is still in the TODO list... > With racoon the lifetime of > the IPSEC SA is allowed to exceed that of the ISAKMP SA it was generated > from, It's not allowed "with racoon", but "with IKEv1" :-) > so you can get in a situation where you have a legit IPSEC SA and > no ISAKMP SA. Thus, no DPD monitoring. I don't really know how to best > deal with this, I'm afraid. Yes, this is a known issue, and there have been some discussions on that already. I guess the "best" solution would be to add a token like "keep IsakmpSA when DPD is active", which would force the negociation of a new ISAKMP-SA if DPD is active (I mean "active monitoring", not "enabled by peer and oneself") and if there are still some IPSec-SAs for the peer (if there are no more IPSec-SAs, DPD monitoring is really less interesting, and there is no need to force a new ISAKMP-SA just for nothing !). If someone can provide a patch for cfparse and man page, I'll do the rest ;-) > I don't know if a stale ISAKMP SA being torn down due to unanswered DPD > pings will also tear down all related IPSEC SAs generated from it. When a peer is detected as dead, DPD code will flush *everything* related to that peer, including any IPSec-SA for that peer. Yvan. |
From: Tore A. <to...@li...> - 2008-05-30 09:01:17
|
* VANHULLEBUS Yvan > It's not allowed "with racoon", but "with IKEv1" :-) Aha, I see. I know that at least Nortel boxes don't allow this to happen, which leads to _very_ frequent rekeying as the phase1 lifetime draws near its end - if there's 100 seconds left of phase1, that's what it'll demand, followed by rekeying after 80 seconds, followed by rekeying after 16 seconds, then after three seconds, and so on... Unfortunately it also makes racoon interop badly with those boxes because it uses RESPONDER-LIFETIME to signal that it doesn't accept the long lifetime, a notification racoon flat-out ignores, and it will also ignore the INITIAL-CONTACT notification they send when they're establishing new tunnels afterwards, so if we have several tunnels to the same Nortel box, the ones that carry traffic that's only initiated from the racoon side ends up being blackholes. :-( The bounty I promised a while ago for the implementation of these features is still unclaimed... Hint hint... ;-) > I guess the "best" solution would be to add a token like "keep > IsakmpSA when DPD is active", which would force the negociation of a > new ISAKMP-SA if DPD is active (I mean "active monitoring", not > "enabled by peer and oneself") and if there are still some IPSec-SAs > for the peer (if there are no more IPSec-SAs, DPD monitoring is really > less interesting, and there is no need to force a new ISAKMP-SA just > for nothing !). Agreed, this should do the trick nicely. But it should be sufficient to check for active _outbond_ IPSEC SAs, I think. > If someone can provide a patch for cfparse and man page, I'll do the > rest ;-) I'll look into it, maybe next week. :-) > When a peer is detected as dead, DPD code will flush *everything* > related to that peer, including any IPSec-SA for that peer. Including inbound IPSEC SAs, too? I would prefer if those was left alone. I don't think it will hurt to leave them there, and I can think of a situation where I believe it will help: Imagine a setup where racoon is on the receiving end of a tunnel (all traffic is initiated from the other side). Racoon does DPD monitoring, the other end is simply a passive DPD responder (like the default racoon configuration). Then there's a lengthy network outage, enough to make racoon tear down the ISAKMP and IPSEC SAs due to DPD. The outage is then fixed, and we have now the situation where the other side have a valid outbound IPSEC SA (and possibly also an ISAKMP SA). If we have at this point deleted the inbound IPSEC SA the other side will send us ESP traffic with an unknown SPI until their SA will expire - effectively blackholing traffic. Not good. Leaving the inbound SA there will ensure that we correctly receive the packet, and if we intend to respond to this packet the reply will trigger us to initiate both new phase1 and phase2 negotiations since we lack the necessary SAs to actually encrypt and transmit the reply packet. Regards, -- Tore Anderson |
From: Matthew G. <mg...@sh...> - 2008-06-05 05:35:56
|
VANHULLEBUS Yvan wrote: > On Fri, May 30, 2008 at 07:49:01AM +0200, Tore Anderson wrote: >> * Matthew Schumacher > [...] >> You're not saying if it's the IPSEC or the ISAKMP SAs that goes stale. >> I believe DPD only covers the ISAKMP SA. > > Yes, according to RFC 3706, DPD is here to detect "Dead IKE Peers". > It has been in my TODO list for a long time to extend this RFC to aso > be able to monitor IPSEC-SAs (it woudn't be too difficult to do > "DPDv2" for that), but I'm affraid it is still in the TODO list... > The name says it all. Its "Dead Peer Detection" not "Dead ISAKMP SA" detection. All SAs, not just ISAKMP SAs, should be deleted if a peer is dead. What benefit would there be to extend DPD so that it can monitor individual IPsec SAs? > >> so you can get in a situation where you have a legit IPSEC SA and >> no ISAKMP SA. Thus, no DPD monitoring. I don't really know how to best >> deal with this, I'm afraid. > > Yes, this is a known issue, and there have been some discussions on > that already. > > I guess the "best" solution would be to add a token like "keep > IsakmpSA when DPD is active", which would force the negociation of a > new ISAKMP-SA if DPD is active (I mean "active monitoring", not > "enabled by peer and oneself") and if there are still some IPSec-SAs > for the peer (if there are no more IPSec-SAs, DPD monitoring is really > less interesting, and there is no need to force a new ISAKMP-SA just > for nothing !). > > If someone can provide a patch for cfparse and man page, I'll do the > rest ;-) > Since we store DPD state in the phase1 handle, when would we not want to maintain persistent ISAKMP SAs when DPD is enabled? If you can think of a situation, I would be happy to provide a cfparse+manpage patch for the option. Otherwise, having DPD enabled for a specific peer should be the only option required. I believe the root cause is that racoon has no notion of peer state beyond what is stored in the individual phase 1 or phase 2 handles. A PF_KEY acquire can cause an ISAKMP negotiation because policies exist outside of racoon that know the peer address endpoints. If we had a struct which held peer state information, we could use it to track DPD events instead of keeping DPD state in the phase1 handle. I believe Cisco does something similar to this. If more than one ISAKMP SA exists, they can respond with a DPD ARE-YOU-THERE-ACK using a different ISAKMP SA than the one used to send the ARE-YOU-THERE request. ( not sure how well racoon handles this situation ) This implies peer state outside of what is stored in their version of an ISAKMP SA handle. In other words, it understands that both SA's belong to the same peer relationship and prefers to respond using a different SA. Another example would be where they will replace an expired ISAKMP SA when a connected client fails to. Even after the phase1 SA is dead, it still recognizes the peer relationship and attempts to salvage it. If the rekey fails, it deletes all SAs in the same fashion as a DPD timeout. The Shrew Soft IKE daemon also does something similar to this. A tunnel object is used to track relationships based on the LOC:PORT<->RMT:PORT information. Exchange handles are associated to the tunnel object and indirectly to the peer config in a hierarchal fashion. This allows the daemon to track things like DPD, NAT-T, XAuth, modecfg and generated policy state beyond the lifetime of a phase1 exchange handle. PEER \TUNNEL \PH1 <- easily replaced without effecting state CFG PH2 In any case, this is a much more complex solution to the problem at hand. I also vote for maintaining persistent ISAKMP SAs when DPD is enabled. It sounds like the easy way to fix things in racoon. > >> I don't know if a stale ISAKMP SA being torn down due to unanswered DPD >> pings will also tear down all related IPSEC SAs generated from it. > > When a peer is detected as dead, DPD code will flush *everything* > related to that peer, including any IPSec-SA for that peer. > The way it should be :) -Matthew |
From: Matthew S. <ma...@ap...> - 2008-06-04 21:28:20
|
VANHULLEBUS Yvan wrote: > On Fri, May 30, 2008 at 07:49:01AM +0200, Tore Anderson wrote: >> * Matthew Schumacher > [...] >> You're not saying if it's the IPSEC or the ISAKMP SAs that goes stale. >> I believe DPD only covers the ISAKMP SA. > > Yes, according to RFC 3706, DPD is here to detect "Dead IKE Peers". > It has been in my TODO list for a long time to extend this RFC to aso > be able to monitor IPSEC-SAs (it woudn't be too difficult to do > "DPDv2" for that), but I'm affraid it is still in the TODO list... Yes, the problem is with the IPSEC Sa, the ISAKMP sa looks fine. >> so you can get in a situation where you have a legit IPSEC SA and >> no ISAKMP SA. Thus, no DPD monitoring. I don't really know how to best >> deal with this, I'm afraid. > > Yes, this is a known issue, and there have been some discussions on > that already. > > I guess the "best" solution would be to add a token like "keep > IsakmpSA when DPD is active", which would force the negociation of a > new ISAKMP-SA if DPD is active (I mean "active monitoring", not > "enabled by peer and oneself") and if there are still some IPSec-SAs > for the peer (if there are no more IPSec-SAs, DPD monitoring is really > less interesting, and there is no need to force a new ISAKMP-SA just > for nothing !). I'm not sure I understand what your saying here. As far as I know there are several SAs after I have my ISP flap and I suspect one of them is correct, but because the stale ones are still up the traffic doesn't flow. At this point I just need a way to detect this situation and resolve it, but was hoping to not write a watchdog script. > > > If someone can provide a patch for cfparse and man page, I'll do the > rest ;-) My C is terrible so I'm not the guy to write the patch, but I can update man pages, but I would need to study this a little more since my ipsec isn't as strong as I would like it to be before I contribute documentation. > > >> I don't know if a stale ISAKMP SA being torn down due to unanswered DPD >> pings will also tear down all related IPSEC SAs generated from it. > > When a peer is detected as dead, DPD code will flush *everything* > related to that peer, including any IPSec-SA for that peer. What I don't understand is why racoon is smart enough to bring up another SA but not smart enough to tear down the old ones. Simply calling `racoonctl flush-sa esp` resolves the problem when I have more than an in and outbound sa. Thanks, schu |
From: Tore A. <to...@li...> - 2008-06-05 07:09:51
|
* Matthew Schumacher > What I don't understand is why racoon is smart enough to bring up > another SA but not smart enough to tear down the old ones. Simply > calling `racoonctl flush-sa esp` resolves the problem when I have more > than an in and outbound sa. Hmm. The kernel should always start using the most recently established SA for outgoing packets, so this isn't really up to racoon. The old ones are left there until they expire, though. I think it is conceivable that the peer ask us to delete the new SA, making the old one the most recent one in the process, but generally the old SAs remain unused until they go away. Are you running this on an old Linux kernel? It sounds like you're hitting this bug: http://bugzilla.kernel.org/show_bug.cgi?id=4952 -- Tore Anderson |
From: Matthew S. <ma...@ap...> - 2008-06-05 15:46:14
|
Tore Anderson wrote: > * Matthew Schumacher > >> What I don't understand is why racoon is smart enough to bring up >> another SA but not smart enough to tear down the old ones. Simply >> calling `racoonctl flush-sa esp` resolves the problem when I have more >> than an in and outbound sa. > > Hmm. The kernel should always start using the most recently established > SA for outgoing packets, so this isn't really up to racoon. The old > ones are left there until they expire, though. I think it is > conceivable that the peer ask us to delete the new SA, making the old > one the most recent one in the process, but generally the old SAs remain > unused until they go away. > > Are you running this on an old Linux kernel? It sounds like you're > hitting this bug: > > http://bugzilla.kernel.org/show_bug.cgi?id=4952 > I'm using 2.6.22.19 so I shouldn't be hitting that bug, but I'll take a look next time it fails. Thanks, schu |