Hi, On Fri, Jan 06, 2023 at 04:46:17PM -0500, Selva Nair wrote: > > On Fri, Jan 06, 2023 at 03:44:24PM +0200, Lev Stipakov wrote: > > > Compiled and slightly tested - pinged server's tunnel IPv6 address. > > > > Do we call "route" for connect networks on Windows? We do on some > > of the platforms, but for those where we do not, this is not a good > > test for "route add" functionality - as tunnel IP + subnet gets > > setup via the "ifconfig-ipv6" part (implicit route for connected net). > > Yes we do call add_route_connected_v6_net() on windows, so add_route_ipv6() > should always get exercised.
Thanks for reminding me :-) > Though I vaguely understand why we set the address with /128 and then set > the route for the vpn subnet with fe80::8 as the gateway for tap-windows6, > wonder why we do this for dco as well. Let me recap why we do this for tap-windows - for windows, this is always an Ethernet adapter, so it wants to always do neighbour discovery (ND), IPv6's equivalent of ARP for all "on this interface" addresses. For "--dev tun" setups, OpenVPN does not want to deal with "Ethernet things", so the TAP driver replies to ARP requests for "special addresses" - for net30, OpenVPN ioctl()'s the "peer" address (which is also the gateway address) into the TAP driver, and only this address is replied to - admittedly, I do not know how "topology subnet" works wrt virtual ARP, need to read up on this again. For IPv6, I decided that having to deal with ND is easier if I could just look at a magic number, namely fe80::8, in the tap driver code - so, we use /128 for the ifconfig bit ("no network here, everything is behind the gateway") and point all routing to "on this interface, fe80::8" - so for whatever IPv6 destination, windows will only do ND for fe80::8, and the TAP driver will reply to it, without any further help (ioctl()) from OpenVPN. This said, I have no idea why we do it that way for wintun and DCO - most likely because it avoids having to add even more windows-driver- specific special case handling in places where we are nicely generic today. We are not really losing anything this way, though - even though we pretend "the interface is a multiaccess interface", it is really only point-to-point from the OS view, including win-dco. So whatever helps to convince windows "send the packet down this pipe" with the least amount of code and debugging is good :-) On a "real" multiaccess network, different neighbours would have different MAC addresses, and more ND activity would happen - but "--dev tun" mode never is (--dev tap on a --server would be). 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