How The Social Dork Builds an OPNsense Home Firewall

Thank you to The Social Dork | Cyber Security for sharing an OPNsense home-firewall build on ZimaBoard 2. A virtual machine handles routing and firewall policy, an access point provides Wi-Fi, and Pi-hole supplies DNS filtering for connected clients. Watch the original YouTube walkthrough for the complete demonstration.

Watch before reading: This roughly ten-minute video is useful if you want to separate your network gateway from your wireless access point. The creator explains the topology, boots OPNsense in Zima Virtual Machine, assigns interfaces and DHCP, then checks a wireless laptop and its DNS filtering.

The demonstrated milestone is a laptop reaching the network through the new firewall and using the chosen DNS filter. The video is a first-client walkthrough. Its introductory concern about vulnerable IoT devices would require additional network separation and access policy; putting devices on one new SSID does not by itself isolate them from each other.

Decide which jobs the existing gateway must keep

The topology discussion separates three jobs that an all-in-one router can hide: the provider connection, the routed firewall boundary, and wireless access. An Ethernet handoff can feed the new firewall, while a DSL or cable service still needs the appropriate modem or provider equipment. Replacing the routing function does not remove that physical connection requirement.

In the creator’s working setup, the existing home router feeds the firewall’s WAN side and an access point sits on its LAN side. If the upstream gateway also performs network address translation, this creates double NAT. That can be acceptable for an initial test, but it can complicate inbound services and troubleshooting. Whether bridge or passthrough mode is available depends on the provider equipment and service; confirm that before changing the production connection.

Write down the current provider-facing settings before a cutover. A video showing an Ethernet handoff does not establish your ISP’s authentication, VLAN, or modem requirements. Keep the old gateway configuration available while you test the new path with one client. This makes it possible to separate an upstream service problem from a mistake in the new LAN.

Double NAT describes two routed translation boundaries; it is different from simply having an access point downstream. If the wireless device also continues routing, it can introduce another boundary and another DHCP service. Confirm its actual operating mode and cable placement instead of identifying its role by the product label on the case.

Map the virtual interfaces to a real WAN and LAN boundary

The Social Dork downloads an OPNsense installation image and boots it in Zima Virtual Machine on ZimaBoard 2. This is a virtualized firewall demonstration. The host still runs ZimaOS, so its networking arrangement is part of the design as well as the OPNsense settings inside the guest.

For a similar deployment, explicitly map each virtual interface to the intended physical port or isolated host network. A pair of network sockets does not establish that mapping automatically. Keep the WAN-facing path separated from ordinary host services, and ensure that LAN client traffic must cross the firewall to reach the upstream connection. If a client has another route around the VM, the firewall cannot enforce policy on that traffic.

Use the current OPNsense installation instructions and virtual-machine guidance for the selected image and platform. Record how to reach the host and VM console before changing interfaces. A host reboot, storage problem, or VM shutdown can interrupt this gateway, so schedule maintenance with the household connection in mind.

Make the interface plan explicit

1. Identify the host’s physical ports and record which cable reaches the upstream connection.
2. Map the guest’s WAN-facing interface to the intended upstream network.
3. Map its LAN-facing interface to a distinct downstream network.
4. Confirm that the management path and ordinary host services are not unintentionally exposed through the WAN side.
5. Connect one test client downstream and verify its actual default gateway before adding other devices.

An interface name inside the guest may not match a label printed beside a physical port. Use the hypervisor’s network mapping and the guest console to establish the relationship. Check it again after changing virtual adapters. The video demonstrates a working arrangement on the creator’s machine, but it is not a complete inventory of every host bridge or adapter setting you may encounter.

Allocate resources for the firewall while leaving capacity for ZimaOS and the other services on the host. The current OPNsense virtualization guide lists a 3 GB RAM minimum, an 8 GB minimum recommended virtual disk, and networking compatibility guidance. Those are starting conditions, not a throughput promise. Logs, VPNs, inspection features, and other workloads can change the required headroom.

This is an operational tradeoff of sharing one machine: an update or restart of the host can also take down the gateway VM. Decide how the VM starts after boot and how you will recover if it does not. A stable console path is particularly useful when a mistaken network setting makes the web interface unreachable.

Let one DHCP service manage each client network

The creator uses different upstream and downstream IPv4 networks: the upstream side uses 192.168.0.x addresses and the client LAN uses 192.168.1.x addresses. These are examples from the video. Choose non-overlapping subnets that suit your own network rather than copying addresses that may already be in use.

The access point supplies the radio connection, while OPNsense serves the downstream clients’ DHCP leases. The walkthrough discusses AP mode and disabling the old wireless router’s DHCP service. On equipment without a dedicated AP mode, disabling DHCP alone does not guarantee transparent access-point behavior: verify the vendor’s LAN-to-LAN wiring and routing/NAT requirements. Keep its management address reachable without conflicting with the DHCP pool.

Test the resulting lease on one laptop. It should receive an address in the intended LAN, the firewall’s LAN address as its default gateway, and the intended DNS server. Successful Wi-Fi association only proves that the radio connection works. The address, gateway, and resolver show whether the client has actually joined the new network path.

Plan fixed addresses and the lease pool separately

The following is an illustrative /24 LAN plan, not a transcription of the creator’s exact addresses. Adapt it to your existing networks. Reserve fixed infrastructure addresses outside the dynamically assigned pool, and keep the upstream network different from the downstream LAN.

If Pi-hole actually resides on another subnet or on a host-side virtual network, use its real reachable endpoint and the necessary routing and policy. The example address does not make the service appear on the LAN by itself. A DHCP entry tells clients where to send a request; it does not establish the route or start the server.

After changing DHCP, inspect the lease on the laptop rather than checking only the server’s configuration page. Confirm the assigned address, mask, gateway, and DNS entries. A client that still holds an old lease can make a correct new setup look broken. An unexpected address or gateway is also a useful sign that another DHCP server remains active.

Treat the first allow rule as a connectivity test

The creator begins with a permissive outbound rule for the single test laptop and discusses preventing unsolicited connections from the WAN toward the LAN. OPNsense uses stateful filtering, so replies to an allowed connection are handled through connection state. The OPNsense firewall rules documentation explains how interface, direction, and rule order affect that behavior.

The video also opens the web interface from its private upstream network. In your own deployment, keep administrative access restricted to a trusted management path and retain a console recovery option. The WAN label describes a role relative to this firewall; an upstream private lab segment and the public internet are different exposure conditions.

To address the IoT concern raised at the start, create distinct networks with equipment that supports them, then define the traffic allowed between them. Devices exchanging traffic within the same local segment may communicate without crossing the routed firewall. For another practical view of gateway and privacy decisions, see cachito labs’ OPNsense firewall build.

Separate connectivity from isolation

Define the source, destination, protocol, and intended purpose before adding a rule. A rule that proves one laptop can reach the internet is not a policy for every device in a household. For segmentation, use distinct networks and a firewall path between them. Traffic exchanged locally on the same segment may not reach the gateway at all.

When a rule change seems ineffective, test a fresh connection and consider connection state. The OPNsense rules guide explains stateful processing. Existing states can affect a retest, while resetting every state would interrupt other active connections. Identify the specific test flow before making a broad diagnostic change.

Connect Pi-hole through DHCP without creating a DNS loop

Near the end, The Social Dork sets the DHCP-provided DNS server to Pi-hole’s address. That brings the earlier Pi-hole and Tailscale ad-blocking project into the new wireless network. OPNsense controls the routed traffic path; Pi-hole evaluates DNS names requested through its service. The two components have different responsibilities.

Pi-hole’s OPNsense integration guide describes direct DHCP distribution and forwarding through the firewall as alternative arrangements. Choose a consistent path and ensure that the resolvers do not forward queries back to each other in a loop. Also verify that the clients are allowed to reach the Pi-hole address if it is on a different network.

Choose one resolver path and draw it end to end

The video uses the DHCP-provided Pi-hole address for clients. The forwarding arrangement in the linked official guide is an alternative. If you choose it, make sure that Pi-hole’s upstream does not send the request straight back into the same forwarding chain. A clear path makes an absent response much easier to diagnose.

DNS also has a transport and routing dependency. If client and resolver live on different networks, check the path and relevant TCP/UDP port 53 policy. Review IPv6 DNS advertisements and independent client DNS settings when the observed result differs from the DHCP configuration. Reaching the Pi-hole web interface alone is not sufficient evidence.

For away-from-home filtering, revisit the companion Pi-hole and Tailscale walkthrough. Remote DNS access, local gateway policy, and full internet egress through a VPN are separate decisions. Test each one on the connection where it will actually be used.

Verify the whole path before moving every device

The final demonstration changes the laptop’s Wi-Fi network and compares the same website with and without the filtering setup. It illustrates the selected client path, rather than proving that all websites are ad-free or that all devices are isolated. Validate internet access and DNS first, then inspect the relevant firewall and Pi-hole logs to connect each result to the intended client.

Before moving the household, test a client renewal, a permitted connection, and a deliberately denied connection between separate networks if segmentation is part of your design. Export a working firewall configuration and confirm the recovery path. The useful outcome is a gateway whose routing, DHCP, filtering, and administration you can explain and maintain. Watch The Social Dork’s complete OPNsense home-firewall walkthrough for the original topology and setup sequence.

Use a staged acceptance test

1. Join the intended wireless network and inspect the new client lease.
2. Confirm the default gateway, then test a permitted IP-based connection where appropriate.
3. Resolve a permitted hostname through the selected resolver and find the query.
4. Test a domain in the active Pi-hole policy and confirm the expected response.
5. If you configured segmentation, test both an allowed and a denied connection across the routed boundary.
6. Reconnect or renew the client lease and confirm the intended settings return.
7. During a planned maintenance window, verify the host and gateway VM startup path before relying on it continuously.

Troubleshoot in network order

Use logs to answer one question at a time. OPNsense’s firewall logging documentation explains that a stateful flow does not necessarily produce a new live-log line for every packet. The firewall diagnostics guide provides the state view. A quiet log alone does not prove that no traffic crossed the firewall.

Save a working configuration before a significant change and retain a clear rollback plan. During testing, keep the old connection available separately; avoid accidentally joining the upstream and downstream networks around the firewall. A useful rollback restores a known gateway and client configuration, rather than introducing two competing routers into the same client segment.

FAQ

Can ZimaBoard 2 replace the Wi-Fi radio by itself?

In this video, a separate access point provides Wi-Fi. The board hosts the virtualized gateway and related services. Routing and wireless access are different roles.

Can I remove the ISP modem?

Only if your service handoff no longer requires it. DSL, cable, and provider-specific setups may still need their original termination equipment. Confirm the physical and service requirements before replacing a gateway.

Does an allow-outbound rule isolate IoT devices?

It does not create network separation. Devices on one local segment may communicate without crossing the routed firewall. Isolation needs distinct networks and a tested policy between them.

Should Pi-hole run inside OPNsense?

The demonstrated project uses a Pi-hole service alongside the virtualized firewall and advertises its address through DHCP. The important requirement is a reachable, consistent DNS path; do not assume that installing OPNsense also installs that service.

Why does the firewall VM need two network paths?

The routed design needs an upstream-facing path and a separate downstream path. Correct guest-to-host mapping establishes that boundary. Two visible adapter names alone do not prove that the networks are isolated.

What happens when the ZimaOS host is restarted?

Its guest firewall and other hosted services can become unavailable. Plan VM startup and recovery, then verify them during a maintenance window. Shared hardware makes host maintenance part of gateway availability.

Conclusion

The Social Dork’s build is useful because it turns an all-in-one gateway into a set of understandable jobs: provider connectivity, virtualized routing, wireless access, address assignment, and DNS filtering. Its first successful laptop test establishes a starting point. A maintained home gateway also needs verified network boundaries, a policy appropriate to each client group, and a recovery path.

Complete the single-client checks before moving the household, then validate any additional segmentation or VPN behavior independently. Keep the original OPNsense video walkthrough beside your own interface plan and the current official documentation. The outcome to aim for is a network whose behavior you can explain, test, and restore.