Entropic Thoughts

Locking Yourself Out With Firewall Configuration

Locking Yourself Out With Firewall Configuration

I accidentally underconfigured my vpn1 Why do I run my own vpn? Because I have one of the world’s most privacy-friendly internet providers for my home connection, and I trust them over basically any other connectivity I might have access to elsewhere. before a work trip to Hungary: I forgot to enable ip forwarding and nat on the FreeBSD box running it.2 The full story is a little complicated. This FreeBSD box used to run as the primary gateway of my home network, but during the previous move, I installed another gateway in front of it, so it’s been relegated to a regular member of the local network. It does, however, still run the vpn I use abroad, so I thought I had updated the nat rules to work with the new network layout, but it turns out I had not.

This is not complicated configuration to do, but it was a while since I used the FreeBSD firewall pf, so I was still a little nervous about locking myself out.

Here’s what I’ve had success with doing before.

  1. Make whatever changes are needed to /etc/pf.conf
  2. Start tmux for it’s nohup functionality, i.e. that it doesn’t kill the shell when you log off.
  3. In a competent shell, run the command service pf restart && sleep 120 && service pf stop.
  4. Now the firewall is enabled with the new config for two minutes, during which we should test that we can still access the system well enough to rescue a botched attempt at firewall config.
    • If we cannot access the system, we wait two minutes, then the firewall will be turned off (bad!) but we can quickly log in, restore the previous config, and then have a second go at it.
    • If we can acccess the system still, we simply interrupt (^C) the sleep and the third command will not run.

This is a general pattern that you can probably think of many variants of: it doesn’t have to be about firewalls. Maybe we can restore the previous configuration automatically instead of stopping the firewall entirely.3 The reason I preferred stopping the firewall entirely in this case is that the machine in question is already on a local network behind another firewall, and I prefer as few things that can go wrong as possible in emergency recovery procedures!

A typical beginner’s mistake is to forget about tmux or equivalent. A nohup-type environment is critical for this to work! Without it, test failure will likely lead to your shell being killed, and then the sleep is automatically interrupted, and then the firewall will not be disabled.