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"

Reply via email to