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 

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

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).

"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

Attachment: signature.asc
Description: PGP signature

Openvpn-devel mailing list

Reply via email to