IPv6 6in4 tunnel connectivity breaks when OpenVPN client active

My ISP in the UK doesn't have native IPv6 connectivity so I use a 6in4 tunnel from Hurricane Electric. I've recently come from DD-WRT where I had various setups and configurations. I'm slowly learning applying the same with OpenWRT but hitting a few road blocks. I have configured my 6in4 tunnel on OpenWRT and it's working fine.

The main issue I've found is when in conjunction with OpenVPN configuration it breaks my 6in4 tunnel connectivity. My VPN provider is Private Internet Access, I loosely followed the steps below, but ended up using the advanced configuration option and editing /etc/config/openvpn to get the right config.


When this OpenVPN connection is active, the VPN works, but it breaks my IPv6. Private Internet Access doesn't currently handle IPv6 traffic itself only IPv4.

Under DD-WRT I was able to have traffic over IPv4 going through the VPN and IPv6 going over Hurricane Electric without an issues, however it seems I need additional configuration to allow this to happen, possibly firewall or routing related?

Any ideas what areas I should be looking at to maintain connectivity to my IPv6 tunnel with the VPN active?

Router: Linksys WRT3200ACM 18.06

You need to add a static route for the HE endpoint to go through the ISP, not the VPN.


Thanks @trendy. That's possibly what's missing and perhaps DD-WRT adds this by default. I'll try it out!

@trendy Would I need to add a static IPv4 route to the tunnel endpoint? In my case it's Can this be done through LuCI at /cgi-bin/luci/admin/network/routes?

Yes exactly.
Make a static route in IPv4 for mask 32, leave gateway blank, and select the interface of the ISP.

1 Like

Thanks. I added the static route as below, but it doesn't appear to be the issue or it's something else. As checking test-ipv6.com shows no IPv6 address. When I disable the VPN, it shows my Hurricane Electric IPv6 address.

The OpenVPN setup seems a little different to DD-WRT. The VPN appears to include the router itself, looking at traceroute, I can see the traffic going through the VPN when SSH into the router. Under DD-WRT the router itself did not have it's traffic routed through the VPN but other clients connected did. Is this the normal behaviour with OpenWRT?

I'm obviously missing some configuration somewhere, but I don't really know where to start.

Establish the VPN connection and check:

traceroute ipv4.he.gateway

Run: ip tun

root@linksys-wrt3200acm:~# ip tun
6in4-henet: ipv6/ip remote local xx.xx.xx.xx ttl 64 6rd-prefix 2002::/16
sit0: ipv6/ip remote any local any ttl 64 nopmtudisc 6rd-prefix 2002::/16

The xx.xx.xx.xx is my WAN IPv4.

With the static route added and the VPN up please post the following.

uci show network ; \
uci show firewall; uci show dhcp; \
ip -4 addr ; ip -4 ro ; ip -4 ru; \
ip -6 addr ; ip -6 ro ; ip -6 ru; \
iptables-save; ip6tables-save; \
head -n -0 /etc/firewall.user
1 Like

FYI, the gateway is specified in my route for the HE tunnel, as it's a Layer 2 Interface.

According to my testing, it is required to specify explicitly.

. /lib/functions/network.sh
network_find_wan NET_IF
network_get_gateway NET_GW "${NET_IF}"
uci -q delete network.@route[-1]
uci -q delete network.hegw
uci set network.hegw="route"
uci set network.hegw.interface="${NET_IF}"
uci set network.hegw.target="$(uci get network.henet.peeraddr)"
uci set network.hegw.gateway="${NET_GW}"
uci commit network
/etc/init.d/network restart
sleep 10
/etc/init.d/openvpn restart

Are you initialising your henet interface through scripts? I just followed the general OpenWRT example guidance from HE.net and swapped my /64 prefix for the /48, so I could create subnets for other interfaces.

1 Like

I don't actually use IPv6 tunnel broker, because I provide IPv6 via VPN from my VPS which has native IPv6 and my router has no public IPv4 and no IPv6.
I usually use scripts to make the solution reproducible, but it doesn't really matter.
On the other hand, if you have dynamic IPv4 gateway, you probably need to utilize hotplug to make the route work properly.

You can use both, space separated.

I figured it wouldn't given it works fine without OpenVPN active. I think there's further configuration required outside of my IPv6 problem that I'm not used to here. The OpenVPN behaviour is different on OpenWRT. Under DD-WRT, the router itself does not have it's traffic routed through the VPN. Even when OpenVPN is active traceroute would use the WAN connection no matter what. It was clients connected via policy based routing that then had their traffic router through the VPN.

It seems the router itself goes through VPN also here. Under DD-WRT this would cause all kinds of hell. This seems to be where the problem is here, because it seems the IPv6 tunnel traffic is possibly being routed through the VPN which isn't the intended goal.

Furthermore, I'd imagine the fact the router itself is going through OpenVPN, this will cause problems for the HE tunnel side to be able to ping and establish a connection with the WAN side when OpenVPN is active. I've somewhat confirmed this could be the case. I also have a broadband monitor setup through thinkbroadband.com, when the VPN is active, it cannot ping the WAN IP, probably because the traffic isn't being routed to the WAN anymore.

Try to specify the ISP gateway explicitly for the route as I mentioned above, then test traceroute again.

1 Like

I did try that. It didn't seem to make a difference after applying and testing a traceroute to the HE IPv4 tunnel endpoint. Just went through the VPN path.

Check the routing table:

ip r

Here's the info. Applying the static route with a gateway does seem to change things on closer inspection. I get 0/10 on test-ipv6.com but it can see my HE IPv6 with OpenVPN connected, before it couldn't see it at all. via dev tun0
default via dev eth1.2 proto static src 82.15.36.xxx via dev tun0 dev tun0 proto kernel scope link src dev eth1.2 proto kernel scope link src 82.15.36.xxx via dev eth1.2 via dev tun0 dev br-lan proto kernel scope link src dev wlan1-1 proto kernel scope link src via dev eth1.2 proto static

Still some configuration issues though:

root@linksys-wrt3200acm:~# traceroute ipv6.google.com
traceroute: bad address 'ipv6.google.com'
root@linksys-wrt3200acm:~# traceroute6 ipv6.google.com
traceroute6: bad address 'ipv6.google.com'