Hi, On Wed, Nov 27, 2019 at 01:43:38PM +0000, Laurent Fasnacht wrote: > Apparently, `netsh interface ipv6 set address ...` defaults to using > a subnet of /64, and therefore adds an onlink route of that size. > > When using a tun tunnel, the tap adapter only replies to neighbor > discovery packets for fe80::8. This leads to the unfortunate situation > where all the hosts in the /64 are not reachable. > > This patch fixes that situation by specifying a /128 netmask, as the real > route is added afterwards, via the gateway.
So, coming back to this. I tried to reproduce this in the context of https://community.openvpn.net/openvpn/ticket/1054 and actually couldn't. I tested on Win10, and both on tun and tap mode, the existing code always configured a "/128" on-link (and then added the /64 route to what it thought was the right gateway - fe80::8 for tun, its own address for tap). I will need to touch the code now anyway, as the behaviour for tap is *wrong* (for tap, it really needs to have a /64 on-link, and do ND inside the network) - but if I could reproduce the issue you saw for tun, it would make my life easier :-) Arne: in "dev tun" mode on windows, we can only reach a single gateway IP (fe80::8) which is the "spoof ND replies!" thing in the tun/tap driver - everything else only works if sent via fe80::8 -> strip ethernet header -> send as "tun" packets. So, /128 is correct for tun. gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
