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

IPFW, PF, IPF (but not limited) related discussion

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

Postby mastier » 24 Mar 2011, 10:19

What happens if :
Code: Select all
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: Select all
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 ? :\
mastier
Junior Member
 
Posts: 17
Joined: 06 Dec 2010, 21:27

Postby DutchDaemon » 24 Mar 2011, 18:40

PF can handle tens of thousands of entries in dozens of tables without a hitch. It's all streamlined and optimized internally.
User avatar
DutchDaemon
Old Fart
 
Posts: 10463
Joined: 16 Nov 2008, 20:17
Location: The Netherlands

Postby gkontos » 24 Mar 2011, 20:27

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.
Powered by BareBSD
User avatar
gkontos
Senior Member
 
Posts: 1370
Joined: 09 Dec 2009, 08:36
Location: Polidendri, GR

Postby mastier » 25 Mar 2011, 06:40

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: Select all
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.
mastier
Junior Member
 
Posts: 17
Joined: 06 Dec 2010, 21:27

Postby mastier » 25 Mar 2011, 08:42

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: Select all
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
Junior Member
 
Posts: 17
Joined: 06 Dec 2010, 21:27

Postby gkontos » 25 Mar 2011, 12:59

mastier wrote: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.
Powered by BareBSD
User avatar
gkontos
Senior Member
 
Posts: 1370
Joined: 09 Dec 2009, 08:36
Location: Polidendri, GR

Postby mastier » 25 Mar 2011, 14:40

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.
mastier
Junior Member
 
Posts: 17
Joined: 06 Dec 2010, 21:27

Postby kpa » 26 Mar 2011, 13:47

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
MFC'd
 
Posts: 3387
Joined: 05 Jul 2010, 13:19
Location: People's Technocratic Republic of Finland

Postby gkontos » 26 Mar 2011, 14:25

kpa wrote: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.
Powered by BareBSD
User avatar
gkontos
Senior Member
 
Posts: 1370
Joined: 09 Dec 2009, 08:36
Location: Polidendri, GR

Postby mastier » 27 Mar 2011, 08:52

Yes, I could agree with you, basically, beacause using [FILE]nat quick on[/FILE] 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.
mastier
Junior Member
 
Posts: 17
Joined: 06 Dec 2010, 21:27


Return to Firewalls

Who is online

Users browsing this forum: Yahoo [Bot] and 0 guests