wireguard.lists.zx2c4.com archive mirror
 help / color / mirror / Atom feed
From: Alan Graham <alan@meshify.app>
To: Brad Spencer <bspencer@blackberry.com>
Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>,
	WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: Re: Wintun NeighborDiscoverySupported
Date: Thu, 9 Sep 2021 13:23:00 -0700	[thread overview]
Message-ID: <CAMeHLtxw939uNJcN=UZAR9wM10pB2xYOu2K_X++Z8LsfPCAmNw@mail.gmail.com> (raw)
In-Reply-To: <310f3386-a488-9e28-2f10-3f867ece0f53@blackberry.com>

Hi Brad, Jason,

Adding the 0.0.0.0/0 (or ":::") to the config is what is causing some
growth of the arp table, but it is not growing indefinitely.  After
looking around for SupportsNeighborDiscovery and finding nothing, I
decided to check the repro.  When not routing all traffic through an
interface the arp cache is basically static:

PS C:\>  arp -a -N 100.0.0.2

Interface: 100.0.0.2 --- 0x38
  Internet Address      Physical Address      Type
  100.0.0.4                                   dynamic
  224.0.0.22                                  static
  224.0.0.251                                 static
  224.0.0.252                                 static
  239.255.255.250                             static

When routing all traffic through it grows more or less like an arp cache should:

PS C:\>  arp -a -N 100.0.0.2

Interface: 100.0.0.2 --- 0x38
  Internet Address      Physical Address      Type
  0.0.0.0                                     static
  8.8.4.4                                     dynamic
  8.8.8.8                                     dynamic
  13.64.180.106                               dynamic
  18.211.21.156                               dynamic
  20.98.103.204                               dynamic
  23.6.164.43                                 dynamic
  23.40.197.163                               dynamic
  23.204.103.147                              dynamic
  35.185.199.42                               dynamic
  40.83.247.108                               dynamic
  51.143.14.218                               dynamic
  54.214.97.217                               dynamic
  65.8.17.107                                 dynamic
  67.160.11.228                               dynamic
  69.1.20.242                                 dynamic
  73.118.184.4                                dynamic
  74.125.142.188                              dynamic
  74.125.197.188                              dynamic
  75.75.75.75                                 dynamic
  100.0.0.2                                   dynamic
  100.0.0.4                                   dynamic
  142.250.69.202                              dynamic
  142.250.217.99                              dynamic
  142.251.33.74                               dynamic
  142.251.33.106                              dynamic
  173.194.202.189                             dynamic
  192.168.200.2                               dynamic
  192.228.79.201                              dynamic
  224.0.0.22                                  static
  224.0.0.251                                 static
  224.0.0.252                                 static
  239.255.255.250                             static

So I tend to agree with Jason that this is "harmless" and shouldn't
cause any serious problems.  It would be nice for Microsoft to fix
Set-NetIPInterface, it looks like a bug that SupportsNeighborDiscovery
can't be set.

Best regards,
Alan Graham


On Thu, Sep 9, 2021 at 11:17 AM Brad Spencer <bspencer@blackberry.com> wrote:
>
> On 2021-09-09 2:42 p.m., Jason A. Donenfeld wrote:
> > 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?
> You're right to suspect that I was speaking imprecisely here.  We have
> never seen an ARP request appear on the Wintun interface!  I meant to
> say that we have noticed the ARP table for the Wintun interface
> accumulating entries.
>
> >> 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.
> I pieced this together from a few scraps.
>
> On the MIB_IPINTERFACE_ROW page[1], the docs only tersely say:
>
> "A value that specifies if the IP interface support neighbor discovery."
>
> Microsoft seems to use the same terminology when documenting
> SetIpNetEntry2()[2]:
>
> "The SetIpNetEntry2 function sets the physical address of an existing
> neighbor IP address entry on the local computer."
>
> And then, most importantly, MIB_IPNET_ROW2, the structure used by that
> function says this in its Remarks section[3]:
>
> "For IPv4, this includes addresses determined used the Address
> Resolution Protocol (ARP). For IPv6, this includes addresses determined
> using the Neighbor Discovery (ND) protocol for IPv6 as specified in RFC
> 2461. "
>
> So, it seems that the "NetEntry" APIs are those that deal with ARP (and
> ND) entries, and the term Microsoft uses for that is "neighbor discovery".
>
> I don't know if the SupportsNeighborDiscovery field of MIB_INTERFACE_ROW
> is implied by other properties of the network interface (such as "all
> Ethernet interfaces support ARP") or whether it can be individually set
> at all.
>
> One other detail is that we have the gateway for the tunnel's routes set
> to 0.0.0.0 (or "::").  I presume that also influences how Windows
> decides which addresses might be on-link neighbours.
>
> 1.
> https://docs.microsoft.com/en-us/windows/win32/api/netioapi/ns-netioapi-mib_ipinterface_row
> 2.
> https://docs.microsoft.com/en-us/windows/win32/api/netioapi/nf-netioapi-setipnetentry2
> 3.
> https://docs.microsoft.com/en-us/windows/win32/api/netioapi/ns-netioapi-mib_ipnet_table2
>
> --
> Brad Spencer
>

  reply	other threads:[~2021-09-09 20:48 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-09 14:32 Brad Spencer
2021-09-09 17:42 ` Jason A. Donenfeld
2021-09-09 18:15   ` Brad Spencer
2021-09-09 20:23     ` Alan Graham [this message]
2021-09-10 17:19       ` Brad Spencer
2021-09-10 20:56         ` Alan Graham

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAMeHLtxw939uNJcN=UZAR9wM10pB2xYOu2K_X++Z8LsfPCAmNw@mail.gmail.com' \
    --to=alan@meshify.app \
    --cc=Jason@zx2c4.com \
    --cc=bspencer@blackberry.com \
    --cc=wireguard@lists.zx2c4.com \
    --subject='Re: Wintun NeighborDiscoverySupported' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).