What's new

Turning on VPN disables native ipv6

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

bmb

Regular Contributor
I wasn't sure where to post so hope this is suitable place.

I have an RT-AC87U with latest Merlin beta 380.65 beta1. I get native ipv6 from BT in the UK and all devices I have get full connection to both ipv4 and ipv6 on the sites that are testing ipv6 connectivity. All good and no problem so far.

I occasionally use a VPN service and havea client set up in the router by importing opvn file. The issue is that when VPN is active, and choosing only certain devices routed through the VPN, I loose native ipv6 on those still connected to the WAN. The VPN provider I use offers ipv6 access, is there maybe a conflict?

This was the same on previous firmware that used the older version of OpenVPN. I've only recently enabled native ipv6 so can't go back much further to know if this has been a problem with earlier firmwares.

Is there any further testing I can do, would it help narrow down the problem if I posted the system log entries that relate to openvpn and ipv6?
 
Last edited:
I'll try that suggestion, still looking to find out how to do it.

If ipv6 VPN isn't supported on this router I'll just leave it for now, no doubt one day it will be and I'll look into it again then. If it helps I can see that when VPN is turned on the native ipv6 gateway is lost, so that seems to be the area of conflict.

Its not important, I'll leave it for now.
 
[force VPN Client IPv4]....I'll try that suggestion, still looking to find out how to do it.

https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage

"--remote host [port] [proto]
Remote host name or IP address. On the client, multiple --remote options may be specified for redundancy, each referring to a different OpenVPN server. Specifying multiple --remote options for this purpose is a special case of the more general connection-profile feature. See the <connection> documentation below.

The OpenVPN client will try to connect to a server at host: port in the order specified by the list of --remote options.

proto indicates the protocol to use when connecting with the remote, and may be "tcp" or "udp".

For forcing IPv4 or IPv6 connection suffix tcp or udp with 4/6 like udp4/udp6/tcp4/tcp6.
"

When VPN is turned on the native ipv6 gateway is lost, so that seems to be the area of conflict.

It probably needs more than that, but you could attempt to manually reinstate the native ipv6 gateway in the openvpn-event script? or use def1-IPv6????

NOTE: My ISP provides no IPv6 so unable to test....only reason I had to RTFM OpenVPN 2.4 manual was I because I couldn't get the new client to connect successfully with my existing VPN Client config. :confused:
 
Last edited:
Thanks for helping. I've read through the OpenVPN manual.

I tried adding suffix 'udp4' to remote after the port, and VPN wouldn't start with error:

Code:
Jan 23 10:06:00 openvpn[19789]: Could not determine IPv4/IPv6 protocol
Jan 23 10:06:00 openvpn[19789]: SIGUSR1[soft,init_instance] received, process restarting
Jan 23 10:06:00 openvpn[19789]: Restart pause, 5 second(s)

Even after looking through the Openvpn manual I wouldn't know where to begin adding back the native ipv6 WAN Gateway.

It seems like something to put on hold for a future time when ipv6 and VPN together are better supported, and really isn't a problem I can't live with.
 
I tried adding suffix 'udp4' to remote after the port, and VPN wouldn't start with error:

Probably requires the server to also be on OpenVPN 2.4:oops:

Anyway since I have to avoid IPv6, I now have to use the following Custom directives:
Code:
pull-filter ignore "ifconfig-ipv6"
pull-filter ignore "route-ipv6"

and whilst logically this may have the same meaning as the 'tcp4/udp4' directive, not sure if it would also work for you.
 
That's a good result :)

Using...
Code:
pull-filter ignore "ifconfig-ipv6"
pull-filter ignore "route-ipv6"

I get the native IPV6 gateway back, that's a great achievement, though now any device routed through VPN gets an IPV4 address through VPN and an IPV6 address through WAN. So I tried using just one of the commands at a time to see what occurs, and found that using only...
Code:
pull-filter ignore "route-ipv6"

gives the best result in that native IPV6 is still working, and any device routed through VPN only gets an IPV4 address, so no IPV6 leaking in this instance. That's a really acceptable result now, so thank you for the assistance :)
 
I have to bring this up again. Two years later and this problem seems to still exist.

I loaded the mullvad vpn config file for openvpn, tried it with 384.6 (which is the latest for my router) and johns V38E4, so probably an ASUS Bug.

captureqnj1w.png


It seems we can not have both, IPv6 and VPN-Client. :(

Code:
persist-key
persist-tun
remote-cert-tls server
ping 10
ping-restart 60
sndbuf 524288
rcvbuf 524288
fast-io
tun-ipv6
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA
 
Last edited:
You can have both, but the IPv6 traffic does not go through the VPN.
Hi John, this defeats the purpose, right?

Why we cannot have both? It is probably not the fault of the vpn providers...

At least let the vpn use IPv4 but my other Router-Clients, which don't use the VPN, should use IPv6 also.

I mean, I can live with that, IPv6 is still not relevant, but some day this may change.
 
Last edited:
Hi John, this defeats the purpose, right?
Why we cannot have both? It is probably not the fault of the vpn providers.
Actually, I'm not aware of any major provider that currently offers IPv6 thru the VPN (if there is, someone can jump in). After that, there needs to be an update to the firmware...
 
I just tried mullvad with their own client in a VM (which is not routed through the vpn in the router) and there I got an IPv4 and an IPv6 VPN-address.

captureaqk98.png



(if there is, someone can jump in). After that, there needs to be an update to the firmware...
If you wan to try it yourself, you can use mullvad service for free for 3 hours. You don't have to register, only get an account number with a click of a button and then use their service like a full member for 3 hours.
 
Last edited:
Looks lik mulvad is doing something, but not using native ipv6 when available (their doc indicates they can add ipv6 support when your isp doesn't provide it). Probably setting up there own 6-in-4 or 6rd tunnel. So may not be surprising that it borks any native support.
 
@john9527 Thank you for taking a look at it. I wish that no client-vpn could tinker with my wan-internet. I can't see the direct relation.
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top