Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 18 Jun 2018 11:30:29 +0800
From:      Julian Elischer <julian@freebsd.org>
To:        "Andrey V. Elsukov" <bu7cher@yandex.ru>, Jeff Kletsky <freebsd@wagsky.com>, freebsd-net@freebsd.org, freebsd-ipfw@freebsd.org
Subject:   Re: In-kernel NAT [ipfw] dropping large UDP return packets
Message-ID:  <c348b168-5881-fd1a-d7e1-4e09abf869eb@freebsd.org>
In-Reply-To: <48e750c1-e38c-5376-a937-dcbb2d871256@yandex.ru>
References:  <a00fd38d-a2d1-fcb5-f46a-03ea3fe4d686@wagsky.com> <48e750c1-e38c-5376-a937-dcbb2d871256@yandex.ru>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
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?





Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?c348b168-5881-fd1a-d7e1-4e09abf869eb>