Update route.c to add interface name for link-local ipv6 addresses ev…

[kabassanov]

…en if it is not server special route

If a link-local ipv6 gateway is pushed by the server, openvpn client must append the interface name to the address even if this route is not considered as vpn special route.

Thank you for your contribution

You are welcome to open PR, but they are used for discussion only. All
patches must eventually go to the openvpn-devel mailing list for review:

• https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Please send your patch using git-send-email. For example to send your latest commit to the list:

$ git send-email --to=openvpn-devel@lists.sourceforge.net HEAD~1

For details, see these Wiki articles:

• https://community.openvpn.net/openvpn/wiki/DeveloperDocumentation
• https://community.openvpn.net/openvpn/wiki/Contributing

[cron2]

Please show a log file that demonstrates what you are doing, and what this patch is trying to fix (verb 4, including PUSH_REPLY and all attempts to set up routes).

For tun interfaces, a next-hop is never needed (because we install routes to the interface), and for tap interfaces, we do not configure a link-local, so this whole setup is a bit questionable.

[kabassanov]

This log shows the incomplete /sbin/route add command:
openvpn-macos-no-int-suffix.txt

This log shows the right /sbin/route add command:
openvpn-macos-int-suffix.txt

What do you mean by "for tap interfaces, we do not configure a link-local" ? If ipv6 is not disabled on an interface, it gats automatically a link-local address. And in my resquest it is about a gateway/routeur link-local address that is perfectly acceptable as next hop.

[cron2]

I see a big fat warning in the log that says

1767616079.299939 1 WARNING: OpenVPN was configured to add an IPv6 route. However, no IPv6 has been configured for tap0, therefore the route installation may fail or may not work as expected.

so whatever you are doing is outside the scenarios the OpenVPN developers really care about (and test) - which is "you let the server assign IPv6 addresses to the OpenVPN client interface (push ifconfig-ipv6) and use GUAs for routing".

What is your intended deployment scenario, if you have no GUA on the interface, which means "even if the route is there, the OS has no valid source address to use there"?

[kabassanov]

I see a big fat warning in the log that says

1767616079.299939 1 WARNING: OpenVPN was configured to add an IPv6 route. However, no IPv6 has been configured for tap0, therefore the route installation may fail or may not work as expected.

so whatever you are doing is outside the scenarios the OpenVPN developers really care about (and test) - which is "you let the
server assign IPv6 addresses to the OpenVPN client interface (push ifconfig-ipv6) and use GUAs for routing".

I understand, but manual configurations per client on the server side are not really needed (in ipv4 or ipv6). Protocols are able to manage all this automatically. So the warning you are talking about, says that there is no manual configuration, but it is not a
barrier.

What is your intended deployment scenario, if you have no GUA on the interface, which means "even if the route is there, the OS has no valid source address to use there"?

IPv6 has the so called stateless autoconfiguration mechanism. An IPv6 address has 2 parts: the network part and the host part. The link gateway (router) sends Router Advertisements, offering at least the network part of the address to other hosts. This way they create their addresses after concatenation of an unique identifier to this network part. The second thing the Router Advertisement sends is the network gateway (its link-local ipv6 address). It is almost like a simplified ipv4 dhcp mechanism... There are also other possibilities for clients ipv6 addresses with dhcp6, but let's keep it simple for the moment...

ifconfig tap0

tap0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ether 3a:8a:36:82:bf:d8
inet6 fe80::d:2730:63ea:7b7d%tap0 prefixlen 64 secured scopeid 0x13
inet6 2001:660:3302:0825:103e:7f89:371:f72d prefixlen 64 autoconf secured
inet6 2001:660:3302:0825:94b6:973:7371:f5ab prefixlen 64 autoconf temporary
inet 169.254.2.8 netmask 0xffff0000 broadcast 169.254.255.255
nd6 options=201<PERFORMNUD,DAD>
media: autoselect
status: active
open (pid 44517)

Please, ignore ipv4 values there...

[cron2]

I do understand SLAAC. But if you use SLAAC, why are you not using it for learning routes as well?

Mix-and-match ("ip config from SLAAC, routes from openvpn") is what is being problematic here.

[kabassanov]

I do understand SLAAC. But if you use SLAAC, why are you not using it for learning routes as well?

Mix-and-match ("ip config from SLAAC, routes from openvpn") is what is being problematic here.

2000::/4 + 3000::/4 is the way you are always sure that the "default route" passes through the vpn tunnel (some OSs invented the multiple default routes concept :/ and metrics are not always correctly managed). In addition (need to recheck), but if your vpn server has a public ipv6 address and the tunnel is set using it, default gateway from RA could be filtered by openvpn client instance (like dhcp router options in ipv4).