Opened 6 years ago

Closed 4 years ago

#1054 closed Bug / Defect (fixed)

on-link prefix is *sometimes* not properly installed (with iservice on win7)

Reported by: Gert Döring Owned by: Gert Döring
Priority: minor Milestone: release 2.5
Component: IPv6 Version: OpenVPN git master branch (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:


"sometimes" (alas, I couldn't reproduce it, so I log this as "spurious failure") the pseudo on-link prefixe used for the tap adapter gets installed incorrectly on windows.

When it works, there is one /128 host route "Auf Verbindung" (on link?)
and the "on-link" /64 is routed towards fe80::8, so the TAP driver can play its trick and it works.

When it does not work, I had *two* /64 routes - one was "on link", leading to "netsh interface ipv6 show neigh" telling me that it was trying to do neighbour discovery for $prefix::1 (the server's IPv6 address) and that will always fail. The other /64 route was correct, but not used.

When trying to check how things look with netsh.exe, everything worked, and then with iservice, everything was correctly installed. Funky.

Side note: for some reason we do not log the IPv6 address configured to the interface if iservice is used...

Sun Apr 15 17:09:13 2018 Set TAP-Windows TUN subnet mode network/local/netmask = [SUCCEEDED]
Sun Apr 15 17:09:13 2018 Notified TAP-Windows driver to set a DHCP IP/netmask of on interface {8C1DA1F5-25CB-478D-B839-24FC09F27538} [DHCP-serv:, lease-time: 31536000]
Sun Apr 15 17:09:13 2018 Successful ARP Flush on interface [17] {8C1DA1F5-25CB-478D-B839-24FC09F27538}
Sun Apr 15 17:09:13 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=1
Sun Apr 15 17:09:13 2018 MANAGEMENT: >STATE:1523804953,ASSIGN_IP,,,,,,,2001:608:8003:f::f:208
Sun Apr 15 17:09:13 2018 IPv6 dns servers set using service
Sun Apr 15 17:09:13 2018 add_route_ipv6(2001:608:8003:f::/64 -> 2001:608:8003:f::f:208 metric 0) dev LAN-Verbindung 2
Sun Apr 15 17:09:13 2018 IPv6 route addition via service succeeded

Change History (5)

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

Milestone: release 2.5

There are four different combinations here

  • dev tun and iservice
  • dev tun and netsh
  • dev tap and iservice
  • dev tap and netsh

the {{dev tun}} configs need to send all "on-link" traffic to the gateway, so a "/128" netmask sounds like the correct way to do (doing ND for other hosts in the /64 is not going to work due to the ethernet / tun adaption in tap-windows6)

the {{dev tap}} configs are supposed to send ND for "hosts in the same on-link network", so a correct netmask and on-link route is needed.

I have heard that "some combinations do not work right", but claim that nobody has really tested this - as long as "get to the corp VPN" works, client-to-client is usually not really used.

Needs fixing for 2.5

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

So. Finally running out of excuses, started testing this.

For dev tun, our code consistently does the right thing

  • interface address is $ipv6/128
  • "connected subnet" is routed to fe80::8 (on that interface)
  • "subnets behind server" is routed to fe80::8 (on that interface)
  • so ND only happens for fe80::8, and this is the only way it can work

For dev tap, our code consistently (!) does the wrong thing

  • interface address is $ipv6/128
  • "connected subnet" is routed towards "my own IPv6 address"
  • "subnets behind server" are routed towards server gateway IP (correct)
  • pinging a host *inside* the "connected subnet" leads to
    • ND for $local_ip (3x), which is not answered
    • then, ND for $gateway_ip
    • then, packets are sent to the gateway_ip, who relays to the other client (this can be observed with tcpdump on the server tap - client-to-client is set, so no unicast packets within the same subnet should ever be observed)

this looks like it works, but it should really install a "/64" (or whatever the mask is) as connected subnet, and send ND & packets directly to the other host inside this subnet (via server/client-to-client bridge).

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

commit 81b6a7e75b343e324a44b4476c89c596d7b6c74b (master)
commit 859952560aff6d4442cdfa0c41ced494e9dc397e (release/2.5)
Author: Gert Doering
Date: Tue Sep 15 11:41:01 2020 +0200

Fix netbits setting (in TAP mode) for IPv6 on Windows.

TO BE DONE: test on win7. My homegrown nsis installers are all "Win10" right now.

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

Resolution: fixed
Status: assignedclosed

Tested on Win7 (install the Win10 isntaller and uncheck tap/wintun driver installation).

Only tested "run as admin", but the underlying logic "how should the routes be set up so things work" is the same. Both work.


(I do not intend to backport this to 2.4 right now, as it wasn't really noticed for like 8 years... plus, the windows release cycle is different, so people can just install 2.5.x and do not have to wait for a distribution update)

Note: See TracTickets for help on using tickets.