PF which rule is executed

Hi all,

1.Suppose an external packet is matched against many packet filtering rules and then among all matched rules which one is executed , is it first one or last one(assuming that there is no quick keyword in the matched rules).

I surely believe that last matched rule is executed(similar to openbsd). If i am wrong ,pls correct me.

2.on incoming packet ,first packet rules will be applied and if these packets are allowed ,then corresponding NAT and RDR stmts executed?. Am i correct?


thank you.
 
1) last match wins (except quick rules)
2) NAT/ RDR first, then filter rules applied to the transformed packet. (Unless pass added to the rdr/nat rule; then automatically passed ignoring filter rules.)
 
1) last match wins (except quick rules)
2) NAT/ RDR first, then filter rules applied to the transformed packet. (Unless pass added to the rdr/nat rule; then automatically passed ignoring filter rules.)

Thank you for response.

First one is cleared.
But second one is not cleared. I think it in opposite way(first pass/block and then NAT/RDR).
I just read docs and comeback.
 
Hi,
I have another doubt like.

There is an HTTP Request coming from external network. The first packet of this request will be matched against packet filtering rules(pass or block) or NAT/RDR rules?.

My opinion is that the first packet of any request matched against the packet filtering rules.If pass rule allows the request,then subsequent packets does not require to go through the packet filtering rules and only they pass through the NAT/RDR.

Pls correct my opinion.
 
From the man page:
Code:
     Since translation occurs before filtering the filter engine will see
     packets as they look after any addresses and ports have been translated.
Also, keep in mind translation rules are evaluated differently from filtering rules. Binat rules are evaluated before nat/rdr, and all translation rules are always "first match."

If you need to use pass/block after a nat/rdr rule, and you want to know which nat/rdr rule it matched (if any), you can use policy based filtering. Look at pf.conf(5) for "tag" or "tagged" to get more details on the syntax. Alternatively you can just pass/block on the translation rules themselves.
 
Alternatively you can just pass/block on the translation rules themselves.
Keep this in mind though:
Code:
     If the pass modifier is given, packets matching the translation rule are
     passed without inspecting the filter rules:
Which can be confusing if you have something like this:
Code:
rdr pass on $ext_if inet proto tcp from any to ($ext_if) port 22

block in quick on $ext_if proto tcp from <sshguard> to any port 22
In that case the SSHGuard block rule never gets evaluated. This works as expected:
Code:
rdr on $ext_if inet proto tcp from any to ($ext_if) port 22

block in quick on $ext_if proto tcp from <sshguard> to any port 22
pass in on $ext_if proto tcp from any to ($ext_if) port 22
 
My opinion is that the first packet of any request matched against the packet filtering rules.If pass rule allows the request,then subsequent packets does not require to go through the packet filtering rules and only they pass through the NAT/RDR.

As I stated above, and as multiple other users have repeated, this is wrong. NAT/RDR occurs before filter rules are applied.
Documented here:
Code:
     Since translation occurs before filtering the filter engine will see
     packets as they look after any addresses and ports have been translated.
     Filter rules will therefore have to filter based on the translated ad-
     dress and port number.  Packets that match a translation rule are only
     automatically passed if the pass modifier is given, otherwise they are
     still subject to block and pass rules.
 
Hi all,

i have a below setup like this in pf.conf file.

(ip details)
em0=192.168.43.61/24
em1=192.168.56.40/24

-------------------------------------------
pf.conf file
------------------------------------------

WAN = "{ em0 }"
LAN = "{ em1 }"

# NAT rules
nat on $WAN inet from em1:network to any -> em0
nat on $LAN inet from em0:network to any -> em1
rdr on $WAN proto tcp from any to any port 8080 -> 192.168.56.42

-------------
End of file
--------------

1.On internal network , simple web sever is running with port 8080 on 192.168.56.42.
2. Request is made like 192.168.43.61:8080 from browser of external system,
then this request reached server and response came.

Here my doubt is, with out having the pass attribute ,how request went there?

In which case, packets will pass through the packet filtering rules after translation.
(from doc , i read that if translation is not happens, packets pass through filter engine)

thank you.
 
nat on $LAN inet from em0:network to any -> em1
Remove that one. Actually, remove all NAT. Both sides (em0, em1) are using private range addresses, so you can easily make it work using normal IP routing. There's no need to resort to NAT for this.
 
Remove that one. Actually, remove all NAT. Both sides (em0, em1) are using private range addresses, so you can easily make it work using normal IP routing. There's no need to resort to NAT for this.

Suppose if em0 is 10.182.1.230/23 ,in that case what will happen?.
 
Still a private range network and can often be solved by proper traditional routing. NAT is actually a kludge, avoid it whenever you can. There are a few cases where you simply cannot avoid it, like connecting a private network to the internet, or when you have no control over other routers on the network. I've seen a lot of people solving really simple routing issues with NAT, mainly because they just don't know how to set up routing properly. But your main focus should be proper, correct, routing first, only if you really can't avoid it should you use NAT.
 
As noted above, you may not need any NAT in this setup.

Also, be aware that, for the filtering behavior:
Code:
If no rule matches the packet, the
default action is to pass the packet.

again from pf.conf(5)

Code:
If no rule matches the packet, the
default action is to pass the packet.

This above statement confuses me .(no rule means which rules(nat/rdr or filter or both?)
For example ,(only below two rules are there in pf.conf file)

block all
pass on em0 from src_ip1 src_port1 to dst_ip1 dst_port1

---
Now a new packet came to this em0 interface from different source with ip address of src_ip2 and src_port2.

will this packet accepted?. According above stmt this is allowed.But according to above two rules defined in pf.conf,it does not be allowed?.

pls give me clarity.

thank you

---
 
Still a private range network and can often be solved by proper traditional routing. NAT is actually a kludge, avoid it whenever you can. There are a few cases where you simply cannot avoid it, like connecting a private network to the internet, or when you have no control over other routers on the network. I've seen a lot of people solving connectivity by using NAT, mainly because they simply don't know how to set up routing properly.

In our case, em0 will be also connected to internet only. But for testing purpose , i connected it to my mobile hotspot.
 
But for testing purpose , i connected it to my mobile hotspot.
The "problem" with this is that your mobile hotspot already does NAT to connect your private hotspot network to the internet. Adding another host with another NAT layer complicates things enormously if you need to connect, from the internet, to a host that's behind two (or more) NAT layers.
 
The default (filter) rule is to pass everything.

I understood that if there are set of pass or block rules matched against packet,then the last matched rule or the first rule with quick is applied on the packet. Otherwise, no rule is matched means it will be passed.
 
Still a private range network and can often be solved by proper traditional routing. NAT is actually a kludge, avoid it whenever you can. There are a few cases where you simply cannot avoid it, like connecting a private network to the internet, or when you have no control over other routers on the network. I've seen a lot of people solving really simple routing issues with NAT, mainly because they just don't know how to set up routing properly. But your main focus should be proper, correct, routing first, only if you really can't avoid it should you use NAT.
Or you get bump into double or recursive NATing which creates a packet wreck. Absolutely, only NAT when you have no other choice. I've done more than my share of rouge WAP confiscations when I worked in the business where some :rude:genius put a wireless router on my former employer's network and we deal with a rouge DHCP server that's also NATing.

And people wonder why those of us (formerly) in the business are such curmudgeons.
 
And people wonder why those of us (formerly) in the business are such curmudgeons.
Ever seen what happens when some administrative drone decides to hookup a hub (yes, a hub, not a switch) to a full-duplex switch port because he needs to connect his laptop? He managed to take down the entire network for that department. Then started complaining about how bad network management was for mismanaging the network. Sigh.
 
Ever seen what happens when some administrative drone decides to hookup a hub (yes, a hub, not a switch) to a full-duplex switch port because he needs to connect his laptop?
Yes. I've seen auto negotiation failures and duplex mismatch errors and enough collisions to open up a national chain of auto body shops.

I've done more than my share of network loop busting. I rapidly became an expert at network loop isolation if STP didn't take care of it. Since we were running Macs and PCs, we had to run STP in portfast or ports in host mode on our Cisco switches for everything to function properly.

The running joke in my former employer's department unit that took care of the LAN and WAN was "Loope (pronounced Lupe), you've got some splaining to do!" (A variation of "Lucy, some splaining to do!" from "I Love Lucy.") If you're not in the USA and know some vintage black & white TV shows, you won't get the reference.

I've had drones plug two connections of a hub or miniswitch that auto crossovers into a switch or another hub thinking they could have some magical form of LACP. This was before the IEEE standard and where Cisco FEC and Intel adapter teaming were barely seeing the light of day. Depending on at what evolutionary generation my former employer's remote site was in, it would either take down from a portion of an IDF or perhaps the entire remote site.

I'm sure we could both write a tech support horror anthology called, "Tales From The Helpdesk." :cool:
 
Back
Top