PF Why does reloading pf.conf kill my ssh session?

[japoc]

Hello,

each time I reload my pf.conf using the command:
pfctl -F all -f /etc/pf.conf
my ssh session dies. It does not just hang for a few seconds. It simply dies and I have to launch a new one. This happens even though both the old and the new configurations allow incoming connexion to the ssh port. This happens even if don't change my pf.conf at all.
This happens, for example, with such a pf.conf:

tcp_internet_out="{53, 80, 443, 123}"
udp_internet_out="{53}"
ext_if=em0
set skip on lo0
block in log (all)
block out log (all)
pass in quick on $ext_if inet proto tcp from any to ($ext_if) port 22
pass out quick on $ext_if inet proto tcp from ($ext_if) to any port $tcp_internet_out
pass out quick on $ext_if inet proto udp from ($ext_if) to any port $udp_internet_out
pass in quick on $ext_if inet proto icmp from any to ($ext_if) icmp-type echoreq

With this pf.conf, if I run
pfctl -F all -f /etc/pf.conf

my ssh session dies.

Is there a way to avoid that?

Thanks for your help.

 

[SirDice]

The -F all flushes all state tables, thereby killing the current state of your session. Just use pfctl -f /etc/pf.conf.

             -F nat        Flush the NAT rules.
             -F queue      Flush the queue rules.
             -F rules      Flush the filter rules.
             -F states     Flush the state table (NAT and filter).
             -F Sources    Flush the source tracking table.
             -F info       Flush the filter information (statistics that are
                           not bound to rules).
             -F Tables     Flush the tables.
             -F osfp       Flush the passive operating system fingerprints.
             -F all        Flush all of the above.

From pfctl(8).

 

[sko]

Just use pfctl -f /etc/pf.conf.

Just keep in mind: this won't apply new/changed rules to already established connections (or states). These will be handled with the previously applied rule until closed.

This might be a bit confusing or even frustrating - e.g. When adding NAT rules for a subnet/host that already tries to connect to the outside world (with its local, RFC 1918 IP), these states won't be affected and the host/network still can't reach the outside world.
For such scenarios, a simple pfctl -f /etc/pf.conf -k <host/network> might be the better solution than flushing everything and killing each and every connection.

When configuring PF, nc and tcpdump are by far your best buddies to test and evaluate your rules. Also have a look on pfctl -s and its various modifiers.

 

[japoc]

Is there's a way to allow traffic on the ssh port even if it's not new or established (I mean regardless of state)? I think this would solve the problem (although I'm not sure to what extent it could be a security issue to allow that).

 

[japoc]

Just keep in mind: this won't apply new/changed rules to already established connections (or states). These will be handled with the previously applied rule until closed.

For such scenarios, a simple pfctl -f /etc/pf.conf -k <host/network> might be the better solution than flushing everything and killing each and every connection.

Thanks, the -k option looks promising. It would be even better if it allowed to flush every state for packet that don't originate from a certain network (this way I could flush everything except the connection from my laptop to the server). Or maybe I can label all my rules with a certain label, except the rule for ssh, and then flush every packet that were matched by the rules with the label. That sounds a bit overcomplicated, though.

 

[sko]

Or maybe I can label all my rules with a certain label, except the rule for ssh, and then flush every packet that were matched by the rules with the label. That sounds a bit overcomplicated, though.

Queueing might be the simpler solution:
Put your ssh traffic in a seperate queue and kill the/all other queue(s) when reloading PF.
This way you only have to tag the rules for ssh; everything else goes to the default queue.
It is a wise idea anyways, to put your management/ssh traffic into an own queue with reserved bandwidth, so you can still access your host/network when it is under heavy network load (e.g. during ddos).