Nat & Filtering in PF - what happens if...

What happens if :
Code:
table <goodguys> {10.7.0.1, 10.7.0.2}

nat on $ext_if from 10.7.0.1/24 to !10.7.0.1/24 -> $nat_ip

pass out from <goodguys> to any keep state
block log all

My question is, because NAT must be before filtering. If someone in network will set his ip address as 10.7.0.10, will it still be nated ? Is it a better way to do it ?
Like
Code:
nat on $ext_if from <goodguys> to !10.7.0.1/24 -> $nat_ip

But what will happen if <goodguys> is a table of, let's say 700 users ? (and correspondly bigger subnet , of course). Will it have a big impact on performance ? :\
 
PF can handle tens of thousands of entries in dozens of tables without a hitch. It's all streamlined and optimized internally.
 
Generally speaking and regardless of the firewall make.
We usually NAT (PAT in this case) subnets and not single IP addresses. In your case if you want to use PAT for 700 addresses you might run into other issues like running out of available ports. You will also create unnecessary burden to the firewall. Try limiting one subnet per one NAT IP. You will find it easier to manage later.
 
Yeah, you are right. I got separated in vlans

like 10.1.1.0/24 is vlan350, 10.1.2.0/24 is vlan351.

So basically I could make nat on each gateway like:

Code:
nat on vlan350 from 10.1.1.0/24 to !10.1.1.0/24 -> 10.1.1.254
nat on vlan351 from 10.1.2.0/24 to !10.1.2.0/24 -> 10.1.2.254

But what about altq? Can I make altq per vlan to shape download? I found not conclusive information on the net.
 
Sure, these 700 users are in 8 seperated vlans :D

So in situation these, having vlan350, subnet 10.1.1.0/24 and vlan351, subnet 10.1.2.0/24 there's solution:

Code:
table <localnet> {10.1.1.0/24 10.1.2.0/24}
nat on vlan350 from 10.1.1.0/24 to !<localnet> -> 10.1.1.254
nat on vlan351 from 10.1.2.0/24 to !<localnet> -> 10.1.2.254

But answer me simply yes or no, if the whole subnet is nat'ed will the packet will be first pass through to the outside world before being blocked in the filtering rules.
 
mastier said:
But answer me simply yes or no, if the whole subnet is nated will the packet will be first pass through to the outside world before being blocked in the filtering rules.
Short answer=NO

In PF NAT rules are processed before filtering rules. However, this doesn't change the order in which network firewalls (stateful) work. RAN (Routing, access, NAT) is the order in which every layer 4 stateful network packet filter engine works.
 
Lovely, this is the answer I wanted to hear. I was wondering if the nat is in some way distinguish for firewall like pass quick, that stops the rule checking process at that point.
 
I think the order of evaluation depends on the direction of the packet. For outgoing packets (those leaving via an interface) the situation is like gkontos said, routing->access->nat but for incoming packets it's the other way around nat(rdr in fact)->access->routing.
 
kpa said:
I think the order of evaluation depends on the direction of the packet. For outgoing packets (those leaving via an interface) the situation is like gkontos said, routing->access->nat but for incoming packets it's the other way around nat(rdr in fact)->access->routing.
Either way, if there is no route then the packet is being rejected, or at least it should. You may wonder how can an incoming packet have the wrong routing information. Imagine a large corp with many routers/firewalls. It is possible that somewhere in the middle information is wrong. So, routing is always checked first to save cpu & memory. Then comes the packet filter rule or access list or however the firewall calls it. The incoming packet mast much an acl. Finally NAT take into account. Remember that NAT is optional. Some security specialists even argue if a firewall should be doing that at all.
My original disagreement was based in the fact that NAT should not be used to filter traffic. It is true that you can use NAT to block traffic but you shouldn't. The firewall expects NAT to be configured properly and filter traffic according to the packet filtering policy.
 
Yes, I could agree with you, basically, beacause using nat quick on you may speed up processing of at least allowed hosts, but okay filtering by nat looks a little awkward.

I found once a picture with packet dealing BSD with pf, but cannot find it again. Either way the case seems to be solved. Anyone else willing to join the discussion, but I set the topic as Solved.
 
Back
Top