IPFW problem with passing IPSEC through in-kernel NAT

Karl Denninger karl at denninger.net
Fri Dec 9 13:16:56 UTC 2016


On 12/9/2016 06:18, Dr. Rolf Jansen wrote:
>> Am 09.12.2016 um 02:11 schrieb Karl Denninger <karl at denninger.net>:
>> ...
>> Some more information on this issue.... I suspect that something is
>> getting mangled somewhere in the IP stack, perhaps related to hardware
>> checksumming or similar -- or in the ipfw code.
> I had always ran into IPsec-NAT-UDP checksumming issues since I started working with FreeBSD, that tim v8.0. With a rather simple change in the respective kernel source file at least my issue can be resolved. This may be related to your issue or even not, anyway, I guess it is worth to give it a try.
>
> I am now running FreeBSD 11-RELEASE-p5. On line 462 of file /usr/src/sys/netinet/udp_usrreq.c, I replaced:
>
>     if (uh->uh_sum) {
>
> with:
>
>     if (uh->uh_sum &&
>         uh->uh_dport != htons(1701) &&
>         uh->uh_dport != htons(4500)) {
>
> This effectively skips extended UDP checksumming for certain UDP ports -- here the L2TP and IPsec-NAT-T ports. When I investigated the issue, I found in one related RFC, that IPsec-NAT-T isn't supposed to do UDP checksumming on the encapsulated packets anyway, and my patch enforces this behaviour.
>
> Best regards
>
> Rolf
>

In this case is that I never get to the use of port 4500 (there are no
packets emitted on that port that I can find); the initial key exchange
on port 500 is failing, and in-kernel NAT appears to be involved in some
fashion because I'm getting inside addresses that are (in some cases)
not being NATted at all despite the fact that as far as I can tell they
*should* be.

I'm going to spend some time refactoring the IPFW rule set to
compartmentalize the various paths through it more-fully.  Perhaps that
will shed some more light on the problem, or at least make
more-reasonable an attempt to trace it.

-- 
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2996 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freebsd.org/pipermail/freebsd-ipfw/attachments/20161209/be2b679e/attachment.bin>


More information about the freebsd-ipfw mailing list