From: Michael H. W. <mhw@WittsEnd.com> - 2006-03-08 16:46:36
|
On Wed, 2006-03-08 at 16:29 +0000, Matthias Scheler wrote: > On Wed, Mar 08, 2006 at 09:04:37AM -0500, Michael H. Warfield wrote: > > Yeah, I sorta figured that all out. But then the NAT-T keepalive is > > sort of useless because it doesn't keep the NAT-T connection alive. >=20 > The RFC clearly documents that the purpose of NAT-T keepalive is to > stop the NAT router from purging the NAT mapping. Correct. Which it is now failing to do. When the ISKMP SA expires, the NAT-T keepalive ceases even though there is an IPSec SA that's running on that NAT-T mapping. What's suppose to keep that alive? > > It needs to be tied to any SA's that are alive and need a heartbeat on = the > > NAT-T connection. > That's what DPD (Dead Peer Detection) is for. But the peer is not dead. If you ping it from the inside out, it's alive and well. Besides, as long as you've brought it up... That appear to be broken as well. I've got dpd_delay set to 30 seconds. That appears to be the other blip in my tcpdumps that was occurring at 30 second intervals with a packet length 96 from the racoon side out followed by a packet length 88 returning from the other side. Both of those cease action about the same time as the NAT-T keepalive bubbles when the ISAKMP SA is purged. Net result is that I've got both natt-keepalive and dpd_delay set to values which should keep the connection state active and both die when the ISAKMP SA expires even though the IPSec SA is active. > Kind regards Mike --=20 Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw@WittsEnd.com /\/\|=3Dmhw=3D|\/\/ | (678) 463-0932 | http://www.wittsend.com= /mhw/ NIC whois: MHW9 | An optimist believes we live in the best of a= ll PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! |