Trace DNS separately from an OPNsense selective WireGuard route

Bottom line: Follow the DNS request as its own path. Decide whether the policy concerns selected client traffic or all traffic from a shared resolver before changing where that resolver sends requests.

Source fact: what the authority says

The OPNsense selective WireGuard guide sends the selected hosts’ non-local traffic through the tunnel while retaining access to local resources. It warns that clients using a local DNS server can still have DNS requests processed through the normal WAN gateway rather than the tunnel. Routing a separate local DNS server through the selected-host alias affects all traffic from that server, not only DNS traffic for the selected clients. When a separate local resolver shares the clients’ subnet, the guide says those DNS requests do not traverse OPNsense, so a Destination NAT port-forward rule there cannot intercept them.

What the source does not establish

This article addresses the guide’s selective-routing and local-resolver topology, not a guarantee of anonymous browsing or complete leak prevention. It does not prescribe a universal DNS interception design or assume the same path for every client protocol.

Applicability questions

• Which resolver address does each selected client actually use?
• Is that resolver the firewall, another routed host or a same-subnet host?
• Do non-selected clients share the resolver?
• Must local names remain available, and what resolver traffic may use the tunnel?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

DSE recommends drawing two arrows for a proposed selected workstation: its application destination and its DNS resolver. Add a third arrow from the resolver to its next destination. Mark which devices and interfaces can observe each arrow instead of assuming all three requests carry the workstation’s routing policy.

For a proposed shared-resolver case, identify a non-selected client before changing resolver egress. Have the DNS and network owners decide whether moving the server’s entire traffic is acceptable. Do not add that server to the VPN-host alias solely to make one workstation’s public-address test look correct.

Keep the same-subnet resolver case separate from a routed resolver. Review an alternative documented client-DNS or resolver-egress design against local-name requirements before selecting it. Preserve the current DHCP and manual client settings so the change can be reversed for the actual affected population.

Record the intended privacy and availability requirements in operational terms. Name the person who accepts a resolver-path change and the person who checks local applications. Leave encrypted DNS, additional address families and provider-specific requirements open until their own supported configuration has been reviewed.

Verification and evidence

Proposed verification: from one selected client and one non-selected control client, perform approved external-name and local-name lookups. Observe the actual resolver and its outbound path using authorized network evidence. Compare those observations with the three-arrow diagram and retain unexpected WAN egress as a finding.

Repeat a representative application transaction after the approved change. Preserve client DNS settings, resolver identity and the corresponding route observations together. Treat a successful tunnel connection and an accepted DNS path as separate results rather than allowing either one to stand in for the other.

Official references

• OPNsense — WireGuard Selective Routing to External VPN Endpoint — official product documentation; confirm the installed release and configuration.

Source review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.