View Single Post
Old 10th November 2011
scrummie02 scrummie02 is offline
Port Guard
 
Join Date: Nov 2011
Posts: 27
Default

Quote:
Originally Posted by J65nko View Post
You have now
Code:
#LAN OUT
pass in on $int from $int_net tag LAN
pass in on $int from $int_net to $dmz_net tag LAN_TO_DMZ
Please consider this little bit confusing snippet from the pf man page:
Code:
tag <string>
             Packets matching this rule will be tagged with the specified
             string.  The tag acts as an internal marker that can be used to
             identify these packets later on.  This can be used, for example,
             to provide trust between interfaces and to determine if packets
             have been processed by translation rules.  Tags are "sticky",
             meaning that the packet will be tagged even if the rule is not
             the last matching rule.  Further matching rules can replace the
             tag with a new one but will not remove a previously applied tag.
             A packet is only ever assigned one tag at a time.  Tags take the
             same macros as labels (see above).
If you ping a DMZ server from the internal net, pass in on $int from $int_net tag LAN it
be tagged with LAN. However, because you don't use quick, pf will keep evaluating the ping with the next rule pass in on $int from $int_net to $dmz_net tag LAN_TO_DMZ
You can check this with pfctl -vvsr and check the Evaluations counter.

Remember that packets entering on the internal interface all have the internal lan as origin. There are however two groups: packets with destination DMZ and packets for the Internet.
If pass in quick on $int from $int_net tag LAN would come first, the packets would never be evaluated to check whether they have the DMZ as destination.

So the solution is:

Code:
pass in quick on $int from $int_net to $dmz_net tag LAN_TO_DMZ
pass in quick on $int from $int_net tag LAN
Okay, I have a question, On the packet tagging FAQ on the OpenBSD site they don't' use quick, and wouldn't I want all of the rules evaluated even after traffic passes the int interface? I'm just wondering.
Reply With Quote