Opened 4 years ago

Last modified 10 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: cron2
Priority: major Milestone: release 2.4
Component: IPv6 Version: OpenVPN 2.3.2 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:
Cc:

Description

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.

Change History (4)

comment:1 Changed 4 years ago by cron2

  • Owner set to cron2
  • Status changed from new to assigned
  • Type changed from Bug / Defect to Feature 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 4 years ago by cron2

  • Milestone set to 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 10 months ago by 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.

comment:4 Changed 10 months ago by cron2

still on the TODO list

Note: See TracTickets for help on using tickets.