Hide Network Traffic with Router (Dual WAN VPN)
A dual-WAN VPN router sends chosen devices through an encrypted tunnel over either of two internet links. To prevent exposure, its firewall must block those devices from using either link directly, even when the VPN drops or the router switches providers. This hides traffic details from your access ISP, but not from the VPN service or the sites you visit.
Router upgrades often happen during seasonal sales or before holiday travel, when home networks may gain new devices and more remote access. If you are reviewing your setup now, focus on the routing rules, not just the router’s “VPN” feature. A tunnel can encrypt traffic while it is active, but a loose failover rule may send traffic straight to your ISP when it drops.
I start with one question: what should stop working if the VPN fails? For protected devices, the answer should be internet access, unless an approved exception says otherwise. That is the basis of a fail-closed design.
Planning the dual-WAN VPN threat model and network layout
A threat model names what you want to protect and who might see your traffic. For this setup, the usual goal is to keep your access ISP from reading traffic details from selected devices. The design should also accept that the VPN provider and destination services can still observe some information.
A VPN encrypts traffic between your router and the VPN server. Your ISP can generally see that you connected to a VPN server, along with connection times and data volume. It should not be able to read the contents of that tunnel, but a VPN does not make you anonymous. The provider may see traffic leaving its servers, and websites may identify you through accounts, cookies, or other signals.
Decide which devices need the tunnel. A work computer, household phones, and a guest network may need different rules. Use a separate network, such as a VLAN, for devices that should not use the VPN. A VLAN is a way to keep groups of devices on separate logical networks, even when they share a router.
Before configuring anything, list:
- Router model and firmware, including support for policy routing and firewall rules on both WAN links.
- Primary and secondary WAN gateways, and whether either has a changing public IP address.
- LAN, VLAN, and VPN address ranges.
- VPN protocol, provider, server details, and how the router handles reconnects.
- Which devices need the tunnel, which DNS services they use, and whether they use IPv6.
Avoid overlapping subnets. RFC 1918 defines common private IPv4 ranges: 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. If your LAN and an upstream modem use the same range, routing can fail or become hard to diagnose. Choose distinct ranges for each network.
The security rule is least privilege: allow protected devices only the routes they need. RFC 4301 describes IPsec architecture, and RFC 7296 describes IKEv2, a protocol used to set up IPsec connections. These references help explain the technology; router menus and setup steps still depend on the device and provider.
Checking WAN, DNS, IPv6, and fail-closed routing requirements
Fail-closed routing means protected devices lose internet access rather than bypassing the VPN when the tunnel fails. This rule must cover both WAN links, DNS traffic, and IPv6. A router’s “VPN connected” status alone does not prove the firewall will block direct traffic during an outage.
Check whether the router supports a VPN kill switch that applies to both WAN interfaces. A kill switch is a firewall rule or set of rules that blocks direct internet access when the tunnel is unavailable. Confirm that it applies to the devices or network group you intend to protect, not only to traffic from the router itself.
DNS translates names, such as a website address, into IP addresses. Set an explicit DNS resolver that is reachable through the VPN, then enforce that route in the firewall. Do not assume that entering a DNS address in the router prevents leaks. A device may use a different resolver or encrypted DNS.
Check both standard DNS paths: UDP and TCP port 53. Also consider encrypted DNS, such as DNS over TLS on port 853 and DNS over HTTPS, which often uses port 443. A firewall can block or control some paths, but blocking all HTTPS traffic is not a practical way to stop DNS over HTTPS. If you need to control it, use device or browser policies that your network can manage.
IPv6 needs its own plan. An IPv4-only VPN policy does not automatically protect IPv6 traffic. Either route IPv6 through the VPN with matching firewall rules, or block IPv6 on the protected network. Test this from a client, since a router setting alone may not show what that device is doing.
Ethernet’s common IP MTU is 1500 bytes. VPN encapsulation adds overhead, so the tunnel may need a lower MTU to avoid broken or slow connections. A value of 1420 bytes is a common WireGuard starting point, not a universal setting. Use the value supported by the router and VPN provider, then test real traffic.
Configuring the VPN tunnel, policy routes, and firewall
Policy routing sends traffic along a chosen path based on rules, such as the device or network it came from. Set up and test the VPN on the primary WAN first. Then add the secondary WAN as a way to establish or restore the tunnel, not as a direct internet route for protected devices.
A practical setup sequence is:
- Create the protected device group. Assign selected devices to a dedicated VLAN or policy group. Keep devices that need direct internet access in a separate group with clearly defined rules.
- Set up the VPN on the primary WAN. Configure provider-approved authentication and tunnel settings. Confirm that the router shows a working tunnel, routes traffic through it, and uses the intended DNS path.
- Add the secondary WAN as VPN transport. Configure the router to reconnect the tunnel over the backup link if supported. If the public source address changes, the VPN session may need to reconnect.
- Apply firewall rules to both WANs. Permit protected clients to use the VPN interface. Permit only the VPN connection itself to leave through either WAN, with any provider-required endpoint or setup traffic narrowly defined. Block other direct internet traffic from those clients.
- Handle IPv6 and exceptions. Route IPv6 through the tunnel or block it for protected clients. Document any devices or services that are intentionally allowed to bypass the VPN.
A common mistake is to allow all traffic to the backup WAN while the tunnel reconnects. That keeps the internet available, but it defeats the privacy goal. If protected clients must fail closed, they should wait for the VPN to return.
Also check how the router resolves the VPN server name before the tunnel starts. Some setups need a DNS lookup outside the tunnel to find the server. Follow the provider’s supported method and limit this exception to the required endpoint lookup or connection. Do not add a broad DNS bypass for all clients.
Verifying leak resistance during VPN and WAN failures
A leak test checks whether traffic escapes the intended route. Test from a protected device, and test the VPN outage and each WAN failure separately. A successful internet connection after failover is not proof of privacy; it may mean the router has fallen back to direct WAN access.
First, with the VPN active, check the public IPv4 address and DNS resolver shown by a reputable test service or your own endpoint. The public address should match the VPN exit, not either ISP connection. Check IPv6 as well. If you do not route IPv6 through the VPN, confirm that the protected client cannot reach the public internet over IPv6.
Then test the failure paths:
- Disconnect or disable the VPN tunnel. Protected devices should lose external access. Restore the tunnel and confirm service returns.
- Disconnect the primary WAN. Confirm the router brings up the VPN over the backup WAN. If it cannot, protected devices should remain blocked.
- Restore the primary WAN, then test loss of the secondary WAN. Confirm the same rule holds.
- Check DNS while the tunnel is active and during failure. Protected devices should not reach an unintended resolver directly.
- Review router logs and, if available, firewall counters to confirm that blocked direct traffic is being denied.
On a Linux client, ip route get 1.1.1.1 can show the route the system would use for that destination. ip -6 route lists IPv6 routes, and wg show displays WireGuard tunnel status and transfer information. These commands do not replace a leak test: router policy, DNS behavior, and firewall rules still need separate checks. Router command support varies by operating system.
If you use packet capture, tools such as tcpdump can help a qualified administrator inspect traffic on WAN interfaces. Capture only what you need, protect the files, and avoid collecting other people’s traffic without permission.
Worked dual-WAN design scenarios
These are configuration examples, not reports of specific installations. They show how the same fail-closed rule applies to different needs. Your router’s features and VPN provider’s instructions determine which exact settings are available.
| Scenario | VPN and WAN plan | Required protection | Main check |
|---|---|---|---|
| Home office | Work devices use the VPN over the primary WAN; the secondary WAN reconnects the tunnel if needed. | Block direct egress from work devices on both WANs. | Drop the primary WAN and confirm traffic stops until the tunnel returns. |
| Mixed household | A protected VLAN uses the VPN; a separate device group uses ordinary internet access. | Keep the groups’ routes and firewall rules separate. | Test one device in each group during VPN failure. |
| IPv6-enabled network | Protected IPv4 and IPv6 traffic both use the tunnel. | Match routing, DNS, and firewall controls for both address families. | Check public IPv4, public IPv6, and DNS from a protected client. |
For each design, write down the intended exception rules, such as a service that must use a particular WAN. Keep exceptions narrow and test them during tunnel and WAN failures. The key point is simple: backup connectivity should restore the VPN path, not silently create an unprotected path.
FAQ: dual-WAN VPN routing and traffic privacy
These answers address common setup questions about routing, failover, and what a VPN can hide. The exact controls vary by router, but the fail-closed rule should remain the same: protected devices do not use either WAN directly when the tunnel is down.
Does a dual-WAN VPN make my traffic invisible?
No. It encrypts traffic between your router and the VPN server. Your ISP can still see the VPN connection, and the VPN provider and destination services may see other traffic details.
Does a second WAN make the VPN more anonymous?
No. A second WAN adds connectivity redundancy. It does not make you anonymous, and a change in public source address may cause the VPN to reconnect.
What should happen if the VPN disconnects?
Protected devices should lose internet access until the tunnel returns, unless a specific, documented exception applies. Direct fallback to either WAN can expose traffic to the ISP.
Is a router VPN kill switch enough?
Only if it blocks protected traffic on both WANs and covers DNS and IPv6 as required. Test it by disconnecting the VPN and each WAN in turn.
Can I use the same subnet on both WANs and my LAN?
Avoid it. Overlapping address ranges can confuse routing. Use distinct subnets for the LAN, VLANs, VPN, and upstream networks where possible.
Will an IPv4 VPN protect IPv6 traffic?
Not by itself. Route IPv6 through the VPN with matching rules, or block IPv6 for protected devices.
Should I set the tunnel MTU to 1420?
It can be a WireGuard starting point, but it is not universal. Use the router- or provider-tested value and check that sites and apps work normally.
How can I check for a DNS leak?
With the VPN active, use a DNS test from a protected client and check which resolver responds. Also test during tunnel failure and make sure the firewall blocks direct DNS paths.
Can devices use encrypted DNS to bypass router DNS settings?
They may use DNS over TLS or DNS over HTTPS. Use device policies or other suitable controls if you need to restrict those paths; a router DNS setting alone may not be enough.
What should I record after testing?
Record the router and firmware version, WAN and LAN subnets, VPN settings, DNS and IPv6 policy, approved exceptions, and the results of each failure test. Recheck after firmware or network changes.
(This article was written by one of our staff writers, Richard Montclair. Visit our Meet the Team page.)
