Set Up the pf Firewall on FreeBSD 15.1 Without Locking Yourself Out

A public server gets scanned within minutes of going online. This guide shows a FreeBSD pf firewall setup for a VPS that you can copy, test, and reload safely over SSH. It uses FreeBSD 15.1 and a small pf.conf that blocks all unwanted inbound traffic and opens only SSH, HTTP, and HTTPS.

This is a rule set for an internet-facing host. It is not a home-router NAT guide, so there is no NAT and no gateway_enable.

pf is the packet filter that ships with FreeBSD. It loads as a kernel module when you enable it in rc.conf. FreeBSD does not ship a default ruleset, so pf does nothing until you create /etc/pf.conf. That is why a FreeBSD pf firewall setup for a VPS starts with writing your own file.

pf is stateful. When your server opens a connection, pf remembers it and lets the replies in. Everything else coming in is dropped.

For this guide, you need a FreeBSD 15.1 VPS with root access. If you do not have one yet, you can follow our FreeBSD VPS setup guide.

Make sure you have console or VNC access from your provider panel. This is your way back in if you lock yourself out. Also, you need a second SSH session open.

Then, find your network interface name and your SSH port:

On most KVM VPS hosts, the interface is vtnet0. Other hosts may use em0 or igb0. Use your real name in the rules below.

The file below is short and easy to read. It blocks all new inbound connections and opens only SSH, HTTP, and HTTPS. Your server can still go out to the internet as normal. Back up any old file, then create the new one:

Add the following configuration to the file:

If you changed your SSH port, replace 22 with the new port. Once you are done, save and close the file. Here is how the rules work:

• set skip on lo0 skips pf on loopback, so local services keep working.
• set block-policy drop drops blocked packets silently. Scanners get no reply.
• match in all scrub (no-df) cleans up incoming packets. It is the current syntax, so use it instead of the old scrub in all on FreeBSD 15.1.
• block in log all is the default deny. It logs blocked packets, and the pass rules below it open only what you list.
• pass out quick keep state lets your server reach the internet, for example for pkg and DNS.
• pf adds flags S/SA and keep state to TCP pass rules by default, so you don't need to type them.
• Keep the ICMPv6 line. IPv6 needs neighbor discovery to work.

Some VPS hosts give you an IPv4 address through DHCP. If yours does, add this line before the last pass in rule:

Never load a file you have not checked. This command reads the file and prints the final rules, but does not apply them:

If it prints your expanded rules and no errors, the syntax is fine. Any error shows the line number. Before you proceed, fix them. Checking a file this way is the most important step in any FreeBSD pf firewall setup for a VPS.

At this point, you must set pf to start when the server boots. Also, you must turn on logging, so pf saves blocked packets to a file. Use sysrc to edit /etc/rc.conf safely:

pflog_enable starts pflogd, which saves logged packets to /var/log/pflog. Don't start pf yet. The first start is the riskiest step, so read the next section first.

A bad rule can cut your SSH session. This method gives you a timed rollback. If you lose access, the old rules return on their own. First, copy your rules to a safe file:

Before the first start, set a timer. It turns pf off after 120 seconds unless you cancel it:

Then, you can start pf from your session:

Open a new SSH window and log in. If it works, cancel the timer in your first session:

For later edits, use the same timer. This time it restores your copied file instead of turning pf off:

Now open a new SSH login to test. If it works, cancel the timer and save the new file as your copy:

Do not use pfctl -F all -f for a normal reload. Flushing the state table can drop your live SSH session. A plain pfctl -f /etc/pf.conf reloads the rules and keeps existing states. Safe reloads are what make a FreeBSD pf firewall setup for a VPS practical on a remote server.

Now check that pf is running and your rules are loaded. These three commands show the status, the rules, and the active connections.

From another machine, test the open and closed ports with the command below:

Ports 22, 80, and 443 should show as open only if a service listens on them. Port 3306 should show as filtered.

Logs and packet captures show you what pf blocks and what reaches your server. Use them to find out why a connection fails. The log keyword in your rules sends blocked packets to the pflog0 interface, which you can watch live.

Read the saved log file with the command below:

To cut the noise, you can filter the output by a port or an IP address:

To see real traffic on the network card, you can capture on the main interface instead:

Capture on pflog0 to see what pf blocked. Capture on vtnet0 to see what arrives from the network. If a packet shows on vtnet0 but not in the log, a rule passed it, or it was not logged.

A bad rule can block your own SSH login. You can use your provider's console or VNC, which does not need SSH, to turn pf off and fix the file. Log in as root and run:

This turns pf off immediately, so you can fix the file. Then, check and reload:

If pf blocks you at every boot, boot into single-user mode and mount the disk read-write:

If your VPS uses ZFS, run zfs mount -a instead of the two mount commands. Fix the rules after you regain access, then set pf_enable="YES" again.

Bots try to guess SSH passwords all day. You can slow them down with a rate limit. If an IP opens too many connections too fast, pf adds it to a block list. Add the table and rules below before your pass in line:

Remove 22 from tcp_services so SSH uses this stricter rule. Check the file with pfctl -vnf before loading it. Be careful with this rule if many users share one office IP.

If you need more power or full control, a reliable dedicated server gives you the whole machine. No one else shares it, and your pf rules are the only firewall on it.

At this point, you have a working FreeBSD pf firewall setup for a VPS. It denies unwanted inbound traffic, opens SSH, HTTP, and HTTPS, logs blocked packets, and reloads with a safe rollback. Always run pfctl -vnf, keep a copy file, and keep a console login ready.

If you are running both FreeBSD and Linux, you can review the NVMe Linux VPS hosting options for your Linux workloads.

We hope you enjoy this guide. For NAT, queues, and other advanced rules, you can check the FreeBSD pf documentation.