Need suggestions on improving my pf rules

[trystan]

i wish to have all internet traffic to go through my vpn; when my vpn is disconnected, all internet traffic can not go out of my workstation/desktop (not server).

here's my pf rules. would appreciate if you can suggest improvements to them:

wan="em0"
vpn="tun0"
block all
block in log all
set block-policy drop
set skip on lo
antispoof for $wan inet
block in from urpf-failed to any
block inet proto icmp icmp-type echoreq
block out inet6 all
block in inet6 all
pass out on $wan proto tcp from any to a.b.c.d port 443 modulate state
pass out on $vpn proto tcp from any to any port 80 modulate state
pass out on $vpn proto tcp from any to any port 443 modulate state
pass out on $vpn proto udp from any to any port 53 modulate state

where a.b.c.d. is the IP address of the remote vpn server

[ocicat]

Originally Posted by trystan

...here's my pf rules. would appreciate if you can suggest improvements to them:

Welcome!

In addition to posting your rule set, please provide system information as well. ie.

$ sysctl kern.version

[trystan]

Originally Posted by ocicat

please provide system information as well. ie.

$ sysctl kern.version

kern.version=OpenBSD 5.6-current (GENERIC.MP) #525:Mon Nov 3 19:42:34 MST 2014 
deraadt@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

[jggimi]

Hello, and welcome!

1. Your blocks of IPv6 are moot, due to the prior block all. And, since you're running a recent -current system, IPv6 is disabled by default. It was disabled with 5.6.
2. Domain (port 53) traffic with greater than 512-byte blocks uses TCP. If your DNS requests ever result in a large block response, those will fail since you permit only UDP traffic on that port.

[trystan]

@ jggimi

Thanks for your feedback.

Below is the modified set of rules. Your feedback is appreciated.

wan="em0"
vpn="tun0"
set block-policy drop
block in log all
block all
set skip on lo
antispoof for $wan inet
block in from urpf-failed to any
block in from no-route to any
block inet proto icmp icmp-type echoreq
pass out on $wan proto udp from any to a.b.c.d. port 443 keep state
pass out on $vpn proto tcp from any to any port 80 keep state
pass out on $vpn proto tcp from any to any port 443 keep state
pass out on $vpn proto udp from any to any port 53 keep state

where a.b.c.d. is the IP address of the remote vpn server

[jggimi]

1. For readability, you could combine rules with lists. For example, your two rules:

pass out on $vpn proto tcp from any to any port 80 modulate state
pass out on $vpn proto tcp from any to any port 443 modulate state

could become the single rule:

pass out on $vpn proto tcp from any to any port {80 443} modulate state

.
2. These four rules are unnecessary, since they block specific incoming packets. Your block all rule above them already covers all incoming (and outgoing) packets:

antispoof for $wan inet
block in from urpf-failed to any
block in from no-route to any
block inet proto icmp icmp-type echoreq

With this ruleset, the only incoming packets that will pass must be part of a previously established state, or for your UDP traffic, within a "state" determined by timeout.

3. Domain Name resolution packets greater than 512-bytes will be blocked, since you only pass UDP protocol, as I mentioned previously.

[J65nko]

block in log all
block all

Because in pf the last matching rule is applied, I would replace that with a simple

block log all

Re: DNS

If a DNS reply is too large for an UDP packet, the DNS server sets the "truncated" bit in the UDP reply. This is a hint for the receiver to re-issue the DNS request but now over TCP.

So for DNS you should have:

pass out on $vpn proto tcp from any to any port 53
pass out on $vpn proto udp from any to any port 53

BTW If you have ntpd(8) running you should also allow UDP for port 123

[trystan]

@ jggimi

In my earlier version, I used "modulate state" while in the second, I used "keep state". Which is preferable?

J65nko suggested

pass out on $vpn proto tcp from any to any port 53
pass out on $vpn proto udp from any to any port 53

Can I combine the above two rules with lists (per your recommendation)? as in:

pass out on $vpn proto {tcp udp} from any to any port 53

[trystan]

Originally Posted by J65nko

block log all

pass out on $vpn proto tcp from any to any port 53
pass out on $vpn proto udp from any to any port 53

BTW If you have ntpd(8) running you should also allow UDP for port 123

Thanks for your feedback and tips

[jggimi]

Originally Posted by trystan

Which is preferable?

The modulate stateful option is not needed with a BSD workstation. It's purpose is to protect OSes that do not randomize TCP ISN values. See State Modulation in pf.conf(5).

Can I combine the above two rules with lists (per your recommendation)?

Yes. When lists are used, PF will expand them to multiple rules, which you can see with # pfctl -sr. Lists make your ruleset easier to understand.

[trystan]

@ jggimi

Incorporating both your and J65nko's feedback my pf rules should like like:

wan="em0"
vpn="tun0"
set block-policy drop
block log all
set skip on lo
pass out on $wan proto udp from any to a.b.c.d port 443 keep state
pass out on $vpn proto tcp from any to any port {80 443} keep state
pass out on $vpn proto {tcp udp} from any to any port 53 keep state

After my workstation is connected to a remote VPN server--perhaps in a different country--I launch my pf rules that will ensure all internet traffic goes through the VPN tunnel. Am I right to state that FTP and ping will also tunnel through my VPN connection?

[trystan]

@ jggimi

In

pass out on $wan proto udp from any to a.b.c.d port 443 keep state

1. Can a.b.c.d consists of hostnames instead of resolved IP addresses?

2. Suppose I have a bunch of 15 resolved IP addresses of remote VPN servers such as

1.1.1.1
2.2.2.2
3.3.3.3
4.4.4.4....
...........
15.15.15.15

Can I put them as a list? as in

pass out on $wan proto udp from any to {1.1.1.1 2.2.2.2 3.3.3.3 4.4.4.4 5.5.5.5 up to and including 15.15.15.15} port 443 keep state

[jggimi]

Originally Posted by trystan

After my workstation is connected to a remote VPN server--perhaps in a different country--I launch my pf rules that will ensure all internet traffic goes through the VPN tunnel.

No, that's not quite correct. You have three permitted types of outbound traffic:

1. UDP traffic to a.b.c.d:443, your VPN.
2. TCP traffic to anywhere with destination ports 80 or 443, typically to connect to servers with HTTP and HTTPS, respectively.
3. TCP and UDP traffic to anywhere with destination port 53, typically Domain traffic.

Am I right to state that FTP and ping will also tunnel through my VPN connection?

I assume your VPN is OpenVPN. I haven't used it in decades, and cannot answer regarding its specifics. I assume that, if configured to do so, it will tunnel your ICMP protocol traffic (ping) as well as your TCP traffic. FTP uses multiple TCP sessions to communicate and may have some quirks; if so your OpenVPN documentation should inform you if there are special provisioning requirements.

Originally Posted by trystan

1. Can a.b.c.d consists of hostnames instead of resolved IP addresses?

Yes, but this is not best practice.

Domain names are resolved only when the ruleset is loaded, and never inspected again. At boot time, name resolution may not be possible through the network. (e.g.: /etc/hosts file lookup may be required for resolution, rather than a nameserver on the network.)

If an external nameserver has been compromised, you may not be reaching the VPN gateway you intended.

2. Suppose I have a bunch of 15 resolved IP addresses...can I put them as a list?

Yes, but for IP addresses, tables are much more efficient. Unlike lists, which expand into separate rules at load time, tables are blocks of IP addresses, which are managed as a single entity. They can be loaded from files, and managed "live" by rules or by pfctl(8) commands. For more information, please see the Tables chapter of the PF User's Guide.

[trystan]

No, that's not quite correct.

jggimi, I don't quite get it.

2. TCP traffic to anywhere with destination ports 80 or 443, typically to connect to servers with HTTP and HTTPS, respectively.

is taken care of by the rule below:

pass out on $vpn proto tcp from any to any port {80 443} keep state

3. TCP and UDP traffic to anywhere with destination port 53, typically Domain traffic.

is taken care of by:

pass out on $vpn proto {tcp udp} from any to any port 53 keep state

I assume your VPN is OpenVPN.

Yes, that's correct.

[jggimi]

Originally Posted by trystan

jggimi, I don't quite get it.

I'll try to clarify. You have three pass rules:

1. VPN traffic.
2. HTTP/HTTPS traffic, outside your VPN tunnel.
3. Domain traffic, outside your VPN tunnel.

Your assumption that all traffic must traverse the VPN is incorrect.

[trystan]

@jggimi

If I remove the below rules:

pass out on $vpn proto tcp from any to any port {80 443} keep state
pass out on $vpn proto {tcp udp} from any to any port 53 keep state

doing so will eliminate:

2. HTTP/HTTPS traffic, outside your VPN tunnel.
3. Domain traffic, outside your VPN tunnel.

Am I doing it right?

[J65nko]

In OpenBSD port of OpenVPN revisited I posted to method to verify whether DNS requests are passing through the VPN tunnel.

I will install OpenVPN and check what is a proper pf.conf ruleset

[jggimi]

Originally Posted by trystan

Am I doing it right?

I don't know what is right. I don't know OpenVPN's requirements, and I can only tell you what your rules pass or block.

Originally Posted by J65nko

I will install OpenVPN and check ...

That's better help than I can provide.

[trystan]

Originally Posted by jggimi

I don't know what is right. I don't know OpenVPN's requirements, and I can only tell you what your rules pass or block.

Thanks jggimi for your frank answer.

Can you let me know if I need to add more rules to improve my pf.conf?

[jggimi]

Originally Posted by trystan

Can you let me know if I need to add more rules to improve my pf.conf?

You have initiated what is called a default block ruleset. You're blocking everything, then citing specific packets that are allowed to pass. That is a best practice!

Another best practice is to follow J65nko's advice in every one of his posts: use logging, and watch PF pass or block packets with tcpdump(8). You can then adjust rules as needed. Guidance can be found in the Logging chapter of the PF User's Guide.