Wintun NeighborDiscoverySupported

Jason A. Donenfeld Jason at
Thu Sep 9 17:42:45 UTC 2021

Hi Brad,

That sure is interesting. Indeed UseNeighborUnreachabilityDetection
and SupportsNeighborDiscovery can't be set with SetIpInterfaceEntry. I
haven't (yet?) found any way for the driver itself to indicate that
these should be false, either, via OIDs or similar. This might require
some frustrating reverse engineering. I remember noticing this a long
time ago, but I deemed it "annoying but harmless". However, you now

On Thu, Sep 9, 2021 at 4:33 PM Brad Spencer <bspencer at> wrote:
> but the ARP table fills up with addresses.  For example:
> $  arp -a -N |wc -l
> 387

If that grows indefinitely, that sounds... bad. So this might be worth
looking into again. One thing about your message, though, raised a
question in my mind, but I'm not sure whether its an artifact of your
wording or a real thing you observed:

> We have noticed that Windows seems to try to send ARP requests over
> Wintun interfaces.  In our configurations, these don't go anywhere and
> get no responses,

Indeed the ARP table fills up, as shown above, but I'm wondering how
you're observing ARP requests exactly. ARP is a layer 2 protocol, and
Wintun (and WireGuardNT) are layer 3 devices that should, in theory at
least, not have anything to do with ARP packets. So how exactly were
you "seeing" the ARP requests on the Wintun interface? Did wireshark
show it? Or did you read from the Wintun ring and actually see an ARP
frame? Or something else? Or was this just a manner of speaking and
you didn't actually observe ARP frames themselves?

Another small question:

> We _think_ that the NeighborDiscoverySupported property being Yes means
> that Windows issues ARP requests for addresses on the Wintun interface.

That seems like a good intuition. I'm wondering whether that's
something you're assuming or something you read on a Microsoft
website. I ask because this might provide a good entry point for
whatever reverse engineering I wind up doing to fix this.


More information about the WireGuard mailing list