OPNsense DNS Firewall Blocklist Lab

A hands-on OPNsense lab demonstrating DNS-based website blocking using Unbound DNS.

The goal of this lab was to configure OPNsense to block access to a selected website, verify that the domain was intercepted by the firewall's DNS resolver, and confirm from a Windows client that the blocked website could no longer be reached.

Note: This lab uses the Unbound DNS Blocklist feature in OPNsense. It demonstrates DNS filtering rather than packet-level IP blocking.

• Deploy OPNsense in EVE-NG
• Connect OPNsense to a VMware NAT-backed network
• Configure Internet connectivity
• Use OPNsense as the Windows DNS resolver
• Create a custom DNS blocklist
• Block facebook.com
• Verify normal websites still resolve
• Confirm the blocked domain resolves to 0.0.0.0
• Verify the block from Microsoft Edge
• Troubleshoot routing and DNS connectivity

The lab uses a single OPNsense interface connected through an EVE-NG network cloud to the VMware VMnet8 network.

EVE-NG OPNsense Topology

Windows Client
192.168.138.1
 |
 | DNS Queries
 v
OPNsense
192.168.138.200
 |
 | Unbound DNS
 |
 +---- google.com
 | |
 | +---- Valid Public IP
 | |
 | +---- ALLOWED
 |
 +---- facebook.com
 |
 +---- 0.0.0.0
 |
 +---- BLOCKED

From the OPNsense web interface, navigate to:

Services > Unbound DNS > Blocklists

The Blocklists section allows custom domains to be added to the Unbound DNS filtering policy.

Unbound DNS Blocklists

A new blocklist entry was created for Facebook.

The following settings were used:

Enable: Yes
Blocklist Domains: facebook.com
Wildcard Domains: facebook.com
Description: social media block test

Facebook Blocklist Configuration

The domain was added to both Blocklist Domains and Wildcard Domains so the policy could cover the main domain and related subdomains.

After saving the configuration, the Facebook block appeared in the Unbound DNS blocklist table.

Facebook Blocklist Enabled

The configuration was then applied so Unbound DNS could begin enforcing the policy.

The Windows client was configured to use the OPNsense IP address as its preferred DNS server.

Preferred DNS Server: 192.168.138.200

After changing the DNS server, the local Windows DNS cache was cleared.

ipconfig /flushdns

This ensures that previously cached DNS responses do not interfere with testing.

Google was tested directly against the OPNsense DNS resolver.

nslookup google.com 192.168.138.200

Example result:

Server: OPNsense.internal
Address: 192.168.138.200
Non-authoritative answer:
Name: google.com
Addresses:
 2404:6800:4006:80a::200e
 172.217.25.174

This confirms that OPNsense can resolve normal Internet domains successfully.

google.com -> Valid IP Address -> ALLOWED

Facebook was then tested against the same DNS resolver.

nslookup facebook.com 192.168.138.200

Result:

Server: OPNsense.internal
Address: 192.168.138.200
Name: facebook.com
Address: 0.0.0.0

Instead of returning Facebook's actual public IP address, OPNsense returned:

0.0.0.0

This confirms that the Unbound DNS blocklist intercepted the DNS request.

facebook.com -> 0.0.0.0 -> BLOCKED

After applying the blocklist and configuring Windows to use OPNsense for DNS, Facebook could no longer be reached from Microsoft Edge.

Facebook Blocked in Microsoft Edge

This provided client-side confirmation that the DNS filtering policy was working.

During the initial setup, OPNsense was successfully responding to blocked DNS requests but could not resolve normal external domains.

For example:

nslookup google.com 192.168.138.200

initially returned:

Server failed

A connectivity test from OPNsense to:

8.8.8.8

showed:

100% packet loss

This indicated that OPNsense did not have a working route to the Internet.

The VMware Virtual Network Editor was checked and the VMnet8 NAT gateway was identified as:

192.168.138.2

A gateway was then configured in OPNsense using:

Gateway: 192.168.138.2
Network: 192.168.138.0/24

After configuring the gateway, Internet connectivity was restored.

The following command then successfully resolved Google:

nslookup google.com 192.168.138.200

while Facebook continued returning:

facebook.com -> 0.0.0.0

This confirmed that both normal DNS resolution and the blocklist were functioning correctly.

ipconfig /flushdns

nslookup google.com 192.168.138.200

nslookup facebook.com 192.168.138.200

nslookup google.com

nslookup facebook.com

google.com
-> Valid public IPv4 / IPv6 addresses
-> ALLOWED

facebook.com
-> 0.0.0.0
-> BLOCKED

• OPNsense
• Unbound DNS
• EVE-NG
• VMware Workstation
• VMware VMnet8 NAT
• Microsoft Windows 11
• Microsoft Edge
• Windows Command Prompt
• nslookup
• ipconfig

• OPNsense administration
• EVE-NG network lab configuration
• VMware virtual networking
• Unbound DNS configuration
• DNS-based website filtering
• DNS policy implementation
• Default gateway configuration
• Windows DNS configuration
• DNS troubleshooting
• Network connectivity testing
• nslookup
• ipconfig
• Client-side policy verification
• Network troubleshooting

This lab demonstrates how OPNsense Unbound DNS filtering can be used to control access to selected domains.

Normal DNS resolution:

google.com
 |
 v
OPNsense DNS
 |
 v
Valid Public IP
 |
 v
Website Accessible

Blocked DNS resolution:

facebook.com
 |
 v
OPNsense DNS Blocklist
 |
 v
0.0.0.0
 |
 v
Website Inaccessible

Instead of returning the real IP address of the blocked website, OPNsense returns 0.0.0.0, preventing the client from reaching the destination through normal DNS resolution.

In a production environment, DNS filtering would normally be combined with additional controls such as:

• Firewall rules
• Secure DNS enforcement
• Endpoint security policies
• Web filtering
• Application control
• Secure web gateways
• Logging and monitoring

Firewall-Blocklist/
│
├── README.md
│
└── Firewall Blocklist/
 │
 ├── Screenshot 2026年08月16日 234002.png
 ├── Screenshot 2026年08月16日 235143.png
 ├── Screenshot 2026年08月16日 235413.png
 ├── Screenshot 2026年08月16日 235451.png
 └── Screenshot 2026年08月17日 001400.png

The lab successfully demonstrated DNS-based website filtering using OPNsense and Unbound DNS.

The final results were:

Google -> ALLOWED
Facebook -> BLOCKED
OPNsense -> DNS Resolver
Windows -> Test Client

The lab also provided practical troubleshooting experience involving DNS resolution, VMware NAT networking, gateway configuration, and client-side validation.

Jamill Naipao

Aspiring Network / Infrastructure Engineer