From owner-freebsd-ipfw@freebsd.org  Mon Jun 18 03:30:41 2018
Return-Path: <owner-freebsd-ipfw@freebsd.org>
Delivered-To: freebsd-ipfw@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 D14A9101481F;
 Mon, 18 Jun 2018 03:30:41 +0000 (UTC)
 (envelope-from julian@freebsd.org)
Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client CN "vps1.elischer.org",
 Issuer "CA Cert Signing Authority" (not verified))
 by mx1.freebsd.org (Postfix) with ESMTPS id 757E26BC7A;
 Mon, 18 Jun 2018 03:30:41 +0000 (UTC)
 (envelope-from julian@freebsd.org)
Received: from Julian-MBP3.local (203-59-175-75.dyn.iinet.net.au
 [203.59.175.75]) (authenticated bits=0)
 by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id w5I3UZaG082958
 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
 Sun, 17 Jun 2018 20:30:38 -0700 (PDT)
 (envelope-from julian@freebsd.org)
Subject: Re: In-kernel NAT [ipfw] dropping large UDP return packets
To: "Andrey V. Elsukov" <bu7cher@yandex.ru>, Jeff Kletsky
 <freebsd@wagsky.com>, freebsd-net@freebsd.org, freebsd-ipfw@freebsd.org
References: <a00fd38d-a2d1-fcb5-f46a-03ea3fe4d686@wagsky.com>
 <48e750c1-e38c-5376-a937-dcbb2d871256@yandex.ru>
From: Julian Elischer <julian@freebsd.org>
Message-ID: <c348b168-5881-fd1a-d7e1-4e09abf869eb@freebsd.org>
Date: Mon, 18 Jun 2018 11:30:29 +0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; 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: 7bit
Content-Language: en-US
X-BeenThere: freebsd-ipfw@freebsd.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: IPFW Technical Discussions <freebsd-ipfw.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-ipfw>,
 <mailto:freebsd-ipfw-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ipfw/>
List-Post: <mailto:freebsd-ipfw@freebsd.org>
List-Help: <mailto:freebsd-ipfw-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw>,
 <mailto:freebsd-ipfw-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Jun 2018 03:30:42 -0000

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?