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
r...@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
_______________________________________________
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
