Re: IPFW problem with passing IPSEC through in-kernel NAT

2016-12-09 Thread 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 :
>>> ...
>>> 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
k...@denninger.net 
/The Market Ticker/
/[S/MIME encrypted email preferred]/


smime.p7s
Description: S/MIME Cryptographic Signature

Re: IPFW problem with passing IPSEC through in-kernel NAT

2016-12-09 Thread Karl Denninger 
On 12/9/2016 06:18, Dr. Rolf Jansen wrote:
>> Am 09.12.2016 um 02:11 schrieb Karl Denninger :
>> ...
>> 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
k...@denninger.net 
/The Market Ticker/
/[S/MIME encrypted email preferred]/


smime.p7s
Description: S/MIME Cryptographic Signature

Re: IPFW problem with passing IPSEC through in-kernel NAT

2016-12-09 Thread Dr. Rolf Jansen 
> Am 09.12.2016 um 02:11 schrieb Karl Denninger :
> ...
> 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
___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"