ipfw -- selecting locally generated packets

[Aleksandr A Babaylov]

On Tue, May 01, 2018 at 09:04:36PM +0800, Julian Elischer wrote:
> On 1/5/18 2:02 am, Eugene Grosbein wrote:
> >01.05.2018 0:48, Jeff Kletsky wrote:
> >
> >> From time to time, I rewrite my firewall rules to take advantages of the 
> >> ever-improving set of features that ipfw provides. One of the challenges 
> >> I have faced in the past was selecting packets that are generated on the 
> >> firewall host itself, as opposed to those that it received through an 
> >> interface.
> >>
> >>While I find most of the Linux firewall implementations untenable for a 
> >>variety of reasons, it does provide differentiation between what they 
> >>call "OUTPUT" and "FORWARD". I'm looking to see if there is a "better" 
> >>way to implement this kind of selection with the 11.1 version of ipfw.
> >>
> >>"out and not in" may years ago seemed an obvious selector, and it's good 
> >>to see that it is now clearly documented that it doesn't work in "man 
> >>ipfw" with "(in fact, out is implemented as not in)".
> >>
> >>"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
> >>     64000 count ip from any to any out
> >>
> >>In the past, I've tagged all incoming packets and used that tag to 
> >>differentiate between the two.
> >>
> >>Is there something "cleaner" (or perhaps clearer) that using a tag in 
> >>that way?
> >I have been using "from me" for years and it works.
> >If you have NAT, process "from me" packets before translating outgoing 
> >packets
> >and process "to me" after translating incoming packet
> On a host with two interfaces you can use subtraction..
> i.e in the outgoing part of the rules you can test on recv xxx0 and if 
> it doesn't match it must be locally generated.
> I've also used the uid rule, which can only match on local packets 
> ut it only works if you only have a single 'user' on an appliance.

Why recv * not used for this task?