Introduction

After years of using PFsense I finally got around to replacing it with OPNsense. While I’m at it, I also wanted to ‘improve/complicate’ the setup compared to what I had with PFsense.

Motivation was simple, get rid of PFsense and Netgear. Additionally, I wanted to improve security, privacy and maintainability while achieving my stated requirements. Most of these requirements had to be replicated from what I already had on PFsense using options available on OPNsense. (e.g AdGuard vs pfBlockerNG)

This guide serves as documentation for my future self while helping fellow HomeLabers, Techies and anyone who wants to get back some digital privacy. Hopefully this can help you replicate something similar for your own usecase.

Some specific parts, e.g testing or setting up VLANs on Network Switches and WiFi APs will be in separate posts. This post primarily focuses on OPNsense and requires additional configuration on network switches.

This blog uses Mullvad as VPN provider because there is no better alternative. The instructions here focus on Mullvad only but you can easily replace it with a VPN provider of your choice that supports wireguard.

Before we start, I want to do a shoutout to Schnerring who’s guide + OPNsense docs made migrating to OPNsense a breeze. His guide inspired me to make some decisions to my OPNsense setup that I did not have with PFsense before.

Without further BS, lets get into it.

Requirements

I had very specific goals, so please make necessary changes depending on your setup. Do no blindly copy what’s here.

Network Architecture Goals

VLAN Structure

The network is segmented into multiple VLANs, each serving a specific purpose with appropriate security controls:

Core Requirements

Beyond the VLAN structure, the network must meet these essential requirements:

Connectivity & Routing:

• Redundant VPN tunnel to the internet (primary with automatic failover to secondary)
• IPv4 Only (IPv6 disabled)
• All traffic routed through the 2 VPN tunnels with priority failover
• Port forwarding for services such as Proxies, Cloud services, Plex, and any other self-hosted application

DNS & Security:

• AdGuard DNS blocking for all networks (with VLAN46 exception)
• Unbound Forwarding DNS Queries to Mullvad DNS servers
• VLAN46 traffic routed through VPNs but without AdGuard
• VLAN46 has no DNS filtering and goes directly to 1.1.1.1 (bypass Mullvad DNS)
• Quantum-secure VPN tunnel (Thanks Mullvad - not sponsored)
• Priority on real Open Source tooling and solutions
• DMZ for public facing server with various services

DNS Architecture

The DNS setup uses three services working together: AdGuard filters queries, DNSmasq handles local domains, and Unbound forwards to Mullvad DNS through the VPN tunnel.

Important: Install AdGuard First

DNS Query Flow

graph TD
    Client[All Client Networks
    LAN, DMZ, SecWiFi, IoT, Guest, GoatNET]
    
    Client -->|Port 53| Router{NAT Redirect Rule}
    
    Router -->|DNS_ADGUARD_IG
    LAN, DMZ, SecWiFi
    IoT, Guest| AdGuard[AdGuard Home :53
    DNS Filtering]
    Router -->|NO_ADGUARD_IG
    GoatNET VLAN46| CF[Cloudflare 1.1.1.1
    via VPN]
    
    AdGuard -->|Local Domains| DNSmasq[DNSmasq :5335
    Local Resolution]
    AdGuard -->|All Other Queries| Unbound[Unbound :5353
    Upstream Resolver]
    
    Unbound -->|All Queries
    via VPN| Mullvad[Mullvad DNS
    100.64.0.X]
    
    CF -.->|Response| Client
    Mullvad -.->|Response| Unbound
    Unbound -.->|Response| AdGuard
    DNSmasq -.->|Response| AdGuard
    AdGuard -.->|Response| Client

Understanding the Flow

AdGuard receives all DNS queries on port 53 (DNS) and uses conditional forwarding to route them. Local domains home.byteron.com and reverse DNS for 10.x.x.x go to DNSmasq on port 5335. Everything else goes to Unbound on port 5353, which forwards through the VPN tunnel to Mullvad DNS.

AdGuard Upstream DNS Configuration

The bracket syntax [/domain/]server:port creates conditional forwarding rules in AdGuard. Lines without brackets define the default upstream server.

[/home.byteron.com/]10.0.0.1:5335    # Local domain → DNSmasq
[/10.in-addr.arpa/]10.0.0.1:5335     # Reverse DNS → DNSmasq
10.0.0.1:5353                        # Everything else → Unbound

DNS services & Ports

Security outcome: Internal DNS structure never leaks outside your network, all external queries travel through encrypted VPN tunnels, and AdGuard filtering protects all networks except VLAN46 (which bypasses AdGuard for work requirements).

Additional Security Tools

Once everything is set up and running, I am planning to also implement the following:

To keep the length of this blog reasonable I have to leave this for the future.

Hardware

Hardware selection was somewhat of a headache depending on the levels of risk you were willing to accept.

If nation states, hardware backdoors, etc are a concern for you, then you are pretty much out of affordable options.

Power consumption, noise and costs were some of my priorities when deciding the hardware. My old PFsense was running on a second hand Dell Optiplex 3080 with an i340-T4 Quad Port NIC. It was old and noisy and got quite hot by todays standards. It’s been chugging along for many years and already ROIed 2-3 times over. I think it earned its retirement or a new role maybe? Nothing planned for now.

After comparing various options from Aliexpress, Local EU market and official devices from OPNsense the choices were narrowed down to a Small Form factor PC. Either a newer Dell Optiplex or something from Lenovo Thinkcenter series.

In the end I went for Lenovo M920q with a i350-T4 Quad Port NIC and a riser card. The total costs were under 230 euros, compared to DEC677 from OPNsense which is around 549, we are achieving similar or better performance for half the price.

That sounds like a good value proposition, no wonder so many people have done this exact path.

Here are some pictures of me taking it apart, installing the riser and i350-T4 NIC. I also 3D-printed a backplate cover from Makerworld which snapped immediately as I took it of the print plate. I did some soldering magic and fixed the break, installed the shield and we have our little box ready.

Images: Hardware Preparation

Below are some pictures I took while prepping the hardware

Removing not needed parts:

Intel i350-T4 and Riser card:

Placing NIC inside the riser:

Everything put together without back cover:

Complete Build with 3D printed Back cover.

If required you should update, reset and configure BIOS. You can refer to this github link for more details on the steps related to this.

Software & USB Setup

Downloading OPNsense

Download the latest OPNsense ISO from: https://opnsense.org/download/

Preparing the USB Drive

Identify Your USB Device

lsblk

Locate your USB drive (typically /dev/sdd or similar). Note the device path.

Wipe the USB Drive

sudo dd if=/dev/zero of=/dev/sdd bs=4M status=progress

Replace /dev/sdd with your actual USB device path.

Verify the Downloaded Image

openssl sha256 OPNsense-25.7-vga-amd64.img.bz2

Compare the output with the SHA256 checksum on the OPNsense download page.

SHA256 for version 25.7:

705e112e3c0566e6e568605173a8353a51d48074d48facf5c5831d2a0f7fb175

For additional verification methods, refer to the OPNsense documentation.

Burn the Image to USB

sudo dd if=OPNsense-25.7-vga-amd64.img of=/dev/sdd bs=16k status=progress

Installing OPNsense

Pre-Installation Checklist

Before booting from USB, ensure:

• BIOS settings have been configured (as covered in the hardware setup section)
• Boot order prioritizes USB devices
• Secure Boot is disabled (if applicable)

Installation Process

NIC Compatibility: Non-Intel NICs or certain riser cards may have compatibility issues with OPNsense. The Intel i350-T4 has excellent driver support and is recommended for this build.

Network Interface Assignment

During installation, assign your WAN and LAN interfaces:

Integrated Interface: The M920q includes a built-in network interface (typically em0, though naming may vary). This is normal and can be left unassigned or used for management if desired.

Physical Port Labels: Label your ports with WAN/LAN designations using tape or a label maker. This prevents accidentally plugging cables into the wrong ports, which could expose your network or cause connectivity issues.

Post-Installation

Once the installation is complete, remove the USB and reboot the system. When it loads back up, the console will display the IP address for OPNsense web interface which you can reach through any browser.

Setting up OPNsense using UI

Initial Login

Access the web UI using the credentials: root / [your_password]

Setup Wizard

You’ll be presented with a setup wizard. You can either proceed through it or skip and configure manually.

Recommended Configuration:

Feel free to use your prefered DNS providers instead.

Optional: DNSSEC Configuration

If you want to enable DNSSEC support you should enable the following settings.

User Access, SSH and Keys

Depending on how you are setting this up I’d recommend to enable SSH, at the very least temporarily so that you can troubleshoot any issues as they arise.

Once you’ve done with the setup, I recomend only having certificate or key based authentication for SSH. Password based SSH is acceptable during setup only. Make a mental note on this going forward.

Disable IPv6

If you do not require IPv6 then you need to disable it in two locations found here:

Optional: Hardware Offloading

If you’re not using Intel NICs, you may want to disable hardware offloading options that can be found here: Interfaces → Settings

Setting up VLANs

Navigate to Interfaces → Devices → VLAN and create the following VLANs:

Once done, it should look like this:

Physical Port Configuration

OPNsense connects to two ports on the 24-port switch:

Note that igb1 and igb2 refer to the two physical interfaces on OPNsense.

Assigning VLANs to Interfaces

Navigate to Interfaces → Assignments and assign each VLAN to a virtual interface. Once complete, your assignments should include all the VLANs listed above.

Note that I redacted a few fields as I forgot to take a screenshot earlier in the setup.

Configuring IP Addresses

Now the tedious part, for each VLAN interface, you need to:

1. Enable the interface
2. Assign a static IP address

IP Addressing Scheme

To keep things organized, the third octet matches the VLAN ID:

Base: 10.0.0.1/24 (LAN)

Pattern: 10.0.[VLAN_ID].1/24

Examples:

• VLAN10 → 10.0.10.1/24
• VLAN40 → 10.0.40.1/24
• VLAN46 → 10.0.46.1/24

Navigate to each interface (e.g., Interfaces → [DMZ_VL10]) and configure it with the appropriate static IP following this pattern.

Repeat this process for all VLAN interfaces as shown in the screenshot for DMZ_VL10

DNSmasq & DHCP

We’ll use DNSmasq for local DNS resolution and DHCP services across all VLANs.

Configuring DNSmasq

Navigate to Services → DNSmasq DNS & DHCP → General:

1. Select the interfaces that need the service
2. Enable the service
3. Change the listening port from 53 to 5335 (since AdGuard will use port 53)

Setting Up DHCP Ranges

Navigate to Services → DNSmasq DNS & DHCP → DHCP Ranges and create IP ranges for each VLAN.

DHCP Range Strategy

Each network uses the same range pattern (.100 to .150), providing 51 IP addresses per network. This makes management consistent across all VLANs. Adjust ranges if you need more devices per VLAN.

Example screenshot of editing DHCP range for LAN. Repeat this process for each network in the table above.

Once configured, your DHCP ranges should look like this:

VPN Setup: Mullvad + WireGuard

Generating Configuration Files

Use Mullvad’s WireGuard Config Generator to create configuration files for your tunnels.

1. Generate a new key or use an existing one
2. Select your preferred country, city, and server
3. Download and open the config file

Example Configuration File:

[Interface]
# Device: Funky Name
PrivateKey = REDACTED_PRIVATE_KEY
Address = 10.65.196.16/32
DNS = 10.64.0.1

[Peer]
PublicKey = REDACTED_PUBLIC_KEY
AllowedIPs = 0.0.0.0/0
Endpoint = 185.209.196.77:51819

Note down all fields - you’ll need them in the following steps.

Creating WireGuard Peers

Navigate to VPN → WireGuard → Peers and create a peer for each server:

Leave the Instance field blank for now.

Creating WireGuard Instances

Navigate to VPN → WireGuard → Instances and create an instance:

Repeat for Second VPN

Create a second peer and instance for redundancy. Make sure that you use a different listen port for each VPN instance.

Enabling and Verifying Tunnels

1. Enable WireGuard in the Instance tab
2. Navigate to VPN → WireGuard → Status
3. Verify connection status shows recent handshakes and data transfer

It should look something like this:

Assigning WireGuard Interfaces

Navigate to Interfaces → Assignments and add both WireGuard interfaces wg0 and wg1. Your interface list should now include all VLANs, LAN, WAN, and the two WireGuard interfaces.

Configuring WireGuard Interface Settings

For each WireGuard interface, you need to enable it but NOT assign a gateway at the interface level.

Navigate to Interfaces → [UK_VPN] (or whatever you named your first VPN interface):

VPN Gateways

Creating Gateway Entries

Navigate to System → Gateways → Configuration and create a gateway for each VPN tunnel:

If tunnel address is: 10.65.196.16/32
Gateway IP would be: 10.65.196.15

Modify WAN Gateway

Edit the WAN_DHCP gateway and change its priority to 254 (lowest priority).

Creating Gateway Group

Navigate to System → Gateways → Group and create a failover group:

Static Routes

Understanding the Requirement

You must create a static route for every VPN endpoint IP address from your WireGuard configuration files. Even if you only plan to use one tunnel initially, add routes for all endpoints you’ve configured as peers. This ensures seamless failover if you later enable backup tunnels.

Creating Static Routes

Navigate to System → Routes → Configuration and add a static route for each VPN endpoint.

Example Routes:

For each WireGuard peer you created earlier, add its endpoint:

Route 1 - UK Server:

Route 2 - DE Server:

Finding Your Endpoint Addresses

The endpoint addresses come from the [Peer] section of your Mullvad WireGuard configuration files:

[Peer]
PublicKey = REDACTED_PUBLIC_KEY
AllowedIPs = 0.0.0.0/0
Endpoint = 185.209.196.77:51819  ← This IP address

Extract the IP address (without the port) and use it in the Network Address field with /32 suffix. Once done, it should look like this:

Note that you see 4 entries for 4 different servers/regions.

Verification

After adding all static routes, verify they appear in your routing table. You can go to System → Routes → Status and you can filter by WAN. You should see entries for each VPN endpoint IP routing through your WAN gateway.

DNS Resolver (Unbound)

General Configuration

Navigate to Services → Unbound DNS → General and configure the basic settings. Make sure to change the listen port to 5353 so it does not conflict with AdGuard.

Advanced Mode Settings

Enable Advanced Mode (top left) to access additional options:

Once done, it should look something like this:

Advanced Tab Configuration

Navigate to the Advanced tab and enable the following security options:

Creating Custom Configuration Files on OPNsense

SSH into OPNsense and create the necessary configuration files for local domain handling.

Optional: Install nano

I like to use nano text editor which does not come with OPNsense so you have to install it yourself.

pkg install nano

You can use your prefered editor in the steps below, just replace nano command.

Create the targets file:

nano /usr/local/opnsense/service/templates/OPNsense/Unbound/+TARGETS

Content:

private_domains.conf:/usr/local/etc/unbound.opnsense.d/private_domains.conf

Create the private domains configuration:

nano /usr/local/etc/unbound.opnsense.d/private_domains.conf

Content:

server:
  local-data: "home.byteron.com. 3600 IN SOA opnsense.home.byteron.com. admin.byteron.com. 2021110201 86400 7200 3600000 3600"
  local-zone: "home.byteron.com" static

Apply and verify the configuration:

# Generate template
configctl template reload OPNsense/Unbound

# Show generated file
cat /usr/local/etc/unbound.opnsense.d/private_domains.conf

# Check if configuration is valid
configctl unbound check

Query Forwarding

Navigate to Services → Unbound DNS → Query Forwarding and configure forwarding rules:

** Leave the Domain field blank for default upstream servers that handle all non-local queries.

Note that I included 3 Mullvad DNS servers so that in rare cases where one of them goes down, we are still able to resolve public domains.

Once completed, it should look like this. Also note that we have disabled entry for 1.1.1.1 which was used for testing purposes.

Firewall Configuration

Now we need to configure firewall rules to allow traffic, since the default action is always BLOCK.

Creating Interface Groups

Navigate to Firewall → Groups and create the following groups:

It should look something like this:

Firewall Aliases

Aliases simplify firewall rule management and make maintenance easier. Navigate to Firewall → Aliases to create the following.

Network & Host Aliases

My setup has aliases for every device on the network which includes servers, cameras, printers, network gear and everything else. There are also nested aliases to help group devices further. I recommend you do the same according to your needs. Since my alias list contains sensitive information I am unable to share a screenshot for it.

Port Aliases

Optional: Aliases:

PORTS_OUT_LAN - Intranet allowed ports:

PORTS_OUT_WAN - Internet allowed ports:

My PORTS_OUT_WAN alias also contains other aliases such as STEAM_PORTS, TOOL_PORTS, APPLICATION_PORTS etc. The process of figuring out what application requires what port can be tedious but can be easily done by utilizing Firewall → Log Files → Live View and adding appropriate filters for interfaces, source devices and action being blocked. With the filter set, you simply launch the application and by looking at the logs you can easily figure out what ports are needed. Hint: They are the ones getting blocked.

What are MULLVAD_ENDPOINTS for?

The MULLVAD_ENDPOINTS alias contains your VPN endpoint addresses and will be used to create rules that allow tunnel establishment even when all traffic is routed through the VPN. This solves the circular routing problem mentioned earlier.

NAT - Network Address Translation

Outbound NAT Rules

Navigate to Firewall → NAT → Outbound and select Manual Outbound NAT rule generation.

Create the following outbound NAT rules:

It should look like this once done:

NAT DNS Redirect

Navigate to Firewall → NAT → Port Forward to redirect DNS queries to the appropriate DNS resolver.

Redirect networks using AdGuard:

Redirect VLAN46 to bypass AdGuard:

This traffic still routes through the VPN tunnels but uses Cloudflare DNS instead of Mullvad DNS.

Optional: Reverse Proxy Redirect

If running a reverse proxy, create this port forward rule. You may also want near identical rule for HTTP traffic.

Optional: Plex Remote Access

For Plex remote access, create this port forward rule:

Navigate to Firewall → NAT → Port Forward and click Add to create a new rule:

Once completed, it should look like this:

Firewall Rules

Floating Rules

Navigate to Firewall → Rules → Floating and create the following rules:

*Enable logging on the kill switch rule to monitor blocked traffic.

Optional: Plex Bypass VPN

Once done it should look like this. I’ve redacted some additional rules that are unique to my network.

SEC_LAN_IG Rules

Navigate to Firewall → Rules → SEC_LAN_IG and create the following rules:

Rule Explanation:

1. FILE_SHARING rule: Allows LAN and SecWiFi to access file shares (SMB/NetBIOS) on DMZ server
2. SERVICE_PORTS rule: Allows access to other DMZ services (web interfaces, APIs, etc.) defined in SERVICE_PORTS alias (Common examples: 80, 443, 8080, 8443, or application-specific ports)
3. Intranet traffic rule: Allows LAN and SecWiFi devices to communicate with each other on specified ports
4. ICMP rule: Allows pinging from SEC_LAN_IG networks for troubleshooting

Optional: WAN_OUT_IG Rules

VPN_OUT_IG Rules

Navigate to Firewall → Rules → VPN_OUT_IG:

Optional: Selective Routing

Route VPN traffic through gateway group:

Optional: LAN to ALL Networks

This rule should remain disabled but can be quickly enabled for troubleshooting when you need LAN devices to access all networks.

Optional: Cleanup for PORTS_OUT_LAN

When finalizing your configuration, consider removing the following from PORTS_OUT_LAN if you do not need them:

• Port 53 (DNS): NAT redirect rules handle DNS routing
• Port 623 (IPMI): Only needed if you have hardware management interfaces (Dell iDRAC, HP iLO, etc.)
• Port 137 (NetBIOS): Used for network scanning; blocking can prevent unwanted discovery traffic. We do use Port: 137 for the FILE_SHARING rule on SEC_LAN_IG to DMZ

AdGuard Home Setup

Installing AdGuard Home

AdGuard Home requires adding a third-party repository. SSH into OPNsense and run:

fetch -o /usr/local/etc/pkg/repos/mimugmail-single.conf https://www.routerperformance.net/mimugmail-single.conf

Once the repository is added, navigate to System → Firmware → Plugins in the OPNsense UI and install os-AdGuardhome-maxit.

Enabling AdGuard Home

Navigate to Services → AdGuard and enable the service:

• ✓ Enable
• ✓ Primary DNS

nano /usr/local/AdGuardHome/AdGuardHome.yaml

dns:
  bind_hosts:
    - 10.0.0.1
  port: 53

Accessing AdGuard UI

Access the UI at: http://10.0.0.1:3080/

Configuring DNS Settings

Navigate to Settings → DNS Settings in the AdGuard UI.

Upstream DNS servers:

[/home.byteron.com/]10.0.0.1:5335
[/10.in-addr.arpa/]10.0.0.1:5335
10.0.0.1:5353

Fallback DNS servers:

10.0.0.1:5353

Bootstrap DNS servers:

10.0.0.1:5353

Private reverse DNS servers:

10.0.0.1:5335

Click Test Upstream DNS to verify connectivity, then Save.

Update System DNS Configuration

Navigate to System → Settings → General and update the DNS configuration:

Remove any other DNS entries to ensure all DNS queries go through AdGuard Home.

Optional: Retain WAN IP (MAC Spoofing)

If you’re migrating from another device and want to retain the same WAN IP from your ISP:

1. Obtain the MAC address from your previous device
2. Navigate to Interfaces → WAN
3. Enter the MAC address in the MAC address field
4. Save and restart the device

Your new device should now receive the same IP address from your ISP.

Interfaces → WAN should look like this:

Optional: Network Time Protocol (NTP)

Since I will be setting up additional security measures such as SIEM and log correlation in the future, it will require proper time synchronization. This section ensures that all devices sync time with OPNsense.

Configuring NTP Server

Navigate to Services → Network Time → General and configure:

• Select all interfaces (LAN, VLANs)
• Add upstream NTP servers (Pick an option from pool.ntp.org that is in your region)

Force All Devices to Use OPNsense NTP

Create NAT redirect:

Navigate to Firewall → NAT → Port Forward

This transparently redirects all NTP traffic to OPNsense, ensuring consistent time across all devices.

Configure DHCP NTP option:

Navigate to Services → DNSmasq DNS & DHCP → DHCP Options

Add DHCP option:

dhcp-option=42,10.0.0.1

This tells DHCP clients to use 10.0.0.1 (OPNsense) as their NTP server.

Once all the steps are complete, restart OPNsense. Your setup now has:

What’s Working:

• VPN routing for all traffic with automatic failover
• DNS filtering with AdGuard (all networks except VLAN46)
• Network segmentation and firewall rules
• Kill switch preventing WAN leaks
• NTP synchronization
• No DNS, WebRTC or ISP leaks

What’s NOT Working Yet:

• VLAN traffic (requires switch configuration)
• Wireless VLAN access (requires AP configuration)
• DMZ external access (needs testing after switch setup)

Still Required:

1. Configure managed switches with VLAN tagging
2. Configure wireless access points for VLAN SSIDs
3. Test and verify the complete setup

Detailed verification and testing procedures are covered in separate guides linked below.

Next Steps

Now that OPNsense setup is complete, you still need to configure switches, wireless access points and then verify that everything works.

Since the length of this post is already quite large, I will split up the next steps as follows:

1. Configure Network Switches & WiFi Access Points [REQUIRED]

VLANs won’t work until we configure switches with VLAN tagging. You will need a managed switch for this as “dumb” switches don’t have this capability. You can read more about the standard: IEEE 802.1Q.

Guide: VLAN Switch Configuration for OPNsense

2. Test Your Setup

Once you’ve completed this setup and configured your network switches, verify that everything is working correctly.

This separate post focuses on verifying DNS resolution, VPN tunnels, firewall rules and VLAN isolation.

Guide: Testing Your OPNsense Setup

3. Configure Plex (Optional)

Plex-specific verification steps for testing and configuring Plex remote access that bypasses VPN routing.

Guide: Plex Remote Access Through OPNsense VPN

4. Local Domain Setup with Reverse Proxy (Optional)

Setting up local domains (e.g., service.home.byteron.com) with a reverse proxy for accessing your self-hosted services.

Guide: Local Domain Setup with Reverse Proxy

Future Topics

In the near future I plan to document:

• Advanced security tools: Zenarmor, CrowdSec, Suricata, Wazuh
• Monitoring and alerting

Leave a comment if there is anything else you’d like me to cover in the future.

Disclaimer

Use the information provided here at your own risk, but if you find errors or issues in this guide, leave a comment and I’ll try to address them ASAP.