PF configuration. Need help with VPN and automatic startup

[boba3331]

Hello,

I need help with my firewall and VPN. Many people here have faced similar tasks, but I haven't gleaned much that could solve my problem. I know how to search on Google, but I couldn't find anything worthwhile and comprehensive. So, let's get to the point.

Here’s my pf configuration. I managed to get it working somewhat as I need it to. However, it lacks a kill switch function for the VPN. Ideally, I would like the internet connection on the router to remain active, but for the computers on the local network to lose internet access if the VPN drops.

Additionally, is everything in my configuration set up correctly? I took the standard router configuration from the official OpenBSD website; can you clearly see if I messed something up?

Lastly, how can I make the VPN start automatically when the router is turned on?

wired = "re0"
vpn = "tun0"
table <martians> { 0.0.0.0/8 10.0.0.0/8 127.0.0.0/8 169.254.0.0/16     \
                  172.16.0.0/12 192.0.0.0/24 192.0.2.0/24 224.0.0.0/3 \
                  192.168.0.0/16 198.18.0.0/15 198.51.100.0/24        \
                  203.0.113.0/24 }
set block-policy drop
set loginterface egress
set skip on lo0
match in all scrub (no-df random-id max-mss 1440)
match out on egress inet from !(egress:network) to any nat-to (egress:0)
match out on $vpn inet from !(egress:network) to any nat-to ($vpn:0)
antispoof quick for { egress $wired }
block in quick on egress from <martians> to any
block return out quick on egress from any to <martians>
block all
pass out quick inet
pass in on { $wired } inet
pass out on $wired from ($vpn:network) to any
pass in on egress inet proto tcp from any to (egress) port { 80 443 } rdr-to 192.168.1.2

P.S. I've been struggling with this problem for five days. It might seem funny to some, but these configuration tweaks have been quite challenging for me. A couple of days ago, I created a similar thread on Reddit, but it seems it didn't pass moderation due to my newly created account.

[J65nko]

How about first reordering and grouping your rules by direction (in/out), interface (wired, egress) etc? That would make things easier to understand ...
My suggestion (hoping I did not accidentally leave out any rule )

     1	wired = "re0"
     2	vpn = "tun0"
     3	table <martians> { 0.0.0.0/8 10.0.0.0/8 127.0.0.0/8 169.254.0.0/16     \
     4	                  172.16.0.0/12 192.0.0.0/24 192.0.2.0/24 224.0.0.0/3 \
     5	                  192.168.0.0/16 198.18.0.0/15 198.51.100.0/24        \
     6	                  203.0.113.0/24 }
     7	
     8	set block-policy drop
     9	set loginterface egress
    10	set skip on lo0
    11	
    12	antispoof quick for { egress $wired }
    13	
    14	# --- OUTGOING
    15	block return out quick on egress from any to <martians>
    16	
    17	match out on egress inet from !(egress:network) to any nat-to (egress:0)
    18	match out on $vpn inet from !(egress:network) to any nat-to ($vpn:0)
    19	pass  out quick inet
    20	pass  out on $wired from ($vpn:network) to any
    21	block all
    22	
    23	# --- INCOMING
    24	
    25	# -- egress
    26	match in all scrub (no-df random-id max-mss 1440)
    27	block in quick on egress from <martians> to any
    28	
    29	pass  in on egress inet proto tcp from any to (egress) port { 80 443 } rdr-to 192.168.1.2
    30	
    31	# -- wired
    32	pass  in on { $wired } inet

Problematic:

    19	pass  out quick inet
    20	pass  out on $wired from ($vpn:network) to any

The quick in line 19 will tell pf to unconditionally pass out all inet (IPV4) traffic. Line 20 will only apply to non-inet packets (IPV6)

[boba3331]

Originally Posted by J65nko

How about first reordering and grouping your rules by direction (in/out), interface (wired, egress) etc? That would make things easier to understand ...
My suggestion (hoping I did not accidentally leave out any rule )

     1	wired = "re0"
     2	vpn = "tun0"
     3	table <martians> { 0.0.0.0/8 10.0.0.0/8 127.0.0.0/8 169.254.0.0/16     \
     4	                  172.16.0.0/12 192.0.0.0/24 192.0.2.0/24 224.0.0.0/3 \
     5	                  192.168.0.0/16 198.18.0.0/15 198.51.100.0/24        \
     6	                  203.0.113.0/24 }
     7	
     8	set block-policy drop
     9	set loginterface egress
    10	set skip on lo0
    11	
    12	antispoof quick for { egress $wired }
    13	
    14	# --- OUTGOING
    15	block return out quick on egress from any to <martians>
    16	
    17	match out on egress inet from !(egress:network) to any nat-to (egress:0)
    18	match out on $vpn inet from !(egress:network) to any nat-to ($vpn:0)
    19	pass  out quick inet
    20	pass  out on $wired from ($vpn:network) to any
    21	block all
    22	
    23	# --- INCOMING
    24	
    25	# -- egress
    26	match in all scrub (no-df random-id max-mss 1440)
    27	block in quick on egress from <martians> to any
    28	
    29	pass  in on egress inet proto tcp from any to (egress) port { 80 443 } rdr-to 192.168.1.2
    30	
    31	# -- wired
    32	pass  in on { $wired } inet

Problematic:

    19	pass  out quick inet
    20	pass  out on $wired from ($vpn:network) to any

The quick in line 19 will tell pf to unconditionally pass out all inet (IPV4) traffic. Line 20 will only apply to non-inet packets (IPV6)

How about first reordering and grouping your rules by direction (in/out), interface (wired, egress) etc? That would make things easier to understand ...
My suggestion (hoping I did not accidentally leave out any rule )

Oh, I read somewhere that the rules in pf are applied sequentially from top to bottom, with the last rule being the most important, as I understood. Your example is indeed easier to understand. Thank you! ^_^

The quick in line 19 will tell pf to unconditionally pass out all inet (IPV4) traffic.

Strange; I took the complete configuration from the official documentation. What’s the point of specifying firewall security rules in the official ready-made template and then overriding them?

Line 20 will only apply to non-inet packets (IPV6)

Oh, that's exactly one of those lines that I added myself . To be honest, I have no idea how to get out of this situation right now. I'll try deleting those two lines and see what happens.

You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump

I came across some binary logs, decided that I wasn't getting anywhere, and abandoned the endeavor. You motivated me to give it another try. The truth is, I don't have an example of what I should pay attention to and what I should compare it with.


PS I apologize for the formatting of my response; I haven't fully figured out how things are done here.

[J65nko]

On detecting an incoming packet pf will only check the rules that deal with incoming packets. It will skip the rules for outgoing ones because they don't apply.

Daniel Hartmeier, the original architect of pf, in an old paper called this a skip step. When you alternate in and out rules, pf has to take many of these skip steps. I prefer pf to only take giant skip steps by ordering and grouping the rules by direction (in/out) and then by interface.

Nowadays pf seems to do this ordering (optimizing) behind the scenes, but I kept this habit, because for the human pf rule writer it is easier to understand.

If you use pfctl -vvvsr you can see the rules with statistics; how many times a rule has been evaluated, the number of packets and the size of the oackets. It will also show how pf has re-ordered the rules.

From https://www.openbsd.org/faq/pf/example1.html#pf :

pass out quick inet
pass in on { $wired $wifi } inet

That is different from your version:

    19	pass  out quick inet
    20	pass  out on $wired from ($vpn:network) to any

BTW there is no need to quote complete messages here. Unlike a mailing list it is easy to refer to a previous post. Just need some scrolling

[jggimi]

Hello, and welcome!

It can sometimes be helpful to keep the two laws of PF in mind whenever writing or reviewing rules:

1. The last matching rule wins.
2. Whenever the quick option is used, disregard law #1.

Because of this dichotomy, there are two schools of thought on how to use quick correctly:

• School A: Avoid quick.

• School B: Never use quick.

I'm among the School A folks, as I still have some systems with quick rules defined.

I find rule sets that don't use quick are much easier for me to comprehend. Without quick, the general rules naturally appear before the more specific rules, and the deeper into the rule set, the more specific the rules tend to become. For example, this small rule set first blocks everything, then passes all outbound traffic -- which will allow inbound for any established states -- and finally passes unsolicited traffic to destination tcp port 22, used by the sshd(8) server for remote shell access:

block return all
pass out
pass proto tcp from any to (self) port 22

[boba3331]

Hello everyone. Sorry for the long response; for almost all this time, I was trying to write rules for pf and studying articles about it. At one point, I even thought I was starting to understand. But harsh reality told me otherwise. On top of all the existing needs, I now have to install and configure tinyproxy. The setup itself isn't complicated, but guess what I ran into again?

When you alternate in and out rules, pf has to take many of these skip steps. I prefer pf to only take giant skip steps by ordering and grouping the rules by direction (in/out) and then by interface.

Thank you for this advice. I think it will save me a lot of time in the future, and it already makes it easier for me to understand. It's very difficult for me to grasp, as my work is not related to programming or system administration at all. =^_^=

That is different from your version:

Yes, you are right. Out of desperation, I was trying to find the right rule for the killswitch by trial and error. It turns out that it's not needed at all. At least, that's what I tend to believe at the moment based on the understanding I've developed over the past week.

I find rule sets that don't use quick are much easier for me to comprehend.

Thank you for the advice, I will remember it. It is indeed easier to understand, but as far as I can tell, it is more difficult to write and design, especially for me, since I don't know how to do any of this . I will need to work on this aspect in the future and move away from using quick rules.