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. -- WBR, Andrey V. Elsukov
signature.asc
Description: OpenPGP digital signature
