Opened 2 years ago

Last modified 3 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:
Cc:

Description

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

Change History (13)

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

cc

comment:3 Changed 22 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 18 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> 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).

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

comment:5 Changed 18 months ago by tincantech

Probably duplicate of:
#1247
#1084

comment:6 Changed 16 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: 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.

comment:7 Changed 9 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 8 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 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

comment:9 Changed 3 months ago by 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

comment:10 in reply to:  9 ; Changed 3 months ago by tincantech

Replying to fkooman:

This "reverse split tunnel" is something that Microsoft recommends

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

comment:11 in reply to:  10 ; Changed 3 months ago by 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.

comment:12 in reply to:  11 Changed 3 months ago by tincantech

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.

comment:13 Changed 3 months ago by 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.

Note: See TracTickets for help on using tickets.