Building a Router and Firewall with OPNsense

Replace your ISP router with a real firewall: full visibility into your network's traffic, VLAN segmentation, and rules you actually control instead of whatever your ISP shipped.

By DaemonPress

What you'll build and why

A dedicated OPNsense box replaces your ISP's router entirely: a real stateful firewall with rules you write and can audit, VLAN segmentation, VPN support, and live visibility into exactly what's crossing your network -- none of which a typical ISP-provided router gives you.

Don't build this if: you've never configured a firewall rule or a VLAN before, even on someone else's network -- this is genuinely an advanced first networking project, and a mistake here can take your whole household offline or, worse, silently fail to isolate something you thought was isolated. If that's you, start with the Pi-hole guide (much lower stakes, same "replace one piece of infrastructure" learning curve) and come back to this once you're comfortable with basic firewall/VLAN concepts. You also don't need this if your ISP router already does everything you need and you have no specific complaint about visibility, control, or segmentation -- this is a real time investment for a real capability upgrade, not a strict improvement for everyone.

How it works

  Internet
│
▼
ISP modem/ONT
│
▼
OPNsense -- WAN interface
│
│  (stateful firewall, NAT, rules)
▼
OPNsense -- LAN interface
│
▼
Managed switch
├──── untagged ports ──► Trusted devices (main LAN)
└──── VLAN 20 (tagged) ──► IoT / guest devices
(firewall rule: internet OK,
access to main LAN: blocked)

Every packet crossing from WAN to LAN (or between VLANs) passes through OPNsense's firewall rule set. Rules evaluate top to bottom, first match wins by default (technically: each GUI rule is "quick" by default, meaning the first matching rule stops evaluation right there) -- a broad "allow everything" rule sitting above a specific "block this" rule makes the block rule dead code, never reached. This is the single most common mistake in a first OPNsense config, and it's worth internalizing before you write your first rule, not after debugging why a block rule "isn't working."

Default policy: outbound traffic from LAN is allowed by default; inbound traffic from WAN is blocked by default unless a rule explicitly permits it. You're building on top of "block everything, allow specific things," not the other way around.

Before you start

Plan your interfaces first. You need at least two NICs: one WAN (to your modem/ONT), one LAN (to your internal switch). Know which physical port is which before you start the installer -- getting this backwards during setup is the most common first-time mistake, alongside the rule-ordering one above.

Decision: do you need VLANs on day one?

Choice Pick this if Trade-off
Single flat LAN (start here) You want to confirm the basic router/firewall replacement works before adding complexity No traffic isolation between devices -- an IoT device on the flat LAN can reach everything else on it
VLANs from day one You already know you want IoT/guest isolation and have a managed switch ready More to configure and more that can go subtly wrong (a mistagged switch port silently defeats the isolation) while you're still learning the basics

This guide builds a flat LAN first (Steps 1-4), then adds one VLAN (Step 5) once the basics are confirmed working -- do them in that order even if you know you want VLANs eventually.

Steps

Step 1: Install OPNsense

Flash the OPNsense installer image to a USB drive (or attach the ISO to a VM). Boot from it.

  1. Log into the installer console: username installer, password opnsense (the documented default -- if it doesn't work, log in as root and use menu option 8 to launch the installer manually)
  2. Choose ZFS for the disk layout when asked (recommended for its reliability and boot-environment snapshots, which make a bad config change trivially reversible) -- stripe as the ZFS device type for a single disk
  3. Select the target disk and complete the install
  4. On first boot, the console prompts for interface assignment: the first detected interface becomes LAN by default, the second becomes WAN -- confirm this matches your physical cabling from Before you start, correcting it here if not

Step 2: Log in and change the default password immediately

From a device on the LAN side, visit https://192.168.1.1 (OPNsense's default LAN address). Log in with the documented default: username root, password opnsense.

Change this password before doing anything else -- root/opnsense is a published, well-known default, not a placeholder. System → Access → Users, select root, set a real password.

Step 3: Configure WAN and confirm connectivity

Interfaces → WAN: set the connection type your ISP requires (DHCP is most common for residential connections; static IP or PPPoE if your ISP specifies one). Save and apply.

Interfaces → Overview should now show WAN with a real public IP address. If it's stuck without one, this is almost always ISP-side: some ISPs bind service to the previous router's MAC address -- either clone that MAC onto OPNsense's WAN interface (Interfaces → WAN → MAC address) or power-cycle the modem after OPNsense is connected and requesting an address.

Step 4: Confirm LAN devices get internet access

Connect a device to your switch (on the LAN side) and confirm it gets an address (OPNsense's default DHCP server hands out addresses on the LAN interface out of the box) and can reach the internet. This confirms the default outbound-allow, inbound-block firewall policy is working as expected with no rules added yet.

Step 5: Add a VLAN for IoT/guest devices

Once Steps 1-4 are confirmed working: Interfaces → Other Types → VLAN → Add. Set a VLAN tag (e.g. 20) on your LAN-facing NIC, save.

Interfaces → Assignments: assign the new VLAN as an interface, give it its own subnet (e.g. 192.168.20.1/24), enable it, enable its own DHCP server (Services → DHCPv4 → [new VLAN interface]).

Firewall → Rules → [new VLAN interface] → Add: create a rule allowing outbound internet access, and a rule above it explicitly blocking access to your main LAN subnet (192.168.1.0/24 in this guide's addressing). Remember rule order from How it works -- the block-LAN rule needs to be evaluated, which means it needs to be a real match that isn't shadowed by a broader allow-everything rule above it.

On your switch: the port(s) serving VLAN 20 devices need to be configured (tagged or untagged, depending on your switch and the device) to actually carry that VLAN -- this is a switch-side setting outside OPNsense itself, and skipping it is the most common reason a VLAN "doesn't work" even though OPNsense's own config looks correct.

Verify it works

  • Devices on the main LAN get internet access through OPNsense
  • Interfaces → Overview shows WAN with a stable public IP
  • A device on VLAN 20 gets internet access but cannot reach a device on the main LAN subnet (confirm with a ping or connection attempt from the VLAN device to something on the main LAN -- it should fail)
  • Firewall → Log Files → Live View shows real traffic as you generate it, confirming logging works
  • Failure test: unplug the WAN cable. Confirm LAN devices lose internet access (expected -- there's no failover configured) but can still reach each other and the OPNsense UI (confirms LAN-side services don't silently depend on WAN being up). Reconnect and confirm WAN and internet access both recover without a reboot.

Secure it

  • What's exposed: the web UI (:443 by default) and SSH (if enabled) should only be reachable from LAN, never from WAN -- don't create a WAN-side rule that exposes either. If you need remote administration, use a VPN (WireGuard, built into OPNsense) back into your LAN rather than exposing the UI directly.
  • Default credentials: root/opnsense is a real, documented default for both the installer and first web login -- change it immediately (Step 2), not "eventually."
  • Least privilege: create separate non-root admin accounts for anyone else who manages this firewall (System → Access → Users) rather than sharing the root login.
  • Update strategy: OPNsense ships frequent security patches; check System → Firmware → Status regularly, and subscribe to the OPNsense security advisories list. Firmware updates on a firewall carry real risk (a bad update can take your whole network offline) -- read the changelog before updating, and know how to reach the console directly (not just over the network) in case an update needs recovery.
  • The failure that hurts most: locking yourself out of the web UI with a bad firewall rule (e.g. accidentally blocking LAN access to the UI itself). The step that prevents it: the console (physical or serial access to the box itself, not through the network) always has a menu option to reset firewall rules to factory defaults -- know that exists before you need it, and don't make sweeping rule changes without physical/console access as a fallback while you're still learning.

Back it up and maintain it

What matters: your entire configuration lives in one XML file, downloadable from System → Configuration → Backups → Download configuration. Back this up after every meaningful change, not on a schedule -- it's small, fast to export, and the single thing that turns "rebuild from scratch" into "restore and go" if the hardware dies.

Update cadence: check System → Firmware → Status at least monthly; apply security-flagged updates promptly, general updates on your own schedule after reading the changelog.

What to monitor: Firewall → Log Files periodically for unexpected blocked (or worse, unexpectedly allowed) traffic patterns, and disk space if logging retention is long.

Troubleshooting

Logs: Firewall → Log Files → Live View for real-time traffic; System → Log Files → General for system-level issues.

Symptom Likely cause Diagnostic Fix
No internet after switching to OPNsense WAN never got an IP (Step 3) Interfaces → Overview, check WAN's assigned address Clone your old router's MAC onto WAN, power-cycle the modem
A firewall rule doesn't seem to do anything A broader rule above it matches first and stops evaluation (see How it works) Firewall → Rules, check this rule's position relative to others on the same interface Move the specific rule above the broader one it's being shadowed by
VLAN devices can still reach the main LAN The isolation rule isn't actually above a conflicting allow rule, or the switch port isn't tagged for that VLAN Check rule order on the VLAN interface; check switch port config Fix rule order; confirm the switch port is actually tagged/untagged correctly for VLAN 20, not left on the default network
Locked out of the web UI after a rule change A LAN-side rule accidentally blocks access to the UI itself Console access to the box directly Use the console menu's firewall-reset option, or SSH in locally to fix the specific rule
WAN drops intermittently, not just once ISP-side instability, or (less commonly) a MTU/duplex mismatch with the modem Interfaces → Overview for WAN's link status over time; check for interface errors If ISP-side, this is outside OPNsense's control; if MTU/duplex, check the WAN interface's advanced settings against your ISP's stated requirements
Firmware update fails or the box doesn't come back after one Rare, but possible with any firmware update on any device Console access; check System → Firmware for the failure reason ZFS boot environments (Step 1) make this recoverable -- boot into the previous environment from the console menu rather than reinstalling from scratch

Undo

To remove a VLAN: Interfaces → Assignments, remove the VLAN interface assignment, then Interfaces → Other Types → VLAN, delete the VLAN definition. Remove its firewall rules and DHCP server config from their respective sections.

To fully decommission OPNsense and go back to your ISP router: reconnect the ISP router directly to the modem, then reconfigure it (it likely still has your old settings if you never reset it). Keep the OPNsense box's config backup (Back it up and maintain it) in case you want to return to it later.

Go further

  • Set up a WireGuard VPN (built into OPNsense) for secure remote access into your network instead of ever exposing the web UI to WAN
  • Enable Suricata (also built in) for intrusion detection once the basics are solid -- it adds real CPU load, which is why the recommended hardware spec above calls out a modern multi-core CPU specifically for this
  • Add a second VLAN for a specific purpose (a dedicated server VLAN, a work-from-home isolated segment) using the same pattern as Step 5
  • Configure high-availability with a second OPNsense box (CARP) if this firewall becomes something your household can't tolerate losing, even briefly

Resources

Official documentation:

Source and releases:

Community:

Go deeper:

Related DaemonPress projects:

Last verified: 2026-09-21, checked against official OPNsense documentation (see Resources above).

Editor's note on verification depth: the installer flow, default credentials, and firewall rule evaluation semantics were confirmed directly against fetched OPNsense documentation this session. The VLAN interface-creation menu path (Step 5) reflects established OPNsense/pfSense-family convention consistent with the rest of the confirmed documentation, but wasn't independently re-confirmed against a specific fetched VLAN doc page this session (the specific page URL guessed didn't resolve) -- flagged here rather than presented with false certainty. [TODO-VERIFY] if you're following this guide and the VLAN screen doesn't match, check docs.opnsense.org's current VLAN page directly.

Changelog:

  • 2026-09-21 -- Full rewrite: corrected the version from stale 25.x to the confirmed current 26.7. Added the WAN/LAN/VLAN topology diagram, a "don't build this if," a flat-LAN-first vs. VLANs-from-day-one decision table, explicit default-credential disclosure (root/opnsense, previously only vaguely referenced), Secure it, Back it up and maintain it, Undo, and a full Resources section. Added a real failure test (WAN unplugged) to Verify it works. Expanded Troubleshooting from 3 to 6 entries. Dropped the self-hosting tag -- this is network infrastructure, not a hosted service in the sense every other self-hosting-tagged project in this section uses the term.
  • 2026-09-21 (earlier) -- Original version published with a stale OPNsense version reference.
FirewallsNetworkingOpen source

Related projects