Windows ipv6 routing netsh.exe fails

[pplars]

Windows ipv6 routing fails if the interface name contains spaces and multiple tap adapters are in use because of netsh.exe weirdness.

The solution is to add "" to the device parameter in route.c :

argv_printf (&argv, "%s%sc interface ipv6 add route %s/%d \"%s\"",

get_win_sys_path(),
NETSH_PATH_SUFFIX,
network,
r6->netbits,
device);

Or to use the interface number for netsh, as done in tun.c since commit ​https://github.com/OpenVPN/openvpn/commit/b52c5256efd5f0120a1322b0b9089c96dbedfe56

[pplars]

Ah sorry, since commit ​https://github.com/OpenVPN/openvpn/commit/efeaf947c9c5c88d77d16ac4917c1350c447c8dc

[Gert Döring]

Quotes in argv_printf() are not needed, as the individual parameters are passed as individual arguments to execve() - so standard shell rules "a space separates arguments" do not apply. All my TAP adapters have spaces in there and it works nicely...

OTOH, Lev was supposed to add a followup patch to the listed commit anyway, to change routing to use interface index as well, to be fully consistent. Dunno why this did not happen yet, will go out and chase him :-)

[pplars]

Hi,
after reviewing this today I partially have to agree with you.
Spaces work if you use ipv4, or ipv6 with only one interface.
However setting up a second tunnel fails if the interface contains spaces.
And works if it does not contain spaces.
But adding "" does not help. Using the interface number works. I did verify this by quick-and-dirty patching route.c to use interface numbers.

We are a VPN Provider, and our windows client does cascading. So customers connect to server1 ,
then connect to server2 in another country though server1.
Thats why we have multiple tunnels at once. (Thats not the problem, we do this for years)

Manually running 'netsh.exe interface ipv6 add route 2000::/5 "Lan-Verbindung 5" fe80::8' fails with "element not found", if another tap adapter (Lan-Verbindung 4) is already connected. It works if there is no space in the name, or if i do the same for ipv4, or if I use interface=23.
Note that "element not found" is not the same error that appears if the interface can not be found, eg if I use "Lan-Verbindung dontexist" as the interface name I get something like "wrong syntax, directory name or volume label" (translated from german)
This problem also applies to netsh.exe in the up/down scripts, as the 'dev' env variable only contains the name with spaces, so the ipv6 rules their dont work for the second interface. As this seems to be a problem with netsh and that most likely will not be fixed, openvpn should also pass the interface number to scripts on Windows.

I made some logs for you, for servers with and without v6, single or cascaded: ​http://pastebin.com/0cK19qeR

Openvpn is called using with

--tun-ipv6 --script-security 2 --route remote_host --setenv hop_id <1..4> --up updown_v6.bat --down updown_v6.bat --up-restart --route-noexec --dev-node "<interfacename>"

Our updown_v6.bat script can be found here: ​http://pastebin.com/gjwvB4Rm

PS: On Windows 7, did not test other versions yet.

[stipa]

This patch ​https://github.com/OpenVPN/openvpn/commit/ca8cead8fd8c00154f35b90593442e2bfa8f735d makes openvpn use indexes in "add/del route" commands.

This one ​http://article.gmane.org/gmane.network.openvpn.devel/10762 passes adapter index to scripts as a "dev_idx" env variable.

[pplars]

Nice, thx!