On 14/6/18 3:01 am, 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.
hmmm that sounds like a bug to me..
why does it fail?
_______________________________________________
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"
