Opened 12 months ago

Last modified 9 days 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.4.8
Component: IPv6 Version: OpenVPN 2.4.7 (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 (6)

comment:1 Changed 12 months 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 12 months ago by tincantech

cc

comment:3 Changed 6 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 2 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 2 months ago by mike_SF (previous) (diff)

comment:5 Changed 6 weeks ago by tincantech

Probably duplicate of:
#1247
#1084

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

Note: See TracTickets for help on using tickets.