Opened 10 years ago

Closed 20 months ago

#354 closed Feature Wish (fixed)

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

Reported by: rajkosto 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: tct


Basic part of server config:

proto udp
dev tun
topology subnet


This makes the subnet where the tunnel virtual ips are

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


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 behind it, 102 has behind it), so we add the following to the main server config (not ccd specific):

push "route"

push "route"

This works correctly, on .101 ONLY the route is added to ip route, and on .102 ONLY the 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"


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.

Change History (10)

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

Owner: set to Gert Döring
Status: newassigned
Type: Bug / DefectFeature Wish

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

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

Milestone: release 2.4

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

comment:3 Changed 7 years ago by stepp

Did this find its way into 2.4?
In the changeset 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.

comment:4 Changed 7 years ago by Gert Döring

still on the TODO list

comment:5 Changed 6 years ago by Antonio Quartulli

A patch fixing this issue has been proposed on the mailing list at

feel free to test and report back!

comment:6 Changed 4 years ago by Gert Döring

Milestone: release 2.4release 2.6
Version: OpenVPN 2.3.2 (Community Ed)OpenVPN git master branch (Community Ed)

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

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

comment:7 Changed 2 years ago by MEitelwein

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

comment:8 Changed 2 years ago by tct

Cc: tct added

comment:9 in reply to:  7 Changed 2 years ago by 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.

comment:10 Changed 20 months ago by Gert Döring

Resolution: fixed
Status: assignedclosed

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

Note: See TracTickets for help on using tickets.