Testing Your OPNsense Setup

This guide verifies your OPNsense setup works correctly. Tests progress from simple to complex - fix early failures before proceeding.

Introduction

These tests verify your OPNsense configuration actually works - DHCP assignment, VPN routing, DNS filtering, VLAN isolation, and kill switch functionality. Run them in order because later tests depend on earlier ones passing. The kill switch test is critical - if it fails, your ISP sees all traffic.

Basic Connectivity Tests

Test 1.1: DHCP Assignment

What we’re testing: Devices receive IP addresses automatically from DNSmasq

From: Any device on LAN or VLAN

Expected result: Device receives IP in the configured DHCP range

How to test:

On your client device:

• Windows: Open Command Prompt → ipconfig
• macOS/Linux: Open Terminal → ip addr or ifconfig
• Mobile: Settings → Wi-Fi → Tap your network name

Success indicators:

• IP address is within your DHCP range (e.g., 10.0.0.100 - 10.0.0.150 for LAN)
• Default gateway matches your VLAN gateway (e.g., 10.0.0.1 for LAN)
• DNS server is set to your gateway IP (10.0.0.1)

If this fails:

Check DNSmasq configuration on OPNsense:

# SSH into OPNsense
configctl dnsmasq status

Verify DHCP ranges are configured:

• Navigate to Services → Dnsmasq DNS & DHCP → DHCP Ranges
• Confirm ranges exist for your VLAN
• Check that DNSmasq is enabled and listening on the correct interfaces

Test 1.2: Gateway Reachability

What we’re testing: Device can reach its default gateway

From: Client device on any VLAN

Expected result: Gateway responds to ping

How to test:

# Replace with your gateway IP
ping -c 4 10.0.0.1

Success indicators:

4 packets transmitted, 4 received, 0% packet loss
time 3ms

If this fails:

• Verify you’re connected to the network (check WiFi/Ethernet connection)
• Check interface is enabled: Interfaces → [Your VLAN] → Enable checkbox
• Verify gateway IP is correctly configured on the interface
• Check physical cabling if using wired connection

Test 1.3: Internet Connectivity

What we’re testing: Device can reach the internet through OPNsense

From: Client device on any VLAN

Expected result: External IP responds to ping

How to test:

# Test with a reliable public DNS server
ping -c 4 1.1.1.1

Success indicators:

4 packets transmitted, 4 received, 0% packet loss

If this fails:

Check gateway status from OPNsense:

# SSH into OPNsense
ifconfig | grep -A 5 wg

Verify VPN tunnels are up:

• Navigate to VPN → WireGuard → Status
• Check “Latest Handshake” shows recent timestamp (< 2 minutes)
• Verify “Transfer” shows RX/TX data

Check gateway status:

• Navigate to System → Gateways → Status
• All VPN gateways should show “Online” status

DNS Resolution Tests

Test 2.1: Basic DNS Resolution

What we’re testing: DNS queries resolve correctly

From: Client device

Expected result: Domain names resolve to IP addresses

How to test:

# Test external domain resolution
nslookup github.com

# Or using dig
dig github.com

Success indicators:

• Returns valid IP addresses
• Query completes in < 100ms
• No timeout errors

If this fails:

Check DNS configuration on client:

# Linux/macOS
cat /etc/resolv.conf

# Windows
ipconfig /all | findstr "DNS"

Should show your gateway IP (10.0.0.1)

From OPNsense, verify DNS services:

# Check AdGuard status
service adguardhome status

# Check Unbound status
configctl unbound status

# Check DNSmasq status
configctl dnsmasq status

All three should return “running” or “active”

Test 2.2: Local Domain Resolution

What we’re testing: Internal hostnames resolve correctly

From: Client device on LAN

Expected result: Local domain resolves to internal IP

How to test:

# Replace with your local domain
nslookup opnsense.home.byteron.com

Success indicators:

• Resolves to OPNsense LAN IP (e.g., 10.0.0.1)
• Query goes through DNSmasq (port 5335)

If this fails:

Check DNSmasq is handling local domains:

# SSH into OPNsense
drill @10.0.0.1 -p 5335 opnsense.home.byteron.com

Verify AdGuard forward rules:

• Navigate to AdGuard UI: http://10.0.0.1:3080
• Settings → DNS Settings → Upstream DNS servers
• Confirm [/home.byteron.com/]10.0.0.1:5335 exists

Test 2.3: AdGuard Filtering

What we’re testing: AdGuard blocks ads and tracking domains

From: Client device on any VLAN except VLAN46

Expected result: Known ad domains are blocked

How to test:

# Test known ad domain
nslookup doubleclick.net

# Should return 0.0.0.0 or no result

Or visit in browser: http://doubleclick.net (should not load)

Success indicators:

• Domain returns 0.0.0.0 or fails to resolve
• Browser shows “Site can’t be reached”
• AdGuard dashboard shows blocked queries

If this fails:

Check AdGuard is active:

• Navigate to Services → AdGuard
• Verify “Enable” and “Primary DNS” are checked
• Restart AdGuard service if needed

Check blocklists are enabled:

• AdGuard UI: http://10.0.0.1:3080
• Filters → DNS blocklists
• Ensure at least one blocklist is enabled and updated

Test 2.4: VLAN46 Bypasses AdGuard

What we’re testing: VLAN46 (GoatNET) bypasses AdGuard filtering

From: Device on VLAN46 (10.0.46.x)

Expected result: Ad domains resolve normally

How to test:

# Test known ad domain
nslookup doubleclick.net

# Should return real IP addresses

Success indicators:

• Domain resolves to actual IP addresses (not 0.0.0.0)
• Browser can load ad/tracking sites

If this fails: Check NAT redirect rule for VLAN46:

• Navigate to Firewall → NAT → Port Forward
• Find rule: “Redirect GoatNET DNS directly to 1.1.1.1”
• Verify it redirects port 53 to 1.1.1.1:53 (Cloudflare, bypassing AdGuard)
• Interface should be NO_ADGUARD_IG or VLAN46

VPN Tunnel Tests

Test 3.1: VPN Tunnel Status

What we’re testing: WireGuard tunnels are established

From: OPNsense SSH

Expected result: Both VPN tunnels show active connections

How to test:

# Check WireGuard interface status
ifconfig | grep -A 10 wg

# Check for active handshakes
wg show

Success indicators:

# Interface names depend on your configuration e.g UK_VPN or wg0
UK_VPN: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST>
DE_VPN: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST>
# or this:
wg0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST>
wg1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST>

latest handshake: 45 seconds ago
transfer: 1.23 GiB received, 456.78 MiB sent

If this fails:

Check WireGuard configuration:

• Navigate to VPN → WireGuard → Instances
• Verify “Enable WireGuard” is checked
• Check instances show green status indicators

Verify static routes exist:

netstat -rn | grep -E "185\.|WAN"

Should show routes for VPN endpoint IPs going through WAN gateway

Check endpoint connectivity:

# Replace with your VPN endpoint IP
ping -c 4 185.209.196.77

Test 3.2: Exit IP Verification

What we’re testing: Traffic exits through VPN, not your ISP

From: Client device on any VLAN

Expected result: Public IP shows VPN location, not your real location

How to test:

Visit in browser: https://whatismyipaddress.com

Or command line:

curl ifconfig.me

Success indicators:

• IP address matches your VPN server location
• Location shows VPN country (e.g., Germany, UK)
• ISP shows “M247” or “Mullvad” (not your real ISP)

If this fails:

Check gateway routing:

# SSH into OPNsense
traceroute -n 1.1.1.1

First hop should be your VPN tunnel address (10.65.x.x), not your ISP gateway

Verify outbound NAT rules:

• Navigate to Firewall → NAT → Outbound
• Confirm VPN_OUT_IG → UK_VPN and DE_VPN rules exist
• Rules should be above WAN rules in priority

Check floating rules:

• Navigate to Firewall → Rules → Floating
• Verify VPN routing rules exist and are enabled
• Confirm kill switch rule is last and logs blocked traffic

Test 3.3: VPN Gateway Status

What we’re testing: Gateway monitoring detects online/offline status correctly

From: OPNsense Web UI

Expected result: Both VPN gateways show “Online”

How to test:

Navigate to: System → Gateways → Status

Success indicators:

• WAN_UK_VPN: Status = Online, RTT < 50ms, Loss = 0%
• WAN_DE_VPN: Status = Online, RTT < 50ms, Loss = 0%
• WAN_DHCP: Status = Online (but priority 254)

If this fails:

Check gateway monitor IPs are reachable:

# SSH into OPNsense
# Replace with your monitor IPs
ping -c 4 -S 10.65.196.16 100.64.0.1
ping -c 4 -S 10.65.135.45 100.64.0.2

Both should respond successfully

Verify gateway configuration:

• Navigate to System → Gateways → Configuration
• Check “Monitor IP” is set to Mullvad DNS (100.64.0.x)
• Verify “Far Gateway” is checked
• Confirm correct tunnel addresses are used

Gateway Failover Tests

Test 4.1: Primary VPN Failover

What we’re testing: Traffic switches to secondary VPN when primary fails

From: Client device + OPNsense SSH

Expected result: Internet continues working when primary VPN is disabled

How to test:

Step 1 - Establish baseline:

# From client device
curl ifconfig.me
# Note the IP (should be UK VPN)

Step 2 - Disable primary VPN:

• Navigate to VPN → WireGuard → Instances
• Disable UK_VPN (uncheck Enable)
• Apply changes

Step 3 - Verify failover:

# From client device - wait 30 seconds, then:
curl ifconfig.me
# Should now show DE VPN IP

Step 4 - Re-enable primary:

• Re-enable UK_VPN in WireGuard Instances

Success indicators:

• Brief interruption (< 30 seconds)
• IP changes from UK to DE location
• No complete loss of connectivity
• Gateway status shows UK_VPN offline, DE_VPN online

If this fails:

Check gateway group configuration:

• Navigate to System → Gateways → Group
• Verify WAN_VPN_GRP has both gateways in different tiers
• Tier 1: WAN_UK_VPN
• Tier 2: WAN_DE_VPN
• Trigger Level: Member Down

Check firewall rules use gateway group:

• Navigate to Firewall → Rules → VPN_OUT_IG
• Verify rule uses gateway “WAN_VPN_GRP” (not individual gateways)

Test 4.2: Gateway Monitoring Response Time

What we’re testing: System detects gateway failures quickly

From: OPNsense SSH

Expected result: Gateway marked offline within 30 seconds of failure

How to test:

Monitor gateway status in real-time:

# SSH into OPNsense
watch -n 2 'pfctl -vsr | grep "route-to"'

In another terminal, temporarily break a VPN:

# Disable WireGuard instance
service wireguard stop wg0

Observe status page: System → Gateways → Status

Success indicators:

• Gateway status changes to “Offline” within 20-30 seconds
• Packet loss increases to 100%
• RTT shows ”~” (unreachable)

Re-enable when done:

service wireguard start wg0

If this fails:

Adjust gateway monitoring settings:

• Navigate to System → Gateways → Configuration
• Edit gateway → Advanced
• Try lower probe interval (e.g., 1 second instead of default)
• Lower packet loss threshold if needed

Firewall Rule Tests

Test 5.1: Kill Switch Verification

What we’re testing: No traffic escapes through WAN when VPN is down

From: Client device + OPNsense SSH

Expected result: Complete internet loss when all VPNs are disabled

How to test:

Step 1 - Disable all VPNs:

• Navigate to VPN → WireGuard → Instances
• Disable both UK_VPN and DE_VPN
• Apply changes

Step 2 - Attempt internet access:

# From client device
ping 1.1.1.1
curl ifconfig.me

Success indicators:

• All internet traffic fails
• No packets reach external IPs
• DNS resolution may still work (local cache)

Step 3 - Check logs:

• Navigate to Firewall → Log Files → Live View
• Filter for “Kill Switch”
• Should see blocked packets logged

Step 4 - Re-enable VPNs:

• Re-enable both VPN instances

If this fails (internet still works): This is a critical security failure. Your traffic is leaking through WAN.

Check floating rules immediately:

# SSH into OPNsense
pfctl -sr | grep -i "kill switch"

Should show: block drop out log quick on igb0 inet from <VPN_OUT_IG> to ! <IPv4_RFC1918>

Verify floating rule exists:

• Navigate to Firewall → Rules → Floating
• Find “Kill Switch: Block all other WAN traffic”
• Verify it’s enabled and direction is “out” on WAN interface
• Ensure it’s the LAST floating rule (lowest priority)

Test 5.2: Inter-VLAN Communication

What we’re testing: VLANs can/cannot communicate based on rules

From: Device on LAN + Device on another VLAN

Expected result: Communication allowed/blocked per your rules

How to test:

Test 1 - LAN to DMZ (should work):

# From LAN device (10.0.0.x)
ping 10.0.10.1
# Should succeed

Test 2 - Guest to LAN (should fail):

# From Guest device (10.0.44.x)
ping 10.0.0.1
# Should timeout

Test 3 - IoT to other VLANs (should fail):

# From IoT device (10.0.42.x)
ping 10.0.40.1
ping 10.0.0.1
# Should timeout

Success indicators:

• LAN and SecWiFi (VLAN40) can reach each other
• DMZ accessible from LAN (if rule exists)
• Guest and IoT isolated from other networks

If this fails:

Check SEC_LAN_IG rules:

• Navigate to Firewall → Rules → SEC_LAN_IG
• Verify “Allow SEC_LAN intranet traffic” rule exists
• Source: SEC_LAN_IG net
• Destination: SEC_LAN_IG net

Check individual VLAN rules:

• Guest and IoT should have NO rules allowing access to other VLANs
• Only internet access rules should exist

Test 5.3: Port-Based Filtering

What we’re testing: Only allowed ports can reach internet

From: Client device on LAN

Expected result: Allowed ports work, blocked ports fail

How to test:

Test allowed port (HTTPS/443):

curl -I https://example.com
# Should return HTTP 200

Test blocked port (e.g., 25 SMTP if not in PORTS_OUT_WAN):

telnet smtp.gmail.com 25
# Should timeout or connection refused

Success indicators:

• Common ports (80, 443, 22) work
• Uncommon ports blocked unless explicitly allowed
• Firewall logs show blocked attempts

If this fails:

Check PORTS_OUT_WAN alias:

• Navigate to Firewall → Aliases
• Review PORTS_OUT_WAN contents
• Add/remove ports as needed

Check VPN_OUT_IG rules:

• Navigate to Firewall → Rules → VPN_OUT_IG
• Verify rule uses PORTS_OUT_WAN alias in destination port
• Not using “any” for ports

VLAN Isolation Tests

Test 6.1: Guest Network Isolation

What we’re testing: Guest VLAN cannot access internal resources

From: Device on VLAN44 (Guest)

Expected result: Internet works, local network inaccessible

How to test:

Should work:

# Internet access
curl ifconfig.me
ping 1.1.1.1

Should fail:

# Local network access
ping 10.0.0.1          # LAN gateway
ping 10.0.0.50         # LAN device
nslookup opnsense.home.byteron.com  # Local hostname

Success indicators:

• Full internet connectivity
• No access to any 10.0.x.x addresses except own gateway (10.0.44.1)
• Cannot resolve local hostnames

If this fails:

Verify Guest VLAN is NOT in SEC_LAN_IG:

• Navigate to Firewall → Groups
• SEC_LAN_IG should NOT include VLAN44 (Guest)

Check Guest VLAN rules:

• Navigate to Firewall → Rules → VLAN44 (if exists)
• Should only have internet access rules, no LAN access

Test 6.2: IoT Network Isolation

What we’re testing: IoT devices can only reach internet, not other VLANs

From: Device on VLAN42 (IoT)

Expected result: Same as Guest - internet only

How to test:

# Should work
ping 1.1.1.1

# Should fail
ping 10.0.0.1
ping 10.0.40.1

Success indicators:

• Internet access works
• Cannot reach LAN, SecWiFi, or DMZ
• Can reach own gateway (10.0.42.1) only

If this fails:

Same troubleshooting as Guest isolation test above.

Test 6.3: DMZ Isolation

What we’re testing: DMZ accessible from LAN but isolated from other VLANs

From: Multiple devices

Expected result: LAN can reach DMZ, other VLANs cannot

How to test:

From LAN device:

ping 10.0.10.1        # Should work
ping 10.0.10.100      # Should work

From Guest/IoT device:

ping 10.0.10.1        # Should timeout

Success indicators:

• LAN has full access to DMZ
• Other VLANs blocked from DMZ
• DMZ uses separate physical interface (igb2)

If this fails:

Check DMZ parent interface:

• Navigate to Interfaces → Devices → VLAN
• Verify VLAN10 parent is igb2 (not igb1)

Check LAN rules:

• Navigate to Firewall → Rules → LAN
• Should have rule allowing LAN net → DMZ_VL10 net

DNS Leak Prevention Tests

Test 7.1: DNS Leak Test (Web)

What we’re testing: DNS queries go through VPN, not ISP

From: Client device browser

Expected result: Only Mullvad DNS servers visible

How to test:

Visit: https://dnsleaktest.com

Click “Extended test”

Success indicators:

• All DNS servers belong to Mullvad (M247, Mullvad AB)
• No servers from your ISP
• DNS location matches VPN location
• At least 2-3 Mullvad servers shown

If this fails:

Check Unbound outgoing interfaces:

• Navigate to Services → Unbound DNS → General
• Advanced Mode → Outgoing Network Interfaces
• Should list only: DE_VPN, UK_VPN
• Should NOT include WAN

Check DNS NAT redirects:

• Navigate to Firewall → NAT → Port Forward
• Verify DNS redirect rules force port 53 to 10.0.0.1

Test 7.2: DNS Leak Test (Command Line)

What we’re testing: DNS queries don’t leak to ISP servers

From: Client device terminal

Expected result: DNS queries only go through VPN tunnel

How to test:

# Install dnsleaktest tool
curl -o dnsleaktest.py https://raw.githubusercontent.com/macvk/dnsleaktest/master/dnsleaktest.py
python3 dnsleaktest.py

Or manual test:

# Query with explicit DNS server
dig @8.8.8.8 whoami.akamai.net +short
# Should timeout or be blocked (can't reach 8.8.8.8 directly)

# Query normally
dig whoami.akamai.net +short
# Should work (goes through your DNS setup)

Success indicators:

• Direct queries to external DNS fail or timeout
• Normal queries work through your DNS chain
• No ISP DNS servers appear in results

If this fails:

Check floating rules for DNS blocking:

• Navigate to Firewall → Rules → Floating
• Should have rule: “Block external DNS - prevent leaks”
• Blocks LOCAL_IG from reaching IPv4_RFC1918 on port 53

Test 7.3: WebRTC Leak Test

What we’re testing: Browser WebRTC doesn’t leak real IP

From: Client device browser

Expected result: Only VPN IP visible, not real IP

How to test:

Visit: https://browserleaks.com/webrtc

Look at “IP Addresses” section

Success indicators:

• Only shows VPN IP addresses (10.65.x.x or public VPN IP)
• Does NOT show your real local IP (e.g., 192.168.x.x if that’s your ISP’s gateway)
• Does NOT show your ISP’s public IP

If this fails:

This is a browser-level issue, not OPNsense:

Firefox fix:

• Type about:config in address bar
• Set media.peerconnection.enabled to false

Chrome/Brave fix:

• Install extension: “WebRTC Leak Prevent”
• Set to “Disable non-proxied UDP”

Note: WebRTC leaks are hard to prevent at firewall level. Browser configuration is required.

Common Issues and Quick Fixes

Issue: No Internet After Setup

Quick checks:

1. VPN tunnels up? → VPN → WireGuard → Status
2. Gateways online? → System → Gateways → Status
3. DNS working? → ping 1.1.1.1 then ping google.com

Issue: Slow Internet Speed

Quick checks:

1. Hardware offloading enabled? → Interfaces → Settings
2. VPN server overloaded? → Try different Mullvad server
3. Gateway RTT high? → Check System → Gateways → Status

Issue: Some Sites Don’t Load

Quick checks:

1. AdGuard blocking too much? → Check AdGuard logs
2. MTU issues? → Try setting MTU to 1420 on WireGuard
3. DNSSEC failing? → Temporarily disable in Unbound

Issue: Can’t Access OPNsense GUI

Quick checks:

1. Anti-lockout rule exists? → Firewall → Rules → Floating
2. HTTPS enabled? → Try http://10.0.0.1 instead
3. Firewall blocking? → Check from LAN device, not Guest VLAN

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.