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
