Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 13 Jun 2018 10:16:04 -0700
From:      Jeff Kletsky <freebsd@wagsky.com>
To:        freebsd-net@freebsd.org, freebsd-ipfw@freebsd.org
Subject:   In-kernel NAT [ipfw] dropping large UDP return packets
Message-ID:  <a00fd38d-a2d1-fcb5-f46a-03ea3fe4d686@wagsky.com>

next in thread | raw e-mail | index | archive | help
When a T-Mobile "femto-cell" is trying to establish its IPv4, IPSEC 
tunnel to the T-Mobile provisioning servers, the reassembled, 4640-byte 
return packet is silently dropped by the in-kernel NAT, even though it 
"matches" the outbound packet from less than 100 ms prior.

All other operations of the firewall seem to be functioning as expected. 
This includes iPhones using "WiFi Calling" which utilizes similar IPSEC 
connections to T-Mobile servers (though fragmentation has not been seen 
on those connections). The connection for the femto-cell can be handled 
by a Linux/netfilter NAT. Proper reassembly of the packet fragments 
within the firewall ("reass ip from any to any"), at the start of the 
rule set, prior to NAT, has been confirmed with ngtee and wireshark.


Is there a known issue with large packets and in-kernel NAT?


The only sysctl that I found that seemed related was the UDP timeout. 
For good measure I upped it to 30 (seconds), but that did not change the 
behavior.


Are there known causes and/or resolutions for this behavior?


Is there a way to be able to "monitor" the NAT table?

(I didn't see anything obvious in the ipfw, natd, or libalias man pages.)


Thanks!

Jeff


11.1-RELEASE-p9 FreeBSD 11.1-RELEASE-p9 #0: Tue Apr  3 16:59:16 UTC 2018 
root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64

Additional details at 
https://forums.freebsd.org/threads/in-kernel-nat-dropping-large-udp-return-packets.66262/

pcapng files and ipfw rule set available on request to freebsd {a} 
wagsky {.} com






Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a00fd38d-a2d1-fcb5-f46a-03ea3fe4d686>