Date: Mon, 21 Jul 2008 19:03:28 -0500 From: Matthew Grooms <mgrooms@shrew.net> To: vanhu@freebsd.org Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD NAT-T patch integration [CFR/CFT] Message-ID: <488523D0.30300@shrew.net> In-Reply-To: <48851B00.1060600@shrew.net> References: <488515FF.2020309@shrew.net> <48851B00.1060600@shrew.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> > I noticed this too. But the only situation that I could think of where a > > valid ISAKMP packet will be smaller than this is a NAT-T keep-alive. > > These are handled previously in the code path so I don't think there is > > an issue from a functional standpoint. > > That's what I also supposed when I noticed that, but I was tracking > down a negotiation problem (as an initiator, responder's first > exchange in Main mode was seen on tcpdump but not on racoon's log), > and it has been solved by fixing that part of the code.... > Sounds reasonable. > > On a related note, I noticed the patch unconditionally uses a source > > port of 500 when processing outbound Draft 00/01 packets. Should this > > value be obtained from the SAD NAT-T mapping to support an IKE daemon > > bound to a non standard port? > > It should really really not happen..... but yes, it would be cleaner > to get it from SAD than setting 500 anytime. > Well, its really really supported by all the IKE daemons I have seen in the ports collection. Someone is bound to try this and then spend a lot of time scratching their head. If this situation can be easily avoided, it should be. -Matthew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?488523D0.30300>