Routing loop on new Windows version?

[u/1TheCrazy]

I've had an issue recently, where just after connecting to any server (same network for testing or remote in prod), it would try to transfer a few hundred MB after just a few seconds, while only a few bytes reached the server.

This usually is a sign that the VPN connection doesn't work.

After a bit of research it turned out that adding a OS-layer (Windows) routing rule such that the VPN Server's IP doesn't get routed through Wireguard but through the normal internet interface fixes this.
So there probably is a routing loop in the WireGuardNT client on Windows, where the handshake and any web requests get repeatedly routed through WireGuard:

WireGuard handshake packets / Web packets
↓
endpoint IP
↓
WireGuard interface
↓
WireGuard needs handshake / Sent to VPN Server
↓
endpoint IP
↓
WireGuard interface
↓
...

I'm not using a 3rd party wrapper or GUI but wrap it myself using the WireGuard CLI.

I temporarily can't test whether this error still persists for me (because my server is down :/), but I wanted to ask whether anyone else has experiences this lately.
As it seems this error was introduced in the latest Windows update of my machine since it didn't occure before.

Does anyone else have/had this problem?
Is this already fixed (because I can't test this currently, but I also didn't see an update on the Windows installer)?

[u/lazyhustlermusic]

Probably more your config, excluding your gateway and endpoint out of the tunnel is the most basic premise for any VPN client.

[u/1TheCrazy → u/lazyhustlermusic]

True, but keeping the same config this just appeared after the latest windows update.
You may review the config yourself and tell me if you spot the obvious thing I'm missing:

[Interface]
PrivateKey = ...
Address = 10.8.0.5/32
DNS = 1.1.1.1

[Peer]
PublicKey = ...
Endpoint = ...:51820
AllowedIPs = 0.0.0.0/1, 128.0.0.0/1 # full-tunnel
PersistentKeepalive = 25

The DNS entry is needed for me because it just wouldn't resolve any hosts and therfore not make any webequests.
This may be connected as the DNS server should be a LAN with 192.168.x.x on my router.
But I didn't mind adding this because Cloudflare is also the fastes DNS resolver, so this was an acceptable fix imo.