From owner-freebsd-ipfw@freebsd.org Sun Jun 17 21:01:07 2018 Return-Path: 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 39A49100A10E for ; Sun, 17 Jun 2018 21:01:07 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id C15637F29E for ; Sun, 17 Jun 2018 21:01:06 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 55DCC100A108; Sun, 17 Jun 2018 21:01:06 +0000 (UTC) Delivered-To: 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 43A67100A107 for ; Sun, 17 Jun 2018 21:01:06 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D7ED27F276 for ; Sun, 17 Jun 2018 21:01:05 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 15ACE19619 for ; Sun, 17 Jun 2018 21:01:05 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w5HL14XR051353 for ; Sun, 17 Jun 2018 21:01:04 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w5HL14H0051341 for ipfw@FreeBSD.org; Sun, 17 Jun 2018 21:01:04 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201806172101.w5HL14H0051341@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: ipfw@FreeBSD.org Subject: Problem reports for ipfw@FreeBSD.org that need special attention Date: Sun, 17 Jun 2018 21:01:04 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2018 21:01:07 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- New | 215875 | [ipfw] ipfw lookup tables do not support mbuf_tag 1 problems total for which you should take action. From owner-freebsd-ipfw@freebsd.org Mon Jun 18 03:29:15 2018 Return-Path: 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 60E6810146CA; Mon, 18 Jun 2018 03:29:15 +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 EF8AA6BB64; Mon, 18 Jun 2018 03:29:14 +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 w5I3T8So082945 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 17 Jun 2018 20:29:12 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: In-kernel NAT [ipfw] dropping large UDP return packets To: Michael Sierchio , "freebsd-net@freebsd.org" , "freebsd-ipfw@freebsd.org" References: <918b13e0-aef5-add2-6f5c-530bb5850a3a@wagsky.com> From: Julian Elischer Message-ID: Date: Mon, 18 Jun 2018 11:29:03 +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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 03:29:15 -0000 On 14/6/18 1:41 am, Michael Sierchio wrote: > I see you have a case of Netgraph. Perhaps Julian will chime in. well I'm reading but not got any specific ideas at the moment.. Netgraph itself has no requirements on packet size or even contents. a node may however have some. > > On Wed, Jun 13, 2018 at 10:32 AM, Jeff Kletsky wrote: > >> 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 >> [...] >> >> >> _______________________________________________ >> freebsd-ipfw@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw >> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" >> > > From owner-freebsd-ipfw@freebsd.org Mon Jun 18 03:30:41 2018 Return-Path: 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" , Jeff Kletsky , freebsd-net@freebsd.org, freebsd-ipfw@freebsd.org References: <48e750c1-e38c-5376-a937-dcbb2d871256@yandex.ru> From: Julian Elischer Message-ID: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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? From owner-freebsd-ipfw@freebsd.org Mon Jun 18 03:32:43 2018 Return-Path: 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 3C5BE1014B55; Mon, 18 Jun 2018 03:32:43 +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 DA1236C013; Mon, 18 Jun 2018 03:32:42 +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 w5I3WbSw082971 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 17 Jun 2018 20:32:40 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: In-kernel NAT [ipfw] dropping large UDP return packets To: Jeff Kletsky , "Andrey V. Elsukov" , Jeff Kletsky , freebsd-net@freebsd.org, freebsd-ipfw@freebsd.org References: <48e750c1-e38c-5376-a937-dcbb2d871256@yandex.ru> <3b9b426e-8276-bc79-2624-60b66f04b344@wagsky.com> From: Julian Elischer Message-ID: <1cb6c6e6-844e-1e2d-3d65-bfbaee506c37@freebsd.org> Date: Mon, 18 Jun 2018 11:32:31 +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: <3b9b426e-8276-bc79-2624-60b66f04b344@wagsky.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 03:32:43 -0000 On 14/6/18 7:44 am, Jeff Kletsky wrote: > > > On 6/13/18 1:28 PM, Andrey V. Elsukov wrote: >> On 13.06.2018 23:04, Jeff Kletsky wrote: >>>> 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. >> I didn't look at the rest of libalias, but you, probably, can improve >> this hack to use 9k or 16k mbufs. You can replace m_get2() call in >> m_megapullup() with the following code: >> >> if (len <= MJUMPAGESIZE) >>     mcl = m_get2(len, M_NOWAIT, MT_DATA, M_PKTHDR); >> else if (len <= MJUM9BYTES) >>     mcl = m_getjcl(M_NOWAIT, MT_DATA, M_PKTHDR, MJUM9BYTES); >> else if (len <= MJUM16BYTES) >>     mcl = m_getjcl(M_NOWAIT, MT_DATA, M_PKTHDR, MJUM16BYTES); >> else >>     goto bad; >> > > Tested and "works for me" on 11.1-RELEASE-p10 with GENERIC kernconf > > 8< > --- alias.c.orig    2017-07-20 16:42:02.000000000 -0700 > +++ alias.c    2018-06-13 15:41:46.862121000 -0700 > @@ -1758,7 +1758,14 @@ >      if (m->m_next == NULL && M_WRITABLE(m)) >          return (m); > > -    mcl = m_get2(len, M_NOWAIT, MT_DATA, M_PKTHDR); > +    if (len <= MJUMPAGESIZE) > +        mcl = m_get2(len, M_NOWAIT, MT_DATA, M_PKTHDR); > +    else if (len <= MJUM9BYTES) > +        mcl = m_getjcl(M_NOWAIT, MT_DATA, M_PKTHDR, MJUM9BYTES); > +    else if (len <= MJUM16BYTES) > +        mcl = m_getjcl(M_NOWAIT, MT_DATA, M_PKTHDR, MJUM16BYTES); > +    else > +        goto bad; >      if (mcl == NULL) >          goto bad; >      m_align(mcl, len); > >8 > > Thanks again! Hi Andey,  please commit.. > > Jeff > > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > >