Opened 2 years ago

Last modified 4 months ago

#1161 new Feature Wish

--route-ipv6 does not recognize net_gateway or net_gateway-ipv6

Reported by: mike_SF Owned by: Gert Döring
Priority: major Milestone: release 2.6
Component: IPv6 Version: OpenVPN git master branch (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:


On a client with the following entries in the configuration file

route net_gateway
route-ipv6 2001:4860:4860::8888/128 net_gateway

The first one (IPv4) works like a charm, but the second one (IPv6) causes the following log error:

OpenVPNROUTE6: cannot parse gateway spec 'net_gateway'

Following convention and replacing net_gateway with net_gateway-ipv6 yields the following error:

OpenVPNROUTE6: cannot parse gateway spec 'net_gateway-ipv6'

The documented functionality that a route is added with the pre-existing IP default gateway as its gateway (with the effect of routing this traffic outside of the tunnel) only works for IPv4 but not for IPv6.

Version information:

OpenVPN 2.4.7 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Feb 21 2019
Windows version 6.2 (Windows 8 or greater) 64bit
library versions: OpenSSL 1.1.0j  20 Nov 2018, LZO 2.10

Change History (8)

comment:1 Changed 2 years ago by Gert Döring

Type: Bug / DefectFeature Wish

This should not be "documented functionality" for IPv6, as it has never been implemented - mostly due to "nobody could explain why this is a desired feature".

So, could you explain your use case a bit more?

With the mechanisms to detect the net_gateway that were added to 2.4, this would not be very complicated to implement (I think), but it's still "code that someone has to do, test, etc." - and on IPv6, with SLAAC, "what is the current net_gateway" can be a bit of a moving target so it might not always work perfectly.

comment:2 Changed 2 years ago by tincantech


comment:3 Changed 19 months ago by mike_SF

The use case is *identical* for IPv6 than it is for IPv4 -- changing protocol does not change anything.

In general this directive is used to have a selected number of IP addresses (both IPv4 and IPv6) that are not routed through the VPN but whose traffic goes out the network interface.

This is to improve speed to endpoints that we know don't need encryption and to reduce overall VPN traffic and infrastructure costs.

comment:4 Changed 15 months ago by mike_SF

Here's a new issue I just encountered.

We register devices that roam around via DDNS with a wget https:// call to an outside provider. We obviously want the device's public IP address to be the one registered, not the address of the VPN's egress, so we have the following directive for IPv4:

route <DDNS_provider_IP> net_gateway

When registering with DDNS server, due to the lack of the equivalent IPv6 directive, we're seeing the VPN server's address being registered (yes, we have to NAT IPv6 for various reasons, primarily privacy and SLAAC).

Last edited 15 months ago by mike_SF (previous) (diff)

comment:5 Changed 14 months ago by tincantech

Probably duplicate of:

comment:6 Changed 13 months ago by Adambean

The valid use case is when the VPN server is part of an internal network of which you want to route through the tunnel itself. For example:

VPN client network:
VPN server network address:
VPN server public address:, making the server part of network

In this case it makes sense to push the following routes:

push "route"
push "route net_gateway"

That allows VPN clients to communicate with through the secure tunnel they've established without accidentally breaking access to the VPN server itself, as VPN clients must always reach this through their default gateway "net_gateway".

As mike_SF pointed out the use case with IPv6 is identical. Let's look at an example for IPv6:

VPN client network: 2a02:1234:5678:128::/64
VPN server network address: 2a02:1234:5678:128:fff:ffff:ffff:ffff
VPN server public address: 2a02:1234:5678:1:fff:ffff:ffff:ffff

As with the IPv4 case it makes sense to push the following routes:

push "route-ipv6 2a02:1234:5678:1::/64 2a02:1234:5678:128:ffff:ffff:ffff:ffff"
push "route-ipv6 2a02:1234:5678:1:fff:ffff:ffff:ffff net_gateway"

Again, for the same reason that VPN clients could then communicate with 2a02:1234:5678:1::/64 (with the exception of the VPN server itself) through their secure tunnel.

All of this makes sense when VPN is being used to dial into a remote site to reach its LAN (rather than share their Internet connection) when there is a separate subnet/VLAN for VPN clients and the site's internal infrastructure. A prime use case being secure teleworking.

comment:7 Changed 6 months ago by Gert Döring

Milestone: release 2.4.8release 2.6
Version: OpenVPN 2.4.7 (Community Ed)OpenVPN git master branch (Community Ed)

OK, I'm convinced.

Someone needs to implement this, and it won't make 2.5 -> setting milestone 2.6

comment:8 Changed 4 months ago by chris21k

Similarly --route-ipv6 does not recognize vpn_gateway, which would be nice to have.

A valid use case would be to rute all traffic to the subnet the remote is in. Here is such a config for ipv4, which also would be desireable for ipv6.
route vpn_gateway
route remote_host net_gateway

Another use case is to route traffic from a roud warrior to the ula subnet in which the openvpn server is in (here my remote is via ipv4).
route-ipv6 fd23:1234:145:daf3::/64 vpn_gateway

Thanks, Chris

Note: See TracTickets for help on using tickets.