Probable mistake in PF tagging example ruleset order

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Probable mistake in PF tagging example ruleset order

Aham Brahmasmi
Hi,

I am trying to learn and understand the pf tagging mechanism. I was
wondering whether my understanding of the order in the example at
https://www.openbsd.org/faq/pf/tagging.html is correct. If it is, then
there might be a mistake in the order. The relevant lines are
...
pass out on egress inet tag LAN_INET_NAT tagged LAN_INET nat-to (egress)
pass in on $int_if from $int_net tag LAN_INET
...
pass out quick on egress tagged LAN_INET_NAT
...

My understanding:
For the first line, an IPv4 packet that is already tagged with LAN_INET
will now have the tag LAN_INET_NAT, and will be passed out on the
egress interface after Network Address Translation.

For the second line, a packet that is coming from the internal network
on the internal interface will be passed and tagged with LAN_INET.

For the third line, a packet that is tagged with LAN_INET_NAT will be
passed out on the egress interface, and the rule evaluation will stop.

Now, if my understanding is correct, then a packet will never match the
first line, since the LAN_INET tagging happens only in the second line.
And if that is the case, the third line will also not match, since the
LAN_INET_NAT tagging happens in the first line.

If my understanding is correct, then we may need to switch the order of
the first and second lines.

The complete ruleset is

int_if      = "dc0"
dmz_if      = "dc1"
int_net     = "10.0.0.0/24"
dmz_net     = "192.168.0.0/24"
www_server  = "192.168.0.5"
mail_server = "192.168.0.10"

table <spamd> persist file "/etc/spammers"
# classification -- classify packets based on the defined firewall
# policy.
block all
pass out on egress inet tag LAN_INET_NAT tagged LAN_INET nat-to (egress)
pass in on $int_if from $int_net tag LAN_INET
pass in on $int_if from $int_net to $dmz_net tag LAN_DMZ
pass in on egress proto tcp to $www_server port 80 tag INET_DMZ
pass in on egress proto tcp from <spamd> to port smtp tag SPAMD rdr-to \
127.0.0.1 port 8025

# policy enforcement -- pass/block based on the defined firewall policy.
pass in  quick on egress tagged SPAMD
pass out quick on egress tagged LAN_INET_NAT
pass out quick on $dmz_if tagged LAN_DMZ
pass out quick on $dmz_if tagged INET_DMZ

Thanks.

Regards,
ab
---------|---------|---------|---------|---------|---------|---------|--

Reply | Threaded
Open this post in threaded view
|

Re: Probable mistake in PF tagging example ruleset order

trondd-2
On Wed, January 10, 2018 2:44 pm, Aham Brahmasmi wrote:
> Hi,
>
> I am trying to learn and understand the pf tagging mechanism. I was
> wondering whether my understanding of the order in the example at
> https://www.openbsd.org/faq/pf/tagging.html is correct. If it is, then
> there might be a mistake in the order. The relevant lines are
>

Read the rules tagging follows again.  Tags are sticky.  Also a packet
passing through the firewall, say from a LAN machine to the internet, will
be evaluated twice.  If it gets tagged the first time, it'll have that tag
already when evaluated the second time.  If it matches a rule which tags
it, then matches another rule later, it still has the tag from the first
match.

> ...
> pass out on egress inet tag LAN_INET_NAT tagged LAN_INET nat-to (egress)
> pass in on $int_if from $int_net tag LAN_INET
> ...
> pass out quick on egress tagged LAN_INET_NAT
> ...
>
> My understanding:
> For the first line, an IPv4 packet that is already tagged with LAN_INET
> will now have the tag LAN_INET_NAT, and will be passed out on the
> egress interface after Network Address Translation.
>
> For the second line, a packet that is coming from the internal network
> on the internal interface will be passed and tagged with LAN_INET.
>
> For the third line, a packet that is tagged with LAN_INET_NAT will be
> passed out on the egress interface, and the rule evaluation will stop.
>
> Now, if my understanding is correct, then a packet will never match the
> first line, since the LAN_INET tagging happens only in the second line.
> And if that is the case, the third line will also not match, since the
> LAN_INET_NAT tagging happens in the first line.
>

Don't just read the rules from top to bottom.  Follow the packet.  Where
is the packet coming from?  Where is it going?  If there is a packet
coming from the LAN through this firewall to the internet what rules
match?  Does that rule tag the packet?  Does evaluation continue?

That's pass 1.  Since this packet is not destined for this machine, but
for something on the internet, it has to leave this machine.  So now it's
evaluated as an outgoing packet.  Did it get tagged before?  What rules
match based on direction and tag?  Does it get a new tag?  Does evaluation
continue?  Does it match anything else?


> If my understanding is correct, then we may need to switch the order of
> the first and second lines.
>
> The complete ruleset is
>
> int_if      = "dc0"
> dmz_if      = "dc1"
> int_net     = "10.0.0.0/24"
> dmz_net     = "192.168.0.0/24"
> www_server  = "192.168.0.5"
> mail_server = "192.168.0.10"
>
> table <spamd> persist file "/etc/spammers"
> # classification -- classify packets based on the defined firewall
> # policy.
> block all
> pass out on egress inet tag LAN_INET_NAT tagged LAN_INET nat-to (egress)
> pass in on $int_if from $int_net tag LAN_INET
> pass in on $int_if from $int_net to $dmz_net tag LAN_DMZ
> pass in on egress proto tcp to $www_server port 80 tag INET_DMZ
> pass in on egress proto tcp from <spamd> to port smtp tag SPAMD rdr-to \
> 127.0.0.1 port 8025
>
> # policy enforcement -- pass/block based on the defined firewall policy.
> pass in  quick on egress tagged SPAMD
> pass out quick on egress tagged LAN_INET_NAT
> pass out quick on $dmz_if tagged LAN_DMZ
> pass out quick on $dmz_if tagged INET_DMZ
>
> Thanks.
>
> Regards,
> ab
> ---------|---------|---------|---------|---------|---------|---------|--
>


Reply | Threaded
Open this post in threaded view
|

Re: Probable mistake in PF tagging example ruleset order

Aham Brahmasmi
Arigato gojaimas Trondd san for your very helpful reply. 
 

Sent: Thursday, January 11, 2018 at 3:17 AM
From: trondd <[hidden email]>
To: "Aham Brahmasmi" <[hidden email]>
Cc: [hidden email]
Subject: Re: Probable mistake in PF tagging example ruleset order
On Wed, January 10, 2018 2:44 pm, Aham Brahmasmi wrote:
> Hi,
>
> I am trying to learn and understand the pf tagging mechanism. I was
> wondering whether my understanding of the order in the example at
> https://www.openbsd.org/faq/pf/tagging.html is correct. If it is, then
> there might be a mistake in the order. The relevant lines are
>

Read the rules tagging follows again. Tags are sticky. Also a packet
passing through the firewall, say from a LAN machine to the internet, will
be evaluated twice. If it gets tagged the first time, it'll have that tag
already when evaluated the second time. If it matches a rule which tags
it, then matches another rule later, it still has the tag from the first
match.
 

> ...
> pass out on egress inet tag LAN_INET_NAT tagged LAN_INET nat-to (egress)
> pass in on $int_if from $int_net tag LAN_INET
> ...
> pass out quick on egress tagged LAN_INET_NAT
> ...
>
> My understanding:
> For the first line, an IPv4 packet that is already tagged with LAN_INET
> will now have the tag LAN_INET_NAT, and will be passed out on the
> egress interface after Network Address Translation.
>
> For the second line, a packet that is coming from the internal network
> on the internal interface will be passed and tagged with LAN_INET.
>
> For the third line, a packet that is tagged with LAN_INET_NAT will be
> passed out on the egress interface, and the rule evaluation will stop.
>
> Now, if my understanding is correct, then a packet will never match the
> first line, since the LAN_INET tagging happens only in the second line.
> And if that is the case, the third line will also not match, since the
> LAN_INET_NAT tagging happens in the first line.
>

Don't just read the rules from top to bottom. Follow the packet. Where
is the packet coming from? Where is it going? If there is a packet
coming from the LAN through this firewall to the internet what rules
match? Does that rule tag the packet? Does evaluation continue?

That's pass 1. Since this packet is not destined for this machine, but
for something on the internet, it has to leave this machine. So now it's
evaluated as an outgoing packet. Did it get tagged before? What rules
match based on direction and tag? Does it get a new tag? Does evaluation
continue? Does it match anything else?

I had understood from the documentation that tags were sticky. I also
understood that a packet can only have zero or one tag at any time.
Also, that a tag cannot be removed, but only replaced.

However, I had not understood that the rule evaluation happens on every
interface. I now know that the "tags are sticky" actually implies that
the tags persist across evaluations on interfaces.

Also, I can now fully understand this line - "With tagging, it's
possible to do such things as create "trusts" between interfaces and
determine if packets have been processed by translation rules."

Frankly, it is my mistake. Reading back pf.conf's man page, it is there
on the second paragraph.
"Each time a packet processed by the packet filter comes in on or goes
out through an interface, the filter rules are evaluated in sequential
order, from first to last."
And NAT implies two interface traversals.
Mea Culpa.


> If my understanding is correct, then we may need to switch the order of
> the first and second lines.
>
> The complete ruleset is
>
> int_if = "dc0"
> dmz_if = "dc1"
> int_net = "10.0.0.0/24"
> dmz_net = "192.168.0.0/24"
> www_server = "192.168.0.5"
> mail_server = "192.168.0.10"
>
> table <spamd> persist file "/etc/spammers"
> # classification -- classify packets based on the defined firewall
> # policy.
> block all
> pass out on egress inet tag LAN_INET_NAT tagged LAN_INET nat-to (egress)
> pass in on $int_if from $int_net tag LAN_INET
> pass in on $int_if from $int_net to $dmz_net tag LAN_DMZ
> pass in on egress proto tcp to $www_server port 80 tag INET_DMZ
> pass in on egress proto tcp from <spamd> to port smtp tag SPAMD rdr-to \
> 127.0.0.1 port 8025
>
> # policy enforcement -- pass/block based on the defined firewall policy.
> pass in quick on egress tagged SPAMD
> pass out quick on egress tagged LAN_INET_NAT
> pass out quick on $dmz_if tagged LAN_DMZ
> pass out quick on $dmz_if tagged INET_DMZ
>
> Thanks.
>
> Regards,
> ab
> ---------|---------|---------|---------|---------|---------|---------|--
>

 

Thanks.

Regards,
ab

Reply | Threaded
Open this post in threaded view
|

Re: Probable mistake in PF tagging example ruleset order

Aham Brahmasmi
(Resending, I fessed up the inline reply)

Arigato gojaimas Trondd san for your very helpful reply.

I had understood from the documentation that tags were sticky. I also
understood that a packet can only have zero or one tag at any time.
Also, that a tag cannot be removed, but only replaced.

However, I had not understood that the rule evaluation happens on every
interface. I now know that the "tags are sticky" actually implies that
the tags persist across evaluations on interfaces.

Also, I can now fully understand this line - "With tagging, it's
possible to do such things as create "trusts" between interfaces and
determine if packets have been processed by translation rules."

Frankly, it is my mistake. Reading back pf.conf's man page, it is there
on the second paragraph.
"Each time a packet processed by the packet filter comes in on or goes
out through an interface, the filter rules are evaluated in sequential
order, from first to last."
And NAT implies two interface traversals.
Mea Culpa.

Thanks.

Regards,
ab