Development discussion of WireGuard
 help / color / mirror / Atom feed
From: Felix Geschwindner <felix.geschwindner@icloud.com>
To: wireguard@lists.zx2c4.com
Subject: WireGuard Windows client handshake packets appear to be blackholed
Date: Thu, 12 May 2022 22:10:57 -0700	[thread overview]
Message-ID: <7C8C19EF-9076-4A65-9656-EEC28E688B4B@icloud.com> (raw)

Hey folks,

I sent a similar mail a week ago and it said it’s waiting for approval but haven’t gotten anything else back so I thought, try again since there were other mails on the list that came through in the meantime.

I’ve been using WireGuard on my macOS, Linux & Windows machines for a while now and recently the Windows machines started to block WireGuard in a strange way.
I’m using Windows 10 & 11 with the latest updates. WireGuard client version is v0.5.3.

The config looks like this:

[Interface]
PrivateKey = <client_private_key>
Address = 10.0.0.10/32
DNS = 192.168.0.1

[Peer]
PublicKey = <server_public_key>
AllowedIPs = 192.168.0.0/24
Endpoint = vpn.example.com:51820

When I activate the WireGuard VPN it reports that the connection is active and ready to go. I even see the new adapter created in the Windows network settings but when I try to ping resources behind the VPN, I get a “General Failure” message from the command line.
Pinging the local client VPN adapter IP works.

First I tried a couple simple things that may help the WireGuard client to succeed:

	• Reboot
	• Run as administrator
	• Re-install client
	• Re-generate keys & config
	• Try same config on a Mac to rule out mismatches (this works)
	• Run WireGuard in Windows 7 compatibility mode
	• Configure the TCP/IP stack in the registry to favor IPv4 over IPv6
	• Disable IPv6 entirely
	• Add explicit firewall rule to allow WireGuard ports
	• Disable firewall entirely
	• Try full-tunnel via 0.0.0.0/0 in "AllowedIPs"

None of the above points produced any change whatsoever.

Finally I took to WireShark to see if it can help me identify where the packets get stuck and surprisingly WireShark doesn’t show ANY packets destined for the 51820 UDP port on ANY interface. Which is the point at which I ran out of ideas.
I tried this on 2 different Windows machines and both exhibit the same behavior so it doesn’t look like it is something that is special to a machine. I have not yet gotten to test a complete fresh install of windows as that is a bigger undertaking.

Thanks,
Felix

                 reply	other threads:[~2022-05-13 23:39 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=7C8C19EF-9076-4A65-9656-EEC28E688B4B@icloud.com \
    --to=felix.geschwindner@icloud.com \
    --cc=wireguard@lists.zx2c4.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).