dispelledpfSense First Setup Checklist
pfSense is most useful when it is treated as network infrastructure rather than just another web application. The first setup is where you establish the interfaces, management path, address plan, firewall policy, and recovery process that every later change depends on. Work from the console or a local connection until the web interface is reachable and tested.
Plan the Appliance Before Installing
Write down the hardware, intended WAN connection, LAN network, and any VLANs before booting the installer. A small appliance normally needs at least two network interfaces: one for the internet-facing WAN and one for the trusted LAN.
- record the appliance model, storage device, and network interface MAC addresses
- decide which interface will be WAN and which will be LAN
- choose a private LAN range that does not overlap with networks you must reach remotely
- reserve a safe maintenance path through the local console or an out-of-band console
- keep the installation image and release notes for the exact release being installed
Do not put the management interface directly on an untrusted network just to make the first login convenient. A firewall is easiest to repair when the person configuring it still has a local path in.
Install and Assign Interfaces Carefully
Use the official installer for the chosen pfSense release and confirm the image checksum when one is provided. During the first boot, pfSense presents the detected interfaces and asks you to assign them. Confirm the assignment against the MAC addresses or cable labels rather than trusting the interface names alone:
WAN = the interface connected to the modem or upstream router LAN = the interface connected to the trusted switch
If an interface is wrong, the appliance can appear healthy while every client is on the wrong side of the firewall. Stop and correct the assignment from the console before connecting other equipment.
Give the LAN a Deliberate Management Address
Set a fixed private address on LAN and use it only for the management network. For example, a new appliance might use 192.168.50.1/24, with clients receiving addresses from a DHCP pool that leaves room for infrastructure:
LAN address: 192.168.50.1/24 DHCP pool: 192.168.50.100 - 192.168.50.199 Infrastructure: 192.168.50.2 - 192.168.50.49
Connect a laptop directly to LAN or through the trusted switch, renew its address, and open the management URL shown by the console. Test the connection before moving the appliance to its permanent location.
Finish the WebConfigurator Wizard
Complete the initial wizard rather than changing unrelated settings first. Set the hostname and domain you will recognize in logs, choose the correct timezone, and configure the WAN according to the upstream service:
- DHCP: use this when the upstream router or ISP assigns the WAN address automatically.
- Static: enter the address, gateway, and prefix supplied by the provider or network owner.
- PPPoE: enter the account details supplied by the provider and confirm the required interface.
Change the default administrator password to a unique, long password. Do not reuse a password from the modem, wireless access point, or another service. Keep the recovery material somewhere accessible when the web interface is unavailable.
Update Before Building the Network
After the initial login, check System > Update and apply the current supported update for the installed release. Reboot when requested, then confirm the dashboard is healthy before adding packages or custom rules.
Read the release notes before a major upgrade. Treat an upgrade as a change window: export a configuration backup first, ensure console access, and avoid combining the upgrade with a new VPN, VLAN, or package installation.
Set DNS and DHCP Intentionally
Decide whether pfSense will be the LAN DNS resolver and DHCP server, or whether those roles belong elsewhere. Avoid creating two DHCP servers on the same broadcast domain. A simple first setup usually keeps both services on pfSense:
- set the LAN DHCP range smaller than the entire subnet
- add static mappings for switches, access points, servers, and infrastructure nodes
- set a meaningful hostname for each mapping so logs remain readable
- confirm clients receive the pfSense LAN address as their gateway and DNS server
- test both forward DNS lookups and access to a known outside address
If the appliance will forward DNS to an upstream resolver, document which resolver is used and whether DNS over TLS, DNSSEC validation, or local overrides are part of the design.
Start with a Small Firewall Policy
pfSense filters traffic per interface. The default LAN policy is intentionally more permissive than the default WAN policy, but do not assume that a rule on one interface controls traffic everywhere. Before adding exceptions, write down who should be able to reach what:
| Traffic | Starting policy |
|---|---|
| LAN to internet | Allow only as broadly as the network requires; record exceptions. |
| WAN to firewall management | Block. Manage from LAN or a secured VPN instead. |
| WAN to LAN | Block unless a specific published service has a documented destination. |
| Guest to trusted LAN | Block, then allow only the DNS, DHCP, and internet paths guests need. |
| IoT to trusted LAN | Block by default and add narrowly scoped exceptions. |
Use aliases for groups of hosts and ports, give rules useful descriptions, and place specific exceptions above broad rules. After every change, inspect the rule hit counters and the firewall log instead of assuming the intended rule matched.
Keep Management Off the WAN
Do not enable the WebConfigurator or SSH on WAN as a shortcut for remote administration. Use one of these paths instead:
- manage from the trusted LAN
- connect through a site-to-site or road-warrior VPN
- use a local or out-of-band console for recovery
If temporary WAN access is unavoidable during a controlled migration, restrict it to a known source address, use HTTPS, set an expiry or removal time, and verify the rule is gone afterward. A forgotten management exception is an exposure, not a convenience.
Back Up the Configuration
Export the configuration after the initial setup and again before every significant change. A configuration backup contains sensitive material, including encrypted secrets and sometimes private keys, so store it like a credential:
- keep an encrypted copy outside the appliance
- record which pfSense version produced the backup
- keep a recent backup available during upgrades
- test that a spare appliance or documented recovery process can use it
A backup that has never been restored is only an assumption. Periodically verify that the file can be retrieved and that the organization knows who can decrypt it.
Review Logs and Health
Before handing the appliance over to routine operation, check the dashboard, interface status, gateway monitoring, DHCP leases, DNS service, and firewall logs. Look for:
- WAN gateway flapping or packet loss
- unexpected DHCP servers or duplicate addresses
- repeated blocked connections that indicate a missing rule or an unwanted device
- services listening on an interface where they are not needed
- disk, memory, temperature, or certificate warnings
Save a short network diagram with the interface assignments, subnets, VLANs, gateways, VPNs, and the location of the latest configuration backup. The diagram is part of the firewall, because it is what lets the next person troubleshoot it safely.
First-Setup Handoff Checklist
- verify WAN and LAN assignments against the physical interfaces
- confirm the LAN address, DHCP range, gateway, and DNS behavior
- apply the current supported update and record the installed version
- change the default administrator password and keep recovery material safe
- confirm WAN management is disabled or narrowly controlled for a documented reason
- review firewall rules, aliases, NAT, and interface-specific policies
- export and protect a configuration backup
- test a client, a blocked path, DNS, gateway monitoring, and console recovery
The goal is not to add every available package or rule on day one. It is to make the appliance predictable: the interfaces are known, the management path is protected, the policy is explainable, and recovery does not depend on guessing.
Related Firewall Guide
For the packet-filter concepts behind interface rules, state, NAT, tables, and validation, see the site's OpenBSD pf — The Packet Filter guide.