FreeBSD NAT-T patch integration [CFR/CFT]

VANHULLEBUS Yvan vanhu at
Mon Jul 21 19:16:39 UTC 2008

On Mon, Jul 21, 2008 at 01:27:05PM -0500, Matthew Grooms wrote:
> On Mon, Jul 21, 2008 at 10:31:10AM +0200, VANHULLEBUS Yvan wrote:
>> After some more testing, I found another issue: in udp4_espdecap(),
>> when payload <= sizeof(uint64_t) + sizeof(struct esp), packet should
>> not be discarded, but just returned for normal processing.
> 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 negociation 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....

> It should be disallowed as in Sams patch. Allowing them to be mixed  
> would cause problems using any of the patches I have seen. There is no  
> way to distinguish between a Draft 00/01 ISAKMP packet and an RFC ESP  
> packet without matching the port value to a SAD NAT-T mapping. And as  
> you mentioned, I also don't see why anyone would try to set them both.  
> There should never be a situation where you need to evaluate a NON-ESP  
> NAT-T marker on an ISAKMP socket, only NON-ISAKMP markers.

As I said, I was tracking down a problem on a gate which used to run
for a long time with previous patches, so every difference was suspect
for me :-)

> 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.


More information about the freebsd-net mailing list