IPFW problem with passing IPSEC through in-kernel NAT

[Karl Denninger]

On 12/9/2016 07:16, Karl Denninger wrote:
> 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.
>
I have completely re-factored the IPFW rule set that I am using here (it
was formerly built on top of the
"Simple" config in /etc/rc.firewall) to be completely stand-alone and
the problem has disappeared.

Bottom line -- this appears to have been some sort of problem with the
rule set rather than ipfw itself.

-- 
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/c80603a3/attachment.bin>