Date: Tue, 1 May 2018 21:04:36 +0800 From: Julian Elischer <julian@freebsd.org> To: Eugene Grosbein <eugen@grosbein.net>, Jeff Kletsky <freebsd@wagsky.com>, freebsd-net@freebsd.org Subject: Re: ipfw -- selecting locally generated packets Message-ID: <600886b2-f78d-0af7-224e-a2711f7e1106@freebsd.org> In-Reply-To: <5AE75A4E.6020907@grosbein.net> References: <979d3478-4bec-e6a1-41cd-bb26beb93123@wagsky.com> <5AE75A4E.6020907@grosbein.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > > _______________________________________________ > 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" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?600886b2-f78d-0af7-224e-a2711f7e1106>