On 6/13/18 12:01 PM, Andrey V. Elsukov wrote:
On 13.06.2018 20:16, Jeff Kletsky wrote:
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.
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.)
The kernel version of libalias uses m_megapullup() function to make
single contiguous buffer. m_megapullup() uses m_get2() function to
allocate mbuf of appropriate size. If size of packet greater than 4k it
will fail. So, if you use MTU greater than 4k or if after fragments
reassembly you get a packet with length greater than 4k, ipfw_nat()
function will drop this packet.
Thanks!!
Mystery solved...
/usr/src/sys/netinet/libalias/alias.c
#ifdef _KERNEL
/*
* m_megapullup() - this function is a big hack.
* Thankfully, it's only used in ng_nat and ipfw+nat.
suggests that the "old school" approach of natd might resolve this. I'll
give it a try when I'm close enough to the box to resolve it when I make
a configuration error.
Jeff
_______________________________________________
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"
