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 mention:
On Thu, Sep 9, 2021 at 4:33 PM Brad Spencer <[email protected]> wrote: > but the ARP table fills up with addresses. For example: > > $ arp -a -N 10.0.0.100 |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. Regards, Jason
