Surfshark WireGuard on OpenWrt with IPv6: Common Problems and Fixes

by

Running Surfshark WireGuard on OpenWrt is usually straightforward for IPv4 traffic, but IPv6 can expose weak spots in routing, firewall zones, DNS handling, and policy-based routing. The most common symptom is simple: the tunnel appears connected, yet IPv6 either leaks outside the VPN, stops working entirely, or breaks selected services. The fixes are usually not complicated, but they require a clear separation between WireGuard tunnel configuration, OpenWrt firewall behavior, and IPv6 routing rules.

TLDR: If Surfshark WireGuard works on OpenWrt but IPv6 does not, first confirm whether your Surfshark configuration actually provides IPv6 support for the endpoint you are using. Then check that OpenWrt is not advertising your ISP IPv6 prefix while routing IPv4 through the VPN. Most problems are fixed by correcting the firewall zone, disabling unwanted IPv6 delegation, setting DNS deliberately, and preventing IPv6 leaks with clear routing rules.

Why IPv6 Is Different from IPv4 on OpenWrt

IPv4 VPN routing is generally simple: OpenWrt sends client traffic through the WireGuard interface, NAT is applied, and the public IP changes. IPv6 is different because it does not normally rely on NAT. Instead, devices receive globally routable IPv6 addresses through prefix delegation, router advertisements, and DHCPv6. If OpenWrt continues to hand out your ISP’s IPv6 prefix while IPv4 is routed through Surfshark, clients may bypass the VPN for IPv6 traffic.

This is why a router can appear protected when tested only with IPv4, while IPv6 leak tests show the real ISP address. For privacy-focused VPN use, this is a serious configuration issue, not a cosmetic warning.

Problem 1: The WireGuard Tunnel Connects, but IPv6 Does Not Work

The first point to verify is whether the Surfshark WireGuard configuration includes usable IPv6 details. Some VPN configurations are IPv4-only, while others may include both IPv4 and IPv6 addresses in the Address field. A typical WireGuard interface may include one or two addresses, for example an IPv4 tunnel address and possibly an IPv6 tunnel address.

Fix: Inspect the WireGuard peer and interface settings in OpenWrt:

  • Go to Network > Interfaces and open the WireGuard interface.
  • Check whether the interface has an IPv6 address assigned.
  • Confirm that AllowedIPs includes IPv6 routing if IPv6 through the VPN is intended, commonly ::/0.
  • Restart the interface and review logs with logread or the OpenWrt web interface.

If your provider configuration does not include IPv6 support, forcing ::/0 will not magically create working IPv6. In that case, the safer approach is to block or disable LAN IPv6 to avoid leaks.

Problem 2: IPv6 Leaks Through the ISP

This is the most common and most important issue. Your IPv4 traffic may travel through Surfshark, while IPv6 traffic still goes directly through your ISP WAN interface. This happens when the WAN6 interface remains active and OpenWrt continues to distribute the ISP-provided IPv6 prefix to LAN clients.

Fix option A: disable ISP IPv6 on the LAN. If you do not need IPv6, this is the simplest and safest method. In OpenWrt, review:

  • Network > Interfaces > LAN > DHCP Server > IPv6 Settings
  • Set Router Advertisement-Service to disabled.
  • Set DHCPv6-Service to disabled.
  • Set NDP-Proxy to disabled unless specifically needed.

You may also disable or remove the wan6 interface if it is not required. After applying changes, reconnect client devices or restart their network interfaces so old IPv6 addresses are not retained.

Fix option B: route IPv6 through WireGuard. If Surfshark provides IPv6 on WireGuard, ensure the VPN interface is the default route for IPv6 and that the firewall permits forwarding from LAN to the VPN zone. This is cleaner than allowing WAN6 to coexist without strict policy rules.

Problem 3: Firewall Zone Is Missing or Too Permissive

WireGuard interfaces on OpenWrt should normally be placed in their own firewall zone, often named vpn or wg. If the interface is not assigned to a zone, forwarding may fail. If zones are too permissive, leaks may occur during tunnel failure.

Recommended firewall approach:

  • Create a dedicated firewall zone for the WireGuard interface.
  • Allow forwarding from lan to the WireGuard zone.
  • Do not allow LAN forwarding to WAN if you want a strict VPN-only router.
  • Enable masquerading for the VPN zone if required for IPv4.
  • Use reject rules to block traffic when the tunnel is down.

For IPv6, masquerading is not always appropriate or necessary. The important point is that clients must not have a working route through WAN6 if the policy is “VPN only.” A strict firewall is the best protection against accidental fallback.

Problem 4: DNS Still Uses the ISP

Even when traffic is routed correctly, DNS can still reveal information if OpenWrt or client devices query ISP resolvers. IPv6 makes this more visible because clients may receive DNS servers through router advertisements or DHCPv6.

Fix: Configure DNS intentionally. In OpenWrt, check the WAN, WAN6, LAN, and WireGuard interface settings. Avoid automatically using DNS servers advertised by the ISP if your goal is VPN privacy. You can set DNS servers in Network > Interfaces or configure dnsmasq to push preferred resolvers to clients.

Also check client devices. Some operating systems use private DNS, encrypted DNS, or previously learned IPv6 DNS servers. After changing router settings, flush DNS caches or reconnect devices.

Problem 5: Policy-Based Routing Breaks IPv6

Many OpenWrt users install policy-based routing packages to send only selected devices or destinations through the VPN. This is useful, but IPv6 adds complexity. A policy may match IPv4 subnets only, while IPv6 traffic continues through the normal WAN6 route. In other cases, IPv6 rules exist but point to an interface that has no valid IPv6 route.

Fix: Review whether your policies include both address families. If a device should use the VPN, confirm that both its IPv4 and IPv6 traffic are covered. If you cannot route IPv6 reliably through Surfshark, block IPv6 for that device or disable IPv6 advertisement on the LAN. Avoid assuming that an IPv4 policy automatically protects IPv6.

Problem 6: MTU and Performance Issues

WireGuard is efficient, but incorrect MTU values can cause slow loading, broken websites, or intermittent IPv6 failures. This is especially noticeable on connections involving PPPoE, mobile broadband, or nested tunnels.

Fix: Start with a conservative WireGuard MTU such as 1420. If problems continue, test slightly lower values such as 1380. Apply one change at a time and test both IPv4 and IPv6 sites. Randomly changing MTU, DNS, and firewall rules together makes diagnosis much harder.

Problem 7: Router Advertisements Continue After Changes

After disabling or changing IPv6 settings, some client devices may still hold old IPv6 addresses until their lifetime expires. This can make it seem as if OpenWrt ignored the new settings.

Fix: Restart the affected clients, toggle Wi-Fi off and on, or renew the network connection. On OpenWrt, restart network services or reboot the router after major IPv6 changes. Then verify again using an IPv6 leak test and by checking the client’s assigned addresses.

A Practical Testing Checklist

After making changes, test in a controlled order. Do not rely on a single website result. Use several checks and compare them.

  1. Confirm the WireGuard interface is up and receiving handshakes.
  2. Check public IPv4 and confirm it shows Surfshark, not your ISP.
  3. Run an IPv6 test and confirm whether IPv6 is unavailable or routed through the VPN.
  4. Check DNS leak results.
  5. Disconnect the VPN temporarily and verify that traffic is blocked if you require a kill switch.
  6. Reconnect the VPN and test multiple clients, not just one computer.

Final Recommendations

For most home users, the safest configuration is simple: route all traffic through Surfshark WireGuard and disable ISP IPv6 on the LAN unless the VPN configuration clearly supports IPv6. This avoids silent leaks and reduces troubleshooting complexity. Users who need full IPv6 should verify Surfshark’s current IPv6 support for their chosen server and configure OpenWrt so IPv6 default routing, DNS, and firewall forwarding all point through the tunnel.

The key principle is consistency. Do not let IPv4 follow one privacy policy while IPv6 follows another. On OpenWrt, Surfshark WireGuard can be stable and private, but only if IPv6 is handled deliberately rather than left to automatic WAN6 behavior.