From: Timo T. <tim...@ik...> - 2008-04-03 12:32:41
|
VANHULLEBUS Yvan wrote: > On Thu, Apr 03, 2008 at 10:54:23AM +0300, Timo Ter?s wrote: >> I noticed a bug (when running in Linux). When remote racoon is stopped >> cleanly and it sends the delete SA payload and the receiver calls >> purge_ipsec_spi(), but fails to purge the IPsec-SAs if either one is >> behind NAT. > > Some NAT-T issues are already well known with ipsec-tools, mainly > because Linux and Free/NetBSD don't have exactly the same way of > handling port numbers. Is there a list somewhere? I'd be happy to check these in Linux. Since I'm likely to bump into them sooner or later. >> This patch changes how NAT-T ports are matched when comparing which >> IPsec-SA:s to delete. At least on linux the port numbers are only in >> the NAT-T related extensions and the port number in ADDRESS_{SRC,DST} >> is always zero. >> >> The patch copies the port number only from the NAT-T only if the >> port number in the real address was zero. I'm not sure if it should >> be overwritten always, but this seems to work for me. > > Before reporting such patch, we'll have to ensure it doesn't break > other things (on Linux or on Free/NetBSD), I'll try to do such tests > ASAP (but I know it takes some time to do that), and if other people > can do some tests and report on the list the exact setup they tested > (OS/kernel version used, ipsec-tools version, what is the peer), if > NAT-T still works and if DELETE-SAs are correctly send/received, it > would be great ! Of course. I figured BSD would do it differently, so that why I'm not sure if the ports should be overwritten always or the way the attached patch does it. For my part, I can report that the patch fixes things for me: I'm running Linux 2.6.23 kernel and ipsec-tools CVS HEAD on both ends. Cheers, Timo |