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

[mike_SF]

On a client with the following entries in the configuration file

route 8.8.8.8 255.255.255.255 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

[Gert Döring]

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.

[tct]

cc

[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.

[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> 255.255.255.255 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).

[tct]

Probably duplicate of:
#1247
#1084

[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: 172.28.128.0/24
VPN server network address: 172.28.128.254
VPN server public address: 1.2.3.94/28, making the server part of network 1.2.3.80-1.2.3.95.

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

push "route 1.2.3.80 255.255.255.240 172.28.128.254"
push "route 1.2.3.94 255.255.255.255 net_gateway"

That allows VPN clients to communicate with 1.2.3.80/28 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.

[Gert Döring]

OK, I'm convinced.

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

[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 245.34.0.0 255.255.0.0 vpn_gateway
route remote_host 255.255.255.255 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

[fkooman]

This "reverse split tunnel" is something that Microsoft recommends for Microsoft/Office? 365. Not that we should listen to them, but without this IPv6 replica of IPv4 functionality this can't be done when using a VPN service that offers both IPv4 and IPv6 connectivity.

​https://docs.microsoft.com/en-us/microsoft-365/enterprise/microsoft-365-vpn-split-tunnel?view=o365-worldwide

[tct]

Replying to fkooman:

This "reverse split tunnel" is something that Microsoft recommends

"reverse split tunnel" - Where did you get that ?

[mike_SF]

Replying to tincantech:

Replying to fkooman:

This "reverse split tunnel" is something that Microsoft recommends

"reverse split tunnel" - Where did you get that ?

I would say it comes from the document he linked to.

And yes, this is yet another use case for the feature parity I highlighted 24 months ago as missing and that hope will be implemented soon.

[tct]

Replying to mike_SF:

Replying to tincantech:

Replying to fkooman:

This "reverse split tunnel" is something that Microsoft recommends

"reverse split tunnel" - Where did you get that ?

I would say it comes from the document he linked to.

He being you, in this case ?

I presume you understand the term "split tunnel" and so I would like you to explain, in your own words, what you think a "reverse split tunnel" is.

[fkooman]

I'm not sure where I picked up the "reverse split tunnel" terminlogy, I read
it somewhere :)

The way I am understanding the term "split tunnel": route no traffic over the
VPN, except for some prefixes, e.g. company internal network.
"Reverse split tunnel" would be the opposite: route all traffic over the VPN,
except for some prefixes, like e.g. Microsoft/Office? 365.

The former is supported with both IPv4/IPv6. The latter only with IPv4, not
IPv6 as the route-ipv6 option does not support the "net_gateway" flag.

[fkooman]

Example where we expect traffic to 8.8.8.8 and 2001:4860:4860::8888 to go over the VPN, and traffic to 8.8.4.4 and 2001:4860:4860::8844/128 to go outside the VPN:

push "redirect-gateway def1 ipv6"
push "route 8.8.8.8 255.255.255.255"
push "route-ipv6 2001:4860:4860::8888/128"
push "route 8.8.4.4 255.255.255.255 net_gateway"
push "route-ipv6 2001:4860:4860::8844/128 net_gateway_ipv6"

The error message in the client log (2.5.4):

2021-10-29 16:45:49 Options error: route-ipv6 parameter gateway 'net_gateway_ipv6' must be a valid address

This parameter "net_gateway_ipv6" is mentioned in the source code, but doesn't seem to work, e.g. ​https://github.com/OpenVPN/openvpn/blob/0df2261da192eac74d1c53e99db0ed3f49278986/src/openvpn/route.c#L805

It seems what is missing is converting this string to the gateway address in init_route_ipv6 (route.c) like is done for init_route. It perhaps needs a get_special_addr function for the IPv6 case as well...

[fkooman]

Created a PR that fixes it (probably not exactly as it should...) on at least Linux: ​https://github.com/OpenVPN/openvpn/pull/160

[Gert Döring]

Did not proceed the way it should have in the 2.6 timeframe (we saw the patch in the PR, but we wanted some changes and nothing ever happened then...) - but we still want this, so bumping the milestone to 2.7