push "route-ipv6 ..." doesn't behave properly like push "route ..." on the client which owns that subnet

[rajkosto]

Basic part of server config:

proto udp
dev tun
server 172.16.0.0 255.255.255.0
topology subnet

route-gateway 172.16.0.1
client-to-client

This makes 172.16.0.1/24 the subnet where the tunnel virtual ips are

Now let's say we have 2 clients 172.16.2.101 and 172.16.2.102 so we have the following ccd configs:

ifconfig-push 172.16.0.101 255.255.255.0
iroute 172.16.1.0 255.255.255.0

ifconfig-push 172.16.0.102 255.255.255.0
iroute 172.16.2.0 255.255.255.0

now everyone can talk to each other using their tunnel ips (1,101,102)

Let's say both clients are actually edge routers, each with a /24 behind it (101 has 172.16.1.0/24 behind it, 102 has 172.16.2.0/24 behind it), so we add the following to the main server config (not ccd specific):

#behind 172.16.0.101
route 172.16.1.0 255.255.255.0
push "route 172.16.1.0 255.255.255.0"

#behind 172.16.0.102
route 172.16.2.0 255.255.255.0
push "route 172.16.2.0 255.255.255.0"

This works correctly, on .101 ONLY the 172.16.2.0/24 route is added to ip route, and on .102 ONLY the 172.16.1.0/24 route is added to ip route, so now the subnets behind the edge routers are accessible properly from all sides.

So now let's add equivalent IPv6 addresses to all of this
Main server config:

server-ipv6 2001:470:d76b:b055::/64

#behind 2001:470:d76b:b055::1001:1
route-ipv6 2001:470:d76b:bee2::/64
push "route-ipv6 2001:470:d76b:bee2::/64"

#behind 2001:470:d76b:b055::1002:1
route-ipv6 2001:470:d76b:da7a::/64
push "route-ipv6 2001:470:d76b:da7a::/64"

ccds:

ifconfig-ipv6-push 2001:470:d76b:b055::1001:1
iroute-ipv6 2001:470:d76b:bee2::/64

ifconfig-ipv6-push 2001:470:d76b:b055::1002:1
iroute-ipv6 2001:470:d76b:da7a::/64

Now, this worked correctly under 2.1.x with the IPv6 payload patch (same behaviour as ipv4 versions), however, since upgrading the client to 2.3.x push "route-ipv6 ..." adds BOTH routes to ip -6 route show, which means they have one with eth0 and one with tun0, and the tun0 one is preferred, so it can no longer talk to the ipv6 clients wired to that router. To repeat, earlier behaviour was correct and it only added the route that was behind the OTHER router, not the one the edge router was directly connected to. This behaviour is still correct for ipv4, but not for ipv6 since 2.3.x.

Of course, this can be worked around by only pushing routes inside the ccd files (all of them except the one that edge router actually owns) but this involves more copy-paste work than just keeping them in the main server config file, AND it was a feature that worked before with the IPv6 patch, and still works with pushing IPv4 routes properly.

[Gert Döring]

I'm fairly sure 2.1 with the IPv6 payload patch did exactly the same thing as 2.3.2 does - as what was merged into master before 2.3 was exactly this very code.

Arguably this is less than ideal for you, and should be fixed. It's a matter of time (there is other IPv6 stuff in 2.3 that could use some improvement for 2.4), and since there are workarounds possible, I reclassify this as "feature wish".

As one possible workaround, pushing a supernet that contains all /64s in use but that will not conflict with either host should work:

push "route-ipv6 2001:470:d76b::/48"

... or just push the routes as two /63 (again, more specific /64 on eth0 will win over /63 on tun0).

[Gert Döring]

Milestone to 2.4 - the necessary changes are bigger than what we want to do in 2.3, and a workaround exists.

[stepp]

Did this find its way into 2.4?
In the changeset ​https://community.openvpn.net/openvpn/wiki/ChangesInOpenvpn24 I find serveral related lines

Improve documentation and help text for --route-ipv6.
...
refactor struct route_ipv6, bring in line with struct route_ipv4 again
refactor struct route_ipv6_list, bring in line with struct route_list again

but no direct reference

The text in the ​2.4 manual is still the same as in ​2.3, it says the -ipv6 variants should behave the same way as the original iroute/route directives do:

--iroute-ipv6 ipv6addr/bits
    for ccd/ per-client static IPv6 route configuration, see --iroute for more details how to setup and use this, and how --iroute and --route interact.

[Gert Döring]

still on the TODO list

[Antonio Quartulli]

A patch fixing this issue has been proposed on the mailing list at ​https://sourceforge.net/p/openvpn/mailman/openvpn-devel/thread/20180523192802.31611-1-a%40unstable.cc/#msg36324525

feel free to test and report back!

[Gert Döring]

Patchwork says that someone *cough* was lazy in reviewing and merging.

Bump to 2.6 - rebasing will be needed, Antonio is busy.

​https://patchwork.openvpn.net/patch/332/

[MEitelwein]

Any chance that this will be fixed? IPv6 is getting quite common and multi-client configs are getting error prone without this mechanism.

[Antonio Quartulli]

Replying to MEitelwein:

Any chance that this will be fixed? IPv6 is getting quite common and multi-client configs are getting error prone without this mechanism.

Thanks for the ping! The patch is still the same as comment-5 (Feel free to give it a spin if you'd like).
Hopefully it'll get merged in 2.6.

[Gert Döring]

After too long, this is now merged in git master, which will become 2.6.0 fairly soon.

commit 437812d4eac9ac892fbfd2fd97c50384b2d2ec07 (HEAD -> master)
Author: Antonio Quartulli <a@…>
Date: Tue Jun 28 10:20:24 2022 +0200

do not push route-ipv6 entries that are also in the iroute-ipv6 list

it has not been backported to 2.5 as we see this more as a "new feature" than a "bugfix", and 2.5 will only receive bugfixes at this time.

Thanks, @ordex