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.
\nThe 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.
\nThis 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.
\nThe following steps are DSE recommendations based on the cited source.
\nDSE 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.
\nFor 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.
\nKeep 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.
\nRecord 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.
\nProposed 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.
\nRepeat 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.
\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "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.\nSource fact: what the authority says\nThe 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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nWhich resolver address does each selected client actually use?\nIs that resolver the firewall, another routed host or a same-subnet host?\nDo non-selected clients share the resolver?\nMust local names remain available, and what resolver traffic may use the tunnel?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE 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.\nFor 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.\nKeep 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.\nRecord 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.\nVerification and evidence\nProposed 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.\nRepeat 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.\nOfficial references\n\nOPNsense — WireGuard Selective Routing to External VPN Endpoint — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "content_markdown": "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.\n\n## Source fact: what the authority says\n\nThe [OPNsense selective WireGuard guide](https://docs.opnsense.org/manual/how-tos/wireguard-selective-routing.html) 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.\n\n## What the source does not establish\n\nThis 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.\n\n## Applicability questions\n\n- Which resolver address does each selected client actually use?\n\n- Is that resolver the firewall, another routed host or a same-subnet host?\n\n- Do non-selected clients share the resolver?\n\n- Must local names remain available, and what resolver traffic may use the tunnel?\n\n## DSE recommendation: controlled next steps\n\nThe following steps are DSE recommendations based on the cited source.\n\nDSE 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.\n\nFor 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.\n\nKeep 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.\n\nRecord 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.\n\n## Verification and evidence\n\nProposed 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.\n\nRepeat 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.\n\n## Official references\n\n- [OPNsense — WireGuard Selective Routing to External VPN Endpoint](https://docs.opnsense.org/manual/how-tos/wireguard-selective-routing.html) — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/trace-dns-separately-from-an-opnsense-selective-wireguard-route/", "url": "https://update.dsesecurity.com/updates/trace-dns-separately-from-an-opnsense-selective-wireguard-route/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-29" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/trace-dns-separately-from-an-opnsense-selective-wireguard-route/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Cybersecurity", "item": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "ListItem", "position": 3, "name": "Trace DNS separately from an OPNsense selective WireGuard route", "item": "https://update.dsesecurity.com/updates/trace-dns-separately-from-an-opnsense-selective-wireguard-route/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/trace-dns-separately-from-an-opnsense-selective-wireguard-route/#article", "identifier": "https://update.dsesecurity.com/updates/trace-dns-separately-from-an-opnsense-selective-wireguard-route/", "url": "https://update.dsesecurity.com/updates/trace-dns-separately-from-an-opnsense-selective-wireguard-route/", "headline": "Trace DNS separately from an OPNsense selective WireGuard route", "description": "The selective WireGuard guide warns that local DNS can continue through normal WAN routing.", "abstract": "The selective WireGuard guide warns that local DNS can continue through normal WAN routing. A same-subnet resolver also lies outside the documented firewall port-forward interception path.", "articleBody": "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.\nSource fact: what the authority says\nThe 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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nWhich resolver address does each selected client actually use?\nIs that resolver the firewall, another routed host or a same-subnet host?\nDo non-selected clients share the resolver?\nMust local names remain available, and what resolver traffic may use the tunnel?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE 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.\nFor 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.\nKeep 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.\nRecord 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.\nVerification and evidence\nProposed 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.\nRepeat 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.\nOfficial references\n\nOPNsense — WireGuard Selective Routing to External VPN Endpoint — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "datePublished": "2026-10-29T19:49:42+00:00", "dateModified": "2026-10-29T19:50:08+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/trace-dns-separately-from-an-opnsense-selective-wireguard-route/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/trace-dns-separately-from-an-opnsense-selective-wireguard-route/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Trace DNS separately from an OPNsense selective WireGuard route" }, "articleSection": [ "Cybersecurity", "Networks & Infrastructure" ], "keywords": [ "Cybersecurity", "Networks & Infrastructure", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "Thing", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "wordCount": 546, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "OPNsense — WireGuard Selective Routing to External VPN Endpoint", "url": "https://docs.opnsense.org/manual/how-tos/wireguard-selective-routing.html" } } ] } }