Testing Your OPNsense Setup

Run tests in order since later tests depend on earlier ones passing. If the kill switch test (5.1) fails, your ISP sees all traffic.

Basic Connectivity Tests

Test 1.1: DHCP Assignment

Windows: ipconfig | macOS/Linux: ip addr | Mobile: Settings → Wi-Fi → Network details

Expect:

• IP within your DHCP range (e.g., 10.0.0.100 - 10.0.0.150)
• Gateway matches VLAN gateway (e.g., 10.0.0.1)
• DNS server set to gateway IP

Test 1.2: Gateway Reachability

ping -c 4 <your-gateway-ip>

Example gateways: LAN 10.0.0.1 | SecWiFi 10.0.40.1 | Guest 10.0.44.1 | IoT 10.0.42.1

Expect:

4 packets transmitted, 4 received, 0% packet loss

Test 1.3: Internet Connectivity

ping -c 4 1.1.1.1

Expect:

4 packets transmitted, 4 received, 0% packet loss

DNS Resolution Tests

Test 2.1: Basic DNS Resolution

nslookup github.com

Expect:

Server:        10.0.0.1
Address:       10.0.0.1#53

Name:    github.com
Address: 140.82.121.3

Test 2.2: Local Domain Resolution

This test requires DNSmasq host overrides configured. See Local Domain Names guide for setup.

nslookup nas.home.byteron.com

Expect:

Server:        10.0.0.1
Address:       10.0.0.1#53

Name:    nas.home.byteron.com
Address: 10.0.10.50

The IP returned depends on your DNSmasq configuration, either a specific host override or wildcard entry pointing to your reverse proxy.

Test 2.3: AdGuard Filtering

This test requires AdGuard Home with blocklists configured. See the AdGuard Home configuration guide for blocklist setup.

nslookup doubleclick.net

Expect:

Server:        10.0.0.1
Address:       10.0.0.1#53

Name:    doubleclick.net
Address: 0.0.0.0

AdGuard blocks the domain by returning 0.0.0.0.

Test 2.4: VLAN46 Bypasses AdGuard

nslookup doubleclick.net

Expect:

• Returns real IP addresses (not 0.0.0.0)
• Browser can load ad/tracking sites

VPN Tunnel Tests

Test 3.1: VPN Tunnel Status

wg show

Expect:

interface: wg0
  public key: H8mPI4ZE...
  private key: (hidden)
  listening port: 51820

peer: hf+klJbI...
  endpoint: <VPN_SERVER_IP>:51820
  allowed ips: 0.0.0.0/0
  latest handshake: 1 minute, 50 seconds ago
  transfer: 407.93 GiB received, 6.32 GiB sent

interface: wg1
  public key: vpDqhKQT...
  private key: (hidden)
  listening port: 51819

peer: flq7zR8W...
  endpoint: <VPN_SERVER_IP>:51815
  allowed ips: 0.0.0.0/0
  latest handshake: 1 minute, 6 seconds ago
  transfer: 320.44 MiB received, 125.80 MiB sent

Both tunnels should show recent handshakes (< 2-3 minutes) and transfer data.

Test 3.2: Exit IP Verification

curl ifconfig.me

Expect:

194.36.25.XX

The IP should be your VPN provider’s IP, not your real ISP IP. Verify at https://whatismyipaddress.com that the location shows VPN country, not your actual location.

Test 3.3: VPN Gateway Status

Navigate to: System → Gateways → Status

Expect:

Name         | Gateway      | Monitor    | RTT    | Loss | Status
-------------|--------------|------------|--------|------|--------
WAN_UK_VPN   | 10.65.x.x    | 100.64.0.1 | 25ms   | 0%   | Online
WAN_DE_VPN   | 10.65.x.x    | 100.64.0.2 | 35ms   | 0%   | Online
WAN_DHCP     | <ISP_GW>     | <ISP_IP>   | 10ms   | 0%   | Online

Both VPN gateways should show Online with low RTT and 0% loss.

Test 3.4: Static Route Verification

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

Expect: Each VPN endpoint IP routed through your WAN gateway:

Destination        Gateway         Flags     Netif
185.65.135.202/32  <ISP_GW>        UGS       igb0
185.209.196.77/32  <ISP_GW>        UGS       igb0

Without these routes, VPN tunnels cannot establish due to circular routing — traffic destined for the VPN endpoint gets routed through the tunnel that doesn’t exist yet.

Gateway Failover Tests

Test 4.1: Primary VPN Failover

1. Run curl ifconfig.me and note the IP (should be primary VPN)
2. VPN → WireGuard → Instances → Disable UK_VPN → Apply
3. Wait 30 seconds, run curl ifconfig.me again
4. Re-enable UK_VPN

Expect:

• IP changes from UK to DE VPN location
• Gateway status shows UK_VPN offline

Test 4.2: Gateway Monitoring Response Time

1. Open System → Gateways → Status in browser
2. SSH into OPNsense and run service wireguard stop wg0
3. Watch gateway status page
4. Run service wireguard start wg0 to restore

Expect:

• Gateway status changes to “Offline” within 20-30 seconds
• Packet loss shows 100%

Firewall Rule Tests

Test 5.1: Kill Switch Verification

1. VPN → WireGuard → Instances → Disable both UK_VPN and DE_VPN
2. Run ping 1.1.1.1 and curl ifconfig.me from a client device
3. From Plex server: curl ifconfig.me → Should return your WAN IP
4. Check Firewall → Log Files → Live View → Filter for “Kill Switch”
5. Re-enable both VPN instances

Expect:

• All client internet traffic fails — no packets reach external IPs
• Plex server still has internet via WAN (floating rule with Quick bypasses kill switch)
• Firewall logs show blocked packets from kill switch rule

Test 5.2: Inter-VLAN Communication

Test with ping -c 2 <target-gateway> from each source VLAN:

Key points:

• LAN and SecWiFi can reach each other and DMZ (SEC_LAN_IG rules)
• DMZ cannot initiate connections back to LAN or SecWiFi (prevents lateral movement)
• Guest, IoT, and GoatNET are fully isolated from all other networks

Test 5.3: Management Access Control

From each untrusted VLAN, test against its own gateway IP:

curl -k --connect-timeout 5 https://<gateway>:443
ssh -o ConnectTimeout=5 root@<gateway>

Only SEC_LAN_IG networks (LAN, SecWiFi) can reach OPNsense management ports.

Test 5.4: Port-Based Filtering

# Allowed port
curl -I https://example.com
# Blocked port
telnet smtp.gmail.com 25

Expect:

• curl returns HTTP 200 — common ports (80, 443) work
• telnet times out — port 25 not in PORTS_OUT_WAN alias

Test 5.5: NTP Redirect Verification

ntpdate -q pool.ntp.org

Expect:

• Command succeeds — NAT redirect catches the query and sends it to OPNsense
• Time offset is small (< 1 second)

Test 5.6: WAN Inbound Scan

From a device outside your network:

nmap -sT -p 22,80,443,8080,32400 <your-WAN-IP>

Expect:

• Only ports with active NAT port forwards respond (e.g., 32400 for Plex, 443 for reverse proxy)
• Everything else filtered or closed

VLAN Isolation Tests

Test 6.1: Guest Network Isolation

Should work: curl ifconfig.me and ping 1.1.1.1

Should fail: ping 10.0.0.1 (LAN gateway) and nslookup nas.home.byteron.com

Expect:

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

Test 6.2: IoT Network Isolation

Should work: ping 1.1.1.1

Should fail: ping 10.0.0.1 and ping 10.0.40.1

Expect:

• Internet access works
• Cannot reach LAN, SecWiFi, or DMZ

Test 6.3: DMZ Access Control

Test with ping -c 2 <target> from each source:

Key points:

• SEC_LAN_IG networks (LAN, SecWiFi) can reach DMZ
• Guest, IoT, GoatNET blocked from DMZ
• DMZ cannot reach LAN or SecWiFi (prevents lateral movement if DMZ is compromised)

Test 6.4: GoatNET Isolation

Should work: curl ifconfig.me and ping 1.1.1.1

Should fail: ping 10.0.0.1, ping 10.0.10.1, and ping 10.0.40.1

Expect:

• Internet access works through VPN
• Cannot reach LAN, SecWiFi, DMZ, Guest, or IoT networks
• Only own gateway 10.0.46.1 is reachable

DNS Leak Prevention Tests

Test 7.1: DNS Leak Test (Web)

Visit https://dnsleaktest.com and click “Extended test”

Expect:

• All DNS servers belong to your VPN provider
• No servers from your ISP
• DNS location matches VPN country

Test 7.2: DNS NAT Redirect Verification

The DNS NAT redirect on DNS_ADGUARD_IG rewrites all port 53 traffic to AdGuard on 10.0.0.1. NAT rewriting happens before firewall filtering in OPNsense, so the floating DNS block rule is defense-in-depth for cases where NAT doesn’t apply.

dig @8.8.8.8 doubleclick.net +short

Expect: Returns 0.0.0.0

This proves the query never reached Google DNS — Google doesn’t block doubleclick.net. The NAT redirect caught the query and sent it to AdGuard, which returned 0.0.0.0.

Verify both paths return the same result:

dig doubleclick.net +short           # Normal path → should return 0.0.0.0
dig @8.8.8.8 doubleclick.net +short  # Redirected → should also return 0.0.0.0

If @8.8.8.8 returns a real IP instead of 0.0.0.0, the NAT redirect is broken and DNS is leaking to Google.

Test 7.3: WebRTC Leak Test

Visit https://browserleaks.com/webrtc and check “IP Addresses” section

Expect:

• Only shows VPN IP (10.65.x.x or public VPN IP)
• Does NOT show your ISP’s public IP

Test 7.4: Mullvad Connection Check

Visit https://mullvad.net/en/check

This tool checks everything at once: your IP address, DNS servers, and WebRTC leaks. Even if you’re not using Mullvad VPN, this tool works for any VPN provider.

Expect:

• Green checkmarks across all categories
• IP address shows VPN server location (not your real location)
• DNS servers belong to your VPN provider (not your ISP)
• No WebRTC leaks detected

Test 7.5: IPv6 Leak Test

IPv6 leaks are one of the most common VPN bypass vectors. If a client has IPv6 connectivity and OPNsense doesn’t handle it, traffic goes around the VPN entirely.

ping6 -c 4 2001:4860:4860::8888
curl -6 ifconfig.me

Expect:

• ping6 fails with “Network unreachable”
• curl -6 fails with connection error

Verify on OPNsense SSH:

ifconfig | grep inet6

Expect: No global IPv6 addresses. Link-local fe80:: entries are acceptable.

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.