1

Why can't I create new network connections after enabling PF with a simple custom ruleset using pfctl -f?

I'm reading the official FAQ tutorial for OpenBSD's PF firewall, also used in macOS.

I've a single network interface en0, but after loading the my custom ruleset (sudo pfctl -ef ~/pf.conf), I cannot create new connections:

# block all traffic by default
block all

# allow outgoing traffic
pass out on en0 inet proto { tcp, udp } from any to any keep state

The loaded rules:

$ sudo pfctl -s rules
No ALTQ support in kernel
ALTQ related functions disabled
block drop all
pass out on en0 inet proto tcp all flags S/SA keep state
pass out on en0 inet proto udp all keep state

I know that pass rules imply keep state, so the target host will be able to answer and complete the TCP handshake.

Why doesn't it work?

Logs (as suggested by @dan):

11:38:57.252593 IP localhost.54219 > localhost.domain: 25416+ AAAA? tweak.dk. (26)
11:38:57.252653 IP localhost.64032 > localhost.domain: 49819+ A? tweak.dk. (26)
11:38:57.258578 IP localhost.57029 > localhost.domain: 60542+ AAAA? storage.tweak.dk. (34)
11:38:57.258636 IP localhost.63731 > localhost.domain: 1707+ A? storage.tweak.dk. (34)
11:38:57.378386 IP localhost.56727 > localhost.domain: 65417+ AAAA? clients1.google.com. (37)
11:38:57.378522 IP localhost.62210 > localhost.domain: 139+ A? clients1.google.com. (37)
11:38:57.443665 IP 192.168.0.2.34813 > broadcasthost.faximum: UDP, length 173
11:38:57.501016 IP localhost.62183 > localhost.domain: 11629+ AAAA? clients1.google.com. (37)
11:38:57.501147 IP localhost.53388 > localhost.domain: 42774+ A? clients1.google.com. (37)
11:38:57.511827 IP localhost.62420 > localhost.domain: 38225+ AAAA? clients1.google.com. (37)
11:38:57.511887 IP localhost.64524 > localhost.domain: 15042+ A? clients1.google.com. (37)
11:38:57.604447 IP localhost.59068 > localhost.domain: 13668+ AAAA? clients1.google.com. (37)
11:38:57.604519 IP localhost.51720 > localhost.domain: 55562+ A? clients1.google.com. (37)
11:38:57.693499 IP localhost.56993 > localhost.domain: 39058+ AAAA? init-p01st.push.apple.com. (43)
11:38:57.693545 IP localhost.57235 > localhost.domain: 27525+ A? init-p01st.push.apple.com. (43)
11:38:57.848208 IP localhost.61766 > localhost.domain: 22338+ AAAA? clients1.google.com. (37)
11:38:57.848280 IP localhost.54073 > localhost.domain: 33542+ A? clients1.google.com. (37)
11:38:58.037646 IP localhost.64422 > localhost.domain: 24380+ AAAA? clients1.google.com. (37)
11:38:58.037706 IP localhost.60153 > localhost.domain: 10848+ A? clients1.google.com. (37)
11:38:58.255389 IP localhost.54219 > localhost.domain: 25416+ AAAA? tweak.dk. (26)
11:38:58.255440 IP localhost.64032 > localhost.domain: 49819+ A? tweak.dk. (26)
11:38:58.259328 IP localhost.57029 > localhost.domain: 60542+ AAAA? storage.tweak.dk. (34)
11:38:58.259380 IP localhost.63731 > localhost.domain: 1707+ A? storage.tweak.dk. (34)
11:38:58.362581 IP localhost.63716 > localhost.domain: 6695+ AAAA? clients1.google.com. (37)
11:38:58.362662 IP localhost.57058 > localhost.domain: 1829+ A? clients1.google.com. (37)
11:38:58.457064 IP localhost.60834 > localhost.domain: 35607+ AAAA? clients1.google.com. (37)
11:38:58.457124 IP localhost.50331 > localhost.domain: 18857+ A? clients1.google.com. (37)
11:38:58.672209 IP 192.168.0.158 > 224.0.0.251: igmp v2 report 224.0.0.251
11:38:58.994741 IP localhost.57453 > localhost.domain: 12397+ AAAA? api-glb-bln.smoot.apple.com. (45)
11:38:58.994777 IP localhost.51068 > localhost.domain: 22480+ A? api-glb-bln.smoot.apple.com. (45)
11:38:59.030947 IP localhost.58518 > localhost.domain: 37923+ A? clients4.google.com. (37)
11:38:59.460793 IP localhost.60834 > localhost.domain: 35607+ AAAA? clients1.google.com. (37)
11:38:59.460846 IP localhost.50331 > localhost.domain: 18857+ A? clients1.google.com. (37)
11:39:00.258957 IP localhost.54219 > localhost.domain: 25416+ AAAA? tweak.dk. (26)
11:39:00.259010 IP localhost.64032 > localhost.domain: 49819+ A? tweak.dk. (26)
11:39:00.260138 IP localhost.57029 > localhost.domain: 60542+ AAAA? storage.tweak.dk. (34)
11:39:00.260199 IP localhost.63731 > localhost.domain: 1707+ A? storage.tweak.dk. (34)
11:39:00.413401 IP 192.168.0.2.34813 > broadcasthost.faximum: UDP, length 173
Shuzheng
  • 1,491

2 Answers2

1

Debugging basics

To help you progress with PF, I advise you to create the special interface pflog with:

/usr/bin/sudo ifconfig pflog0 create

improve, for a short debugging time, your pf.conf with:

block log all

and next start to spy what is blocked with:

/usr/bin/sudo tcpdump -i pflog0

Choice of IP protocols

Before trying to write your own rule set, decide if you want to use IPv4, IPv6 or both and configure your network interface (en0) accordingly. I wouldn't recommand to start with the last configuration which is already a nightmare to troubleshoot network problems (DNS, routing…). (Concerning this "choice of IP protocols", beware of the cursed Automatic network configuration which does turn everything possible on so as to be sure the dummies will always find a path to the Internet.)

As soon as you switch from IPv4 to IPv6, mind to change all your pass...inet rules into pass...inet6 rules. Otherwise you will be in a perfect cul de sac.

Debugging pfctl

Use the pfdump.sh from this top level answer on pfctl - howto add an anchor and make it active / load it

Always keep a recovery path

2 more pieces of advice:

  1. Always keep a backup of /etc/pf.conf so as to be able to restore a working state with:

    pfctl -f /etc/pf.conf

  2. Always start your tests on a machine you have a physical access to (I mean not through ssh or ARD).

dan
  • 12,177
  • 8
  • 58
  • 136
  • Thank you, Dan. Can it be that loading my rules disables Apple's anchors? What are they? – Shuzheng Jul 21 '19 at 05:52
  • Also, can you see anything wrong with my rules by eye inspection? Shouldn't they be loaded with -f? – Shuzheng Jul 21 '19 at 06:14
  • Yes you removed the system anchors. They are defined within /etc/pf.conf . [return] 2. Yes: ARP is dropped by block drop all.
    • – dan Jul 21 '19 at 08:04
  • Ohh, I see. Do you know why it appears that the system anchors contain no rules? sudo pfctl -a com.apple/200.AirDrop -sr and sudo pfctl -a com.apple/250.ApplicationFirewall -sr both show no rules. – Shuzheng Jul 21 '19 at 09:26
  • Also, block all log should be block log all. I don't believe this has to do with ARP. PF works on layer 3 and 4, and arp is not a supported proto? I've included logs. It seems that all DNS queries are on localhost - can you clarify :) ? – Shuzheng Jul 21 '19 at 09:47
  • Yes, thanks to your 1st debugging log I discovered that your lo0 local interface is on IPv6. Your pass...inet6 rules are missing. I improved my answer since this is a very common problem for users keeping the Automatic network configuration. Apple should have named it Network for the dummies :).
    • – dan Jul 21 '19 at 13:08
  • Thank you. Fixed. Your DNS queries go through localhost as configured by the way Apple decided to route all name resolution through a local proxy which is the process ps ax | egrep '[ /](PID|mDNS)'.
    • – dan Jul 21 '19 at 13:14