Multiple handshake timouts when using WireGuard protocols

[udp_monkey33 0]

Hello all,

I'm still fairly new to all this but I've learned that I can get better speeds with WireGuard protocols than with OpenVPN but with WireGuard I keep getting multiple handshake timeouts back to back. I've already set my my MTU to 1280, use only IPv4 in Eddie and even changed my WiFi channel to a less used one but despite all that it keeps getting timeout and then when it reconnects I have very low speeds. I don't know what to do and  would aprreciate any help.

Eddie_20241104_134626.txt

[OpenSourcerer 1435]

Looks like a replay, or maybe erratic QoS attempts by the access point. Is it far away from your computer?

[udp_monkey33 0]

@OpenSourcerer, I'm sorry but I don't really know what you mean by that. I don't really know much about all this stuff.

Quote

Is it far away from your computer?

My router? It's basically straight under my room.
The server that I get connected to from Eddie? Netherlands but I am located in Germany

[OpenSourcerer 1435]

Basically it looks like this to me: It occurs that some packets are sent "in advance" while a previous flow of packets is still ongoing. It's like you are being sent a row of numbers – 1, 2, 3, 4, 5, 6, 7, 8 – but instead you somehow get the 8 first, then 1-7 after it. This is not liked by either OpenVPN or Wireguard: Both protocols warn you that this is happening and drop all packets that are unorderly received (AEAD decrypt error: Bad Packet ID for OpenVPN, and this nonce warnings for Wireguard). This culminates in packets needing to be resent, leading to throughput cuts, or even disconnections in some softwares.

It could indicate a replay. A replay is, in a simple connection A > B > C, when B is not just passing on packets, but instead resending previously received ones. It could be done by the access point for Quality of Service purposes (like prioritizing certain devices, applications, etc.) or it could be malicious where some device tries to pose as an access point and, while generally relaying packets, checks their content for anything interesting.
Another thing might be that something interferes with the wireless signal and the access point is constantly forced to resend transmissions because it didn't get ACKnowledgments back.

What truly stands out in your case is that you get these messages every five seconds. Can you imagine anything in your network or computer that could do something to the wireless signal (or the devices sending them) every five seconds?

In any case, you can greatly reduce this by using OpenVPN in TCP mode since TCP guarantees orderly transmission and reception. UDP used by Wireguard is a fire-and-forget kinda thing. Of course, it's simply best to check out why those reorderings are happening in the first place

[udp_monkey33 0]

1 hour ago, OpenSourcerer said:

Basically it looks like this to me: It occurs that some packets are sent "in advance" while a previous flow of packets is still ongoing. It's like you are being sent a row of numbers – 1, 2, 3, 4, 5, 6, 7, 8 – but instead you somehow get the 8 first, then 1-7 after it. This is not liked by either OpenVPN or Wireguard: Both protocols warn you that this is happening and drop all packets that are unorderly received (AEAD decrypt error: Bad Packet ID for OpenVPN, and this nonce warnings for Wireguard). This culminates in packets needing to be resent, leading to throughput cuts, or even disconnections in some softwares.

It could indicate a replay. A replay is, in a simple connection A > B > C, when B is not just passing on packets, but instead resending previously received ones. It could be done by the access point for Quality of Service purposes (like prioritizing certain devices, applications, etc.) or it could be malicious where some device tries to pose as an access point and, while generally relaying packets, checks their content for anything interesting.
Another thing might be that something interferes with the wireless signal and the access point is constantly forced to resend transmissions because it didn't get ACKnowledgments back.

What truly stands out in your case is that you get these messages every five seconds. Can you imagine anything in your network or computer that could do something to the wireless signal (or the devices sending them) every five seconds?

In any case, you can greatly reduce this by using OpenVPN in TCP mode since TCP guarantees orderly transmission and reception. UDP used by Wireguard is a fire-and-forget kinda thing. Of course, it's simply best to check out why those reorderings are happening in the first place

I understand now, thanks.

Honestly no, I can't think of anything in my network or computer that would do something like that. But just in case it was in fact on my computer (Windows 11), do you know of a way I could check what might be the culprit?

Also, I tried using OpenVPN in TCP mode but then I get really low download speeds and WireGuard just happens to be way faster. Edited ... by udp_monkey33

[OpenSourcerer 1435]

1 hour ago, udp_monkey33 said:

But just in case it was in fact on my computer (Windows 11), do you know of a way I could check what might be the culprit?

Hrm, try Safe Mode with Network Drivers, maybe, connect to the VPN, try to download something?
 

1 hour ago, udp_monkey33 said:

Also, I tried using OpenVPN in TCP mode but then I get really low download speeds and WireGuard just happens to be way faster.

Because of the guarantees of TCP, it was almost expected to perform so poorly in your case. There is so much interference (with packet ordering or even loss) that it forces constant resends. Can you maybe try a cable connection to rule out wireless being the problem?

[udp_monkey33 0]

Quote

Because of the guarantees of TCP, it was almost expected to perform so poorly in your case. There is so much interference (with packet ordering or even loss) that it forces constant resends. Can you maybe try a cable connection to rule out wireless being the problem?

Unfortunately, I can't.

.

Quote

Hrm, try Safe Mode with Network Drivers, maybe, connect to the VPN, try to download something?

And what should I be on the lookout for when I do that? Should I be actively monitoring something with a program?

[OpenSourcerer 1435]

2 hours ago, udp_monkey33 said:

Unfortunately, I can't.

Not even for a short time? It's just for troubleshooting purposes.
 

2 hours ago, udp_monkey33 said:

And what should I be on the lookout for when I do that? Should I be actively monitoring something with a program?

It's primarily to rule out interference by any softwares you might be running and not knowing that they are doing something to the connection. Safe Mode doesn't launch those at boot.