@Ryan 

 

Please advise 

 

Thanks 

  @Yorchz 

 

While we wait for Ryan there are a few things you can try.

 

Common Issues with TP-Link Deco OpenVPN & FixesDeco routers sometimes have DNS handling quirks with OpenVPN:

 

• Go to your Deco App → More → Advanced → DNS (or WAN settings) and manually set DNS to:
  • Primary: 8.8.8.8
  • Secondary: 8.8.4.4 (Google)
    or
  • 1.1.1.1 / 1.0.0.1 (Cloudflare)
• Make sure IPv6 is disabled on the Deco (or on client devices) — IPv6 is a common source of leaks.

 

To make sure there are no leaks do the following.

 

Step-by-Step DNS Leak Test (Do this from a device connected to the Deco Wi-Fi)

 

1. Connect to the Deco VPN (LAX-C30) and confirm your public IP is still one of the 209.107.192.x addresses.
2. Run the test on these sites (open in a browser):
   • dnsleaktest → Click Standard Test first, then Extended Test.
   • ipleak (also checks WebRTC)
   • browserleaks (very detailed)
3. What to look for in the results:
   • Good (no leak): Only DNS servers belonging to IPVanish (or generic ones like Cloudflare/Quad9 if pushed). The location should show Los Angeles / United States, matching your VPN server. No mention of your real ISP's DNS servers.
   • Bad (leak): You see your real ISP's DNS servers (e.g., Comcast, AT&T, Spectrum, etc.) or your real home location.

  @Yorchz 

 

Additional Troubleshooting Ideas to Try

 

Here are targeted steps beyond what you've already done (re-adding device, reboots, UDP/TCP toggle, IPv6 off, multiple profiles, DNS checks). Focus on routing/NAT quirks common in mesh VPN client setups.

 

1. Check/Force Policy Routing or Device Assignment Again

 

• In the Deco app, remove the NAS from the VPN Client List, reboot the whole mesh, then re-add it.
• Try assigning all devices (or the whole network) temporarily to the VPN to see if the issue is per-device PBR.
• Look for any "VPN Client List" or "Routing Policy" advanced options that might be hidden or glitched.

 

2. MTU/MSS Clamping (Common OpenVPN Routing Killer)

 

• Edit the .ovpn file and add (or increase priority of):

  mssfix 1300
  tun-mtu 1400

 

Or try lower values (e.g., 1200–1350). Re-upload and test.

 

• Fragmentation or oversized packets can break routing even if control/DNS traffic works.

 

3. Explicit Route Push / Redirect-Gateway Tweaks

 

• In the .ovpn, ensure these lines are present (or add them):

  redirect-gateway def1
  route 0.0.0.0 0.0.0.0 vpn_gateway

​​​​​​​

• Some providers push routes poorly on router clients. Test with pull-filter ignore "route" + manual routes above.
• Alternative: Add route-nopull and manually specify routes if you only want specific traffic.

 

4. DNS and Resolver Isolation

 

• You've set Google DNS on WAN—also try forcing it inside the .ovpn with:

  dhcp-option DNS 8.8.8.8
  dhcp-option DNS 8.8.4.4

 

• On the NAS itself, hard-set DNS to the VPN provider's or public ones and disable any local DNS cache/resolver (e.g., systemd-resolved, dnsmasq).
• Test DNS leaks thoroughly from the NAS (not just IP check).

 

5. Firmware and Rollback Options

 

• If possible, temporarily downgrade to an earlier version (or test with a different Deco model if you have spares).
• Factory reset the main Deco after firmware changes before re-importing the .ovpn.

 

6. Test Routing Table on the NAS

 

• SSH/console into the NAS while connected and run:

  ip route show
  ip rule show
  traceroute 8.8.8.8
  tcpdump -i any host 8.8.8.8 -n

​​​​​​​

• Look for missing default route via the tunnel interface (tun0 or similar), conflicting routes, or traffic going out the wrong interface. Compare to when it worked on the XE75 Pro.

 

7. NAT/Masquerade and Firewall Rules

 

• The Deco may not be properly masquerading traffic from LAN devices out the VPN tunnel.
• Test by putting a simple device (e.g., a laptop) directly in the VPN Client List and running the same curl + speed test/browser.
• If the NAS has its own firewall/NAT, temporarily disable it.

 

8. WireGuard Alternative (Since You Mentioned It)

 

• The IP-off-by-one observation with WireGuard suggests a possible backend bug in how the Deco handles VPN interface IPs or routing.
• If your provider supports WireGuard, try a fresh config and verify AllowedIPs = 0.0.0.0/0 (or specific routes).
• Test with the official WireGuard app on a client device for comparison.

 

9. Other Isolation Tests

​​​​​​​

• Bypass the mesh temporarily: Connect the NAS directly to a PC running OpenVPN (same config) and confirm full functionality.
• Disable any QoS, Parental Controls, or "Optimization" features in the Deco app.
• Test with a different VPN provider/profile to rule out provider-specific push issues.
• Check Deco system logs (if accessible via app or telnet/SSH if enabled) for OpenVPN or routing errors around connection time.
• Try enabling the VPN Client on a satellite unit vs. main Deco (if topology allows).

 

10. Advanced Workarounds

 

• Run OpenVPN directly on the NAS (bypassing Deco VPN Client) and set it as the default gateway for traffic.
• Use a small VM/container or cheap router (e.g., GL.iNet) behind the Deco as the VPN endpoint.
• Packet capture on the Deco (if possible) or on the NAS to see where outbound packets are going.

 

Next Steps Recommendation: Start with MTU tweaks + explicit routes in the .ovpn, then deep-dive the routing table on the NAS. Document exact symptoms (e.g., ping/traceroute behavior, any errors) and reply in the forum thread with logs—TP-Link support often escalates when they see regression details vs. older models.