Date: Tue, 28 Apr 2009 17:28:00 +0000 (UTC) From: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> To: Scott Ullrich <sullrich@gmail.com> Cc: freebsd-net@freebsd.org, VANHULLEBUS Yvan <vanhu@freebsd.org> Subject: Re: IPSEC NAT traversal Message-ID: <20090428170638.P15361@maildrop.int.zabbadoz.net> In-Reply-To: <d5992baf0904280915m1fa07b0aq59fefa872a2d0d4e@mail.gmail.com> References: <49F6D598.6040503@zirakzigil.org> <20090428120751.GA68471@zeninc.net> <d5992baf0904280915m1fa07b0aq59fefa872a2d0d4e@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 28 Apr 2009, Scott Ullrich wrote: > On Tue, Apr 28, 2009 at 8:07 AM, VANHULLEBUS Yvan <vanhu@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090428170638.P15361>