Date: Wed, 13 Jun 2018 13:04:22 -0700 From: Jeff Kletsky <freebsd@wagsky.com> 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: <b3a04654-7299-0a4d-61d1-ef21c63932b0@wagsky.com> 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 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b3a04654-7299-0a4d-61d1-ef21c63932b0>