IPSEC NAT traversal

[Bjoern A. Zeeb]

On Tue, 28 Apr 2009, Scott Ullrich wrote:

> On Tue, Apr 28, 2009 at 8:07 AM, VANHULLEBUS Yvan <vanhu at freebsd.org> wrote:
>> See recent archives, there is actually an issue with the patchset, as
>> there are no more available bits in struct inp's flags.
>> We're working on that to find and implement the best solution.
>
> Hi,
>
> Ermal Luci recently whipped the pfSense's NATT patch into shape:
> http://cvs.pfsense.com/~sullrich/NATT.RELENG_8.diff
>
> I am not sure if this is how Yvan wants to solve it for the long term
> but it does seem to work OK for the short term until the patch is
> brought up to speed.

Ermal is using inp_flags2 that Kip has recently added to the inpcb.
The easy way to fix it for the next day. We considered that option.

The long term is that we'll have an UDP control block (patch currently
circulating for review and test but possibly committed the next two
days).  Considering the fact that the in kernel udp tunneling callback
already (ab)used the pointer and that NAT-T needs to dedicated UDP
flags and we've found someone already using an udpcb we decided that
now was the time to add it so that we wouldn't possibly be stuck in
FreeBSD 8.x.

I have NAT-T on top of that. And I am currently doing the whatever
you'll call it 'final pass', will send it back to Yvan once I am done
with the last 2 items and last 400 lines of key.c . After that I
assume someone will commit it.
As I am pretty sure you'll want to test it before it goes into the
tree so you'll get a copy as well; thanks for volunteering;-p

It's not yet going to use the new in kernel tunnel callback and I am
not yet sure if we can actually use it due to the placing of the
callback, but if we can, the change will not be visible to userland.
Thus we'll be able to do it any time.

It will also not yet support transport mode NAT-T that I found another
person needing it the other weekend while he was debugging NAT-T and
I was busy with something else;  but thanks to Yvan's last patch the
infrastructure to support it is in place already, so that support can
be added at a later point w/o breaking the kernel/userland API/ABI or
anything else (I hope at this point;).

/bz

-- 
Bjoern A. Zeeb                      The greatest risk is not taking one.