In-kernel NAT [ipfw] dropping large UDP return packets

[Jeff Kletsky]

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