From owner-freebsd-net@freebsd.org Wed Jun 13 17:32:07 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 20B21102092A; Wed, 13 Jun 2018 17:32:07 +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 B98416F739; Wed, 13 Jun 2018 17:32:06 +0000 (UTC) (envelope-from jmk@wagsky.com) Received: from JKLETSKY1-MBP15.local (184-23-190-180.vpn.dynamic.sonic.net [184.23.190.180]) (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 5C3E92837C; Wed, 13 Jun 2018 10:32:04 -0700 (PDT) Subject: Re: In-kernel NAT [ipfw] dropping large UDP return packets To: "freebsd-net@freebsd.org" , "freebsd-ipfw@freebsd.org" References: From: Jeff Kletsky Message-ID: <918b13e0-aef5-add2-6f5c-530bb5850a3a@wagsky.com> Date: Wed, 13 Jun 2018 10:32:04 -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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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 17:32:07 -0000 On 6/13/18 10:22 AM, Michael Sierchio wrote: > On Wed, Jun 13, 2018 at 10:16 AM, 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. > > > Do you have a 'reass' rule before applying nat on inbound traffic? > > - M Yes, at the start of the rule set. Reassembly confirmed to be working by wireshark examination of the ngtee "taps" shown $ sudo ipfw list 00001 deny ip from any to any recv ng* 00004 ngtee 100 ip from any to any proto udp dst-port 500,4500 in 00004 ngtee 100 ip from any to any proto udp frag in 00004 ngtee 110 ip from any to any proto udp dst-port 500,4500 out 00004 ngtee 110 ip from any to any proto udp frag out 00005 reass ip from any to any 00006 ngtee 101 ip from any to any proto udp dst-port 500,4500 in // reassembled in 00006 ngtee 101 ip from any to any proto udp frag in // never should be frags after reass 00006 ngtee 111 ip from any to any proto udp dst-port 500,4500 out // reass out 00006 ngtee 111 ip from any to any proto udp frag out // never should be frage after reass [...]