Solved Differences between "pfctl -f" and service "pf restart" - dnsmasq timing out?

[darkpixel]

I get the feeling that I'm missing something with pf.

I have dns/dnsmasq installed and running on my router. /etc/resolv.conf is pointed to 127.0.0.1. When the box boots up initially and pf is loaded, I can run host dilbert.com and get a valid result.

If I make any firewall changes unrelated to DNS (i.e. set up a port forward or add an IP to my 'trusted' IP list) and then run pfctl -f /etc/pf.conf, DNS resolution stops working.

To get DNS working again, I have to run pfctl -f /etc/pf.conf; service dnsmasq restart. That may look weird--but I have to run pfctl first followed by restarting dnsmasq within ~3 seconds or it doesn't work.

Alternatively I can just run service pf restart (which disconnects my SSH session and any traffic passing through the router) and then when I reconnect DNS is working again.

My pf config isn't very long, but the relevant parts are:

scrub in all fragment reassemble no-df max-mss 1440
set skip on lo  # This should cause all traffic on 127.0.0.1 (i.e. resolv.conf) to be allowed

nat on $wan_iface from $lan_subnet to any -> ($wan_iface:0)
nat on $wan_iface from $guest_subnet to any -> ($wan_iface:0)

block all
pass out quick inet from self # This should allow all firewall traffic out (wan, lan, etc...which should include DNS traffic)

There are a handful of other rules dealing with allowing traffic from trusted IPs to access a few services on the box and behind the firewall, but nothing to do with DNS.

Am I missing something about how I should be reloading pf and related network services?

 

[mickey]

I remember that there has been a problem associated with interface groups some time back.
Try whether changing this line:

set skip on lo  # This should cause all traffic on 127.0.0.1 (i.e. resolv.conf) to be allowed

to the following makes any difference in behaviour.

set skip on lo0

 

[darkpixel]

Thanks mickey that was it. It's been driving me nuts for weeks.

 

[SirDice]

Use service pf reload instead. A restart will "stop" (i.e. disable and unload PF), then "start" (load the module and ruleset). Because it's stopped first your current connections are killed.

 

[Kristof Provost]

Thats not quite true. A stop will not unload the pf module. It will only disable pf. A 'start' will flush all existing state. In most cases you'd want to do a reload (or resync) to load new rules without killing existing states.

And remember that existing states keep using whatever rule created them. If you've closed a port you may need to restart (i.e. flush existing states) to kill existing connections to that port.