DaemonForums  

Go Back   DaemonForums > OpenBSD > OpenBSD Security

OpenBSD Security Functionally paranoid!

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 28th August 2024
boba3331 boba3331 is offline
New User
 
Join Date: Aug 2024
Posts: 3
Default PF configuration. Need help with VPN and automatic startup

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?

Code:
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.
Reply With Quote
  #2   (View Single Post)  
Old 28th August 2024
J65nko J65nko is offline
Administrator
 
Join Date: May 2008
Location: Budel - the Netherlands
Posts: 4,164
Default

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 )
Code:
     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:
Code:
    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)
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump
Reply With Quote
  #3   (View Single Post)  
Old 29th August 2024
boba3331 boba3331 is offline
New User
 
Join Date: Aug 2024
Posts: 3
Default

Quote:
Originally Posted by J65nko View Post
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 )
Code:
     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:
Code:
    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)

Quote:
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! ^_^

Quote:
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?

Quote:
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.

Quote:
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.
Reply With Quote
  #4   (View Single Post)  
Old 29th August 2024
J65nko J65nko is offline
Administrator
 
Join Date: May 2008
Location: Budel - the Netherlands
Posts: 4,164
Default

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 :
Code:
pass out quick inet
pass in on { $wired $wifi } inet
That is different from your version:
Code:
    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
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump
Reply With Quote
  #5   (View Single Post)  
Old 30th August 2024
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 8,032
Default

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:
Code:
block return all
pass out
pass proto tcp from any to (self) port 22
Reply With Quote
  #6   (View Single Post)  
Old 31st August 2024
boba3331 boba3331 is offline
New User
 
Join Date: Aug 2024
Posts: 3
Default

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?

Quote:
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. =^_^=

Quote:
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.



Quote:
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.
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
OpenBSD automatic disklabel allocation J65nko Guides 0 22nd February 2016 01:50 PM
Automatic heat shutdown. Martillo NetBSD General 2 30th May 2015 04:45 PM
tmux disable automatic resize Carpetsmoker General software and network 7 25th June 2009 10:54 PM
Automatic Mount for Devices/Filesystems vermaden FreeBSD General 11 12th June 2008 04:55 AM
Automatic Thread Subscription When Posting? JMJ_coder Feedback and Suggestions 6 6th May 2008 03:20 AM


All times are GMT. The time now is 10:19 AM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick