> --As off Friday, December 19, 2003 11:20 AM -0600, Jim Mays is
> alleged to have said:
>
> > So when does tagging happen? Is it before NAT? If so, then is the
> > idea to tag it on the way out and block based on tag on the way
> > back in?
>
> --As for the rest, it is mine.
>
> Tagging can be done at any time, on any rule. The idea in your case
> is to tag the 192.168.100.130 box's packets when it is nat'ed and
> then filter on the tag. This does mean you need to NAT it
> separately, but putting a rule to NAT just it (and tag it) just
> before your general NAT rule should be fine.
>
> Daniel T. Staal
According to PF Faq, PF: Packet Tagging:
Tagging follows these rules:
1. Tags are "sticky". Once a tag is applied to a packet by a matching
rule it is never removed. It can, however, be replaced with a different tag.
2. Because of a tag's "stickiness", a packet can have a tag even if the
last matching rule doesn't use the tag keyword.
3. A packet is only ever assigned a maximum of one tag at a time.
4. Tags are internal identifiers. Tags are not sent out over the wire.
This is somewhat confused by the section on Checking for Applied Tags:
"To check for previously applied tags, use the tagged keyword:
pass out on $ext_if tagged INT_NET keep state
Outgoing packets on $ext_if must be tagged with the INT_NET tag in order to
match the above rule. Inverse matching can also be done by using the !
operator:
pass out on $ext_if tagged ! WIFI_NET keep state "
Does this mean that a NAT rule that tags packets will have those packets
stripped as they leave the network, but reapplied when the return connection
is NAT'd back to the privately addressed host? Is this the case for all
"keep state" connections (the returning packets are re-tagged)?
