Opened 2 years ago

Last modified 5 days ago

#1054 assigned Bug / Defect

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

comment:1 Changed 3 months 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 6 days 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 5 days 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.

Note: See TracTickets for help on using tickets.