From owner-freebsd-net@freebsd.org Sat May 5 17:20:50 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 3FA6BFB417D for ; Sat, 5 May 2018 17:20:50 +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 D78E3753F9 for ; Sat, 5 May 2018 17:20:49 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (124-148-108-197.dyn.iinet.net.au [124.148.108.197]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id w45HKdp7029476 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 5 May 2018 10:20:41 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: ipfw -- selecting locally generated packets To: Jeff Kletsky , freebsd-net@freebsd.org References: <979d3478-4bec-e6a1-41cd-bb26beb93123@wagsky.com> <2b8de01f-9c67-8ead-5891-f0241be31a8d@freebsd.org> From: Julian Elischer Message-ID: <53d28233-58ed-fc51-c267-44402dc4e603@freebsd.org> Date: Sun, 6 May 2018 01:20:33 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: 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.25 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2018 17:20:50 -0000 On 5/5/18 1:33 am, Jeff Kletsky wrote: > > > On 5/3/18 6:35 AM, Julian Elischer wrote: >> On 3/5/18 12:08 am, Michael Sierchio wrote: >>> On Mon, Apr 30, 2018 at 10:48 AM, Jeff Kletsky >>> wrote: >>> >>>> "not recv any" doesn't seem to be helpful either >>>> >>>>      $ sudo ipfw add 64000 count ip from any to any out xmit any >>>> not recv >>>> any >>> >>> The loopback interface, lo0 ? >>> _______________________________________________ >>> 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" >>> >> As was pointed out a selector might be >> >> add 100 ip from me to any out not recv * >> >> one wonders if that would work or maybe >> >> skipto {line x) any from any to any out recv * >> >> followed by lines htat are for locally generated. >> >> these not tested.. > > Looks like > >      [not] recv * > > is going to work. > > Part of my refactor is to do "dispatch" with call/skipto (as Julian > Elischer noted above), so the potential inefficiencies of what I'm > guessing is a string glob only happen "once" per packet (per pass), > rather than on dozens of rules. Rule 16, below, could probably skip > the test, but for the likely tiny performance impact, readability > and maintainability have me leaving it in. > > > I took a *quick* look on a "live" routing system (standard ipfw > points; no bridging, no ether) with > > sudo ipfw add 13 set 5 drop all from any to any via ng*    # Kill > packet clones > sudo ipfw add 14 set 5 ngtee 100 ip4 from any to any in    # > incoming packets > sudo ipfw add 15 set 5 ngtee 200 ip4 from any to any out recv \* # > forwarded packets > sudo ipfw add 16 set 5 ngtee 300 ip4 from any to any out not recv > \*    # locally generated packets I'd skip it as 'interface = *' takes some time to evaluate. if you want to be readable. add comments. e.g. fb10-cc01# ipfw add count ip from any to any // test comments 05300 count ip from any to any // test comments fb10-cc01# ipfw list 5000-6000 05000 allow tcp from any to me via em0 frag 05100 allow ip from me to me via lo0 05200 allow udp from me to any out via em0 05300 count ip from any to any // test comments also I've > > $ sudo ngctl > > mkpeer ipfw: iface 100 inet > mkpeer ipfw: iface 200 inet > mkpeer ipfw: iface 300 inet > > and bringing up those new interfaces and using tcpdump. > > Took a brief bit to figure out how to get around the lack of > link-level headers on ng_ipfw output for tcpdump (documented in > ng_tag, of all places) as "mkpeer ipfw: eiface NNN ether" and > "tcpdump -ni ngX" doesn't know what to make of things. > > It feels like something of a hack-ish approach using ng_iface to > wrap the "bare" packet with a link-level header, especially as it > appears to be injecting a second copy of the packet into the stack > (hence rule 13, above). Figuring out a "better" way to "monitor" > packet flow through ipfw may be on my list in the future, but that > was sufficient to let me go ahead with further config/test. > > > Thanks for all the help! > > After so many years with FreeBSD and ipfw, eyes with a different > perspective can reveal new tricks to this old dog. > > 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" > >