Configure pf Firewall: Difference between revisions

From wiki
Jump to navigation Jump to search
imported>Jacob
No edit summary
imported>Jacob
No edit summary
Line 4: Line 4:
The fact that we use a private network range, also mean we have only one public available IP address to which all traffic initiated on the WAN wil be send. We therefore need to redirect the external traffic to the right host.<br>
The fact that we use a private network range, also mean we have only one public available IP address to which all traffic initiated on the WAN wil be send. We therefore need to redirect the external traffic to the right host.<br>
Furthermore we use queues to prioritise traffic, so our web side will be responsive and video will not be hampered by a large file transfer. Queues work on the WAN interface for the LAN → WAN traffic.<br>
Furthermore we use queues to prioritise traffic, so our web side will be responsive and video will not be hampered by a large file transfer. Queues work on the WAN interface for the LAN → WAN traffic.<br>
Lets start with the LAN → WAN traffic first.<br>
By using macros we are able to use only a few rules for a lot of different traffic. The major split used here is:
client_out ports, i.e. http, https
apps_out ports i.e. Dyn updater, Razor, dccproc
These will allow to have only 2 rules one at the LAN NIC and one at the WAN NIC.
pass in on $int_if proto tcp from $localnet to port $apps_out label "G IN tcp apps $srcaddr $dstaddr:$dstport ="
pass out on $ext_if proto tcp from ($ext_if) to !($ext_if) port $apps_out label "R OUT TCP apps $srcaddr to $dstaddr:$dstport =" queue (q_def, q_pri)
pass out on $ext_if proto tcp from ($ext_if) to !($ext_if) port $client_out label "R OUT TCP client to $srcaddr $dstaddr:$dstport =" queue (q_def, q_pri)
pass in on $int_if proto tcp from $localnet to port $client_out label "G IN tcp client $srcaddr $dstaddr:$dstport ="
pass in on $int_if proto tcp from $localnet to port $apps_out label "G IN tcp apps $srcaddr $dstaddr:$dstport ="
<br>
<br>
The above gives use a few challenges. If for instance we use the redirect rule with pass like so:
The above gives use a few challenges. If for instance we use the redirect rule with pass like so:
  <small>rdr pass on $ext_if proto tcp to $ext_if port $web_ports -> $web_server</small>
  <small>rdr pass on $ext_if proto tcp to $ext_if port $web_ports -> $web_server</small>
Line 16: Line 29:
So traffic is now flowing into WAN NIC through the firewall out of the LAN NIC.<br>
So traffic is now flowing into WAN NIC through the firewall out of the LAN NIC.<br>


The return traffic will need to be taken care of. Most of that is done at the
The return traffic will need to be taken care of. These
<br>
<br>
<br>
<br>
* [[Setup pf.conf file]]
* [[Setup pf.conf file]]

Revision as of 08:34, 5 June 2019

The philosophy we will use for the fire wall is that we split in 2 or 4 steps depending on if the traffic initiated outside WAN or RED side or the inside LAN or GREEN.
First of all we use a private network range on the LAN side. So we will need to use NAT to be able to communicate from the LAN to the WAN. Traffic initiated on the LAN will be send to the WAN destination using NAT. NAT will pickup the return traffic and translate it the the correct LAN host. The fact that we use a private network range, also mean we have only one public available IP address to which all traffic initiated on the WAN wil be send. We therefore need to redirect the external traffic to the right host.
Furthermore we use queues to prioritise traffic, so our web side will be responsive and video will not be hampered by a large file transfer. Queues work on the WAN interface for the LAN → WAN traffic.
Lets start with the LAN → WAN traffic first.
By using macros we are able to use only a few rules for a lot of different traffic. The major split used here is:

client_out ports, i.e. http, https
apps_out ports i.e. Dyn updater, Razor, dccproc

These will allow to have only 2 rules one at the LAN NIC and one at the WAN NIC. pass in on $int_if proto tcp from $localnet to port $apps_out label "G IN tcp apps $srcaddr $dstaddr:$dstport ="

pass out on $ext_if proto tcp from ($ext_if) to !($ext_if) port $apps_out label "R OUT TCP apps $srcaddr to $dstaddr:$dstport =" queue (q_def, q_pri)
pass out on $ext_if proto tcp from ($ext_if) to !($ext_if) port $client_out label "R OUT TCP client to $srcaddr $dstaddr:$dstport =" queue (q_def, q_pri)
pass in on $int_if proto tcp from $localnet to port $client_out label "G IN tcp client $srcaddr $dstaddr:$dstport ="
pass in on $int_if proto tcp from $localnet to port $apps_out label "G IN tcp apps $srcaddr $dstaddr:$dstport ="



The above gives use a few challenges. If for instance we use the redirect rule with pass like so:

rdr pass on $ext_if proto tcp to $ext_if port $web_ports -> $web_server

The return traffic will then go through the default queue. and not through for instance the web queue. We therefore will have a rdr and a pass rule like this.

rdr on $ext_if proto tcp to $ext_if port $web_ports -> $web_server 
pass in on $ext_if proto tcp from any to $web_server port $web_ports queue (q_web, q_pri)

The 1st rule will redirect the traffic to the right host.
The 2nd rule will pass the traffic through the WAN NIC into the firewall

The traffic is now in the firewall so we need to let it exit on the LAN NIC like this

pass out on $int_if proto tcp to $web_server port $web_ports

So traffic is now flowing into WAN NIC through the firewall out of the LAN NIC.

The return traffic will need to be taken care of. These