Windows 10/11 wstunnel&WireGuard An attempt was made to access a socket in a way forbidden by it's access permissions. (os error 10013)

[Jim-Young]

Describe the bug Windows 10/11 wstunnel&WireGuard Cannot connect to tcp endpoint x.x.x.x:443 reason An attempt was made to access a socket in a way forbidden by it's access permissions. (os error 10013)

Exactly same setup on macOS Sonoma working no problem.

To Reproduce

1. Clean installed Windows 10 and 11.
2. Download WireGuard from official site and import tunnel and Activated working OK and showing Latest handshakes
3. Deactivate
4. Download wstunnel on WireGuard Debian kernel 5.10.178-3 and unzip and run as server
5. Download wstunnel from latest release and unzipped to Download folder
6. Run as client(By the way, the port should be 51820 on page: https://github.com/erebe/wstunnel)

wstunnel client -L 'udp://51280:localhost:51280?timeout_sec=0' wss://x.x.x.x:443

7. Activate WireGuard, it won't show Latest handshake

Expected behavior Expect the WireGuard showing Latest handshake

Desktop (please complete the following information):

• OS: [Windows 10] & [Windows 11] both Pro
• Version [23H2 V2] Windows 11
• Version [22H2 V1] Windows 10

Windows Defender real time protection off, Firewall off

Telnet could connect to my.server.ip:443

Tried adding a static route via main gateway for the ip of wstunnel server.

Tried on LAN or hotspot to the mobile phone after changing related IP.

[erebe]

Like that I have no idea, every information I found is talking about the network access control on windows, or the firewall. The code is pretty straightforward, it does dns resolution and try to connect to the remote end. The only thing is that it try to set no_delay on the socket (but the call works).

https://github.com/erebe/wstunnel/blob/main/src/tcp.rs#L75C24-L75C55

I you manage to found out let me know. On my windows familly I dont have any issue :x

[Jim-Young]

Thanks mate.

I also tried on a Windows 7 VM and it did the same. I'm a bit suspecting my WireGuard server setup as it's installed through Firezone in a docker. And this could be the problem.

I'll start a new Debian with just ordinary WireGuard installation to see. I'll keep you updated. Thanks again.

[Jim-Young]

I set up a clean Debian and installed wireguard through apt, and set up server with command line, then downloaded wstunnel on it.

It's the same, but I found the problem.

Whenever on the client conf, if I set the [Peer] AllowedIPs = 0.0.0.0/0, it will work without wstunnel but won't show Latest Handshke.

If I set the [Peer] AllowedIPs = server.wg.ip.address/32, wstunnel will work.

I though about the route loop and added default route to server IP, but it made no difference.

I read about the Cryptokey Routing on the wireguard.com page, still not sure if this should cause any problem or between wstunnel and wireguard.

[erebe]

Will try to take another look at it

[erebe]

I managed to reproduce the issue. It only arises indeed when you set 0.0.0.0/0 as allowed ips. It turns out it is a common issue with with VPN that siphon all traffic.

You need to disable the kill switch in order for it to works with wstunnel. or change the allowedIPS from 0.0.0.0/0 to 0.0.0.0/1 128.0.0.0/1

[Jim-Young]

Thanks mate. I'll try that.

0.0.0.0/0 should be no real difference with 0.0.0.0/1, 128.0.0.0/1

Will report back later.

[Jim-Young]

I can confirm now that it's the kill switch related problem, though wireguard works OK with kill switch when not using wstunnel.

On the macOS, there is no kill switch option.

There are other problems where wstunnel would crash after disconnecting. You will have to stop wstunnel and re-load it to make the wireguard work again, but that's different problem.