ipfw -- selecting locally generated packets

[Jeff Kletsky]

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 <freebsd at wagsky.com> 
>> 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 at freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-net
>> To unsubscribe, send any mail to "freebsd-net-unsubscribe at 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

$ 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