Opened 8 years ago

Last modified 12 months ago

#354 assigned Feature Wish

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:


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 (6)

comment:1 Changed 8 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 8 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 5 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 5 years ago by Gert Döring

still on the TODO list

comment:5 Changed 3 years ago by Antonio

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

feel free to test and report back!

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

Note: See TracTickets for help on using tickets.