From owner-freebsd-net@freebsd.org Wed Jun 13 20:04:25 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4473D100E7B2; Wed, 13 Jun 2018 20:04:25 +0000 (UTC) (envelope-from jmk@wagsky.com) Received: from mx.allycomm.com (mx.allycomm.com [138.68.30.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D629877A64; Wed, 13 Jun 2018 20:04:24 +0000 (UTC) (envelope-from jmk@wagsky.com) Received: from JKLETSKY1-MBP15.local (184-23-191-106.vpn.dynamic.sonic.net [184.23.191.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.allycomm.com (Postfix) with ESMTPSA id 7A33F284C9; Wed, 13 Jun 2018 13:04:22 -0700 (PDT) Subject: Re: In-kernel NAT [ipfw] dropping large UDP return packets To: "Andrey V. Elsukov" , Jeff Kletsky , freebsd-net@freebsd.org, freebsd-ipfw@freebsd.org References: <48e750c1-e38c-5376-a937-dcbb2d871256@yandex.ru> From: Jeff Kletsky Message-ID: Date: Wed, 13 Jun 2018 13:04:22 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <48e750c1-e38c-5376-a937-dcbb2d871256@yandex.ru> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 20:04:25 -0000 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