search

mullvad / mullvadvpn-app

The Mullvad VPN client app for desktop and mobile
https://mullvad.net/
GNU General Public License v3.0
5.11k stars 339 forks source link

2024.3 always connects with UDP port 443 on quantum-resistant tunnels #6221

Closed pallorc closed 2 months ago

pallorc commented 6 months ago

Is it a bug?

I have checked if others have reported this already

Current Behavior

Starting with version 2024.2 on MacOS 14.4.1, Mullvad connects using UDP port 443 after trying a random, high-number port. This is using Wireguard. Prior versions of Mullvad connect to a random port on the same computer and the same network. I've also tested this with a second MacBook, so it's not specific to the machine.

For good measure, I tried iOS as well, and that's connecting to a random UDP port as expected. Same wi-fi network, same Mullvad server.

Expected Behavior

The Mullvad app should connect to a random, high-number UDP port.

Steps to Reproduce

Attempt to connect to any Wireguard server using the Mullvad app in MacOS.

Failure Logs

No response

Operating system version

MacOS 14.4.1

Mullvad VPN app version

2024.2

Additional Information

Thank you!

pallorc commented 6 months ago

Update:

I rolled back to 2024.2 beta 1. The behavior returns to normal. The Mullvad app connects instantly to a random, high-number UDP port every time.

BionicBison05 commented 6 months ago

Same on my end.

pallorc commented 6 months ago

This issue persists on 2024.3 beta 1. Steps to reproduce are the same as above.

It seems that something was introduced between 2024.2 beta 1 and the final 2024.2 release that causes the client to fail to connect to random, high-number UDP ports and then fall back to UDP 443 every time it connects.

I don't know if the issue is limited to MacOS. Users of Linux and Windows might want to check to see what port the client is using to connect. I have seen this issue on two separate MacOS machines.

pallorc commented 6 months ago

Update:

After further troubleshooting, it appears that when the quantum resistant tunnel option is set to "on", the Mullvad client uses UDP 443. When quantum resistant tunnel is set to "auto" or "off", the Mullvad client uses a random, high-number UDP port as usual. This doesn't seem like it should be the intended behaviour.

I hope this helps!

pallorc commented 6 months ago

Thanks for the suggestion. However, this is not an issue with 2024.2 beta 1 and prior versions. Quantum resistant tunnels connect quickly and reliably on those versions, and not the newest. That suggests it's a change in the client app.

Also, quantum resistant tunnels have always been quick to connect for me. I've used many of the lowest latency servers nearby, with sub 30ms pings to 1.1.1.1. They've never had trouble connecting before. Switching back to 2024.2 beta 1, the issue completely goes away.

I'm open to further ideas though.

staffa commented 5 months ago

Coming from Windows 10, 22H2, with Mullvad 2024.3, and a separate computer on 22H2 with Mullvad 2024.2, I can say that I am not experiencing this issue.

trevyn commented 5 months ago

I'm seeing this too on macOS. My guess is that it's timeout-related: quantum-resistant tunnels take a few seconds to connect for me, so I think it's trying to connect on a random port, the quantum-resistant tunnel takes too long to establish, so it thinks that port is blocked, and falls back to 443 per https://github.com/mullvad/mullvadvpn-app/blob/2024.2/docs/relay-selector.md#default-constraints-for-tunnel-endpoints

Setting a manual high port and quantum-resistant tunnel works fine for me.

pallorc commented 5 months ago

Yeah, I agree. It seems like a timeout issue. The question in my mind is: why does rolling back to a pre-2024.2 release fix it? It appears that something changed between the 2024.2 beta and the final 2024.2 release to cause the timeout. And it remains in 2024.3.

Manually setting a high port is a decent workaround. It would nice to see this fixed though, particularly because it could discourage people from using quantum-safe encryption when they otherwise would.

BionicBison05 commented 2 months ago

This appears to be fixed with the latest beta.

pallorc commented 2 months ago

I'm still seeing this behavior with the latest beta (2024.5-beta1).

Serock3 commented 2 months ago

Hello! As far as we can tell, this was a regression introduced in version 2024.2 which caused the first connection attempt to fail when using quantum resistance because of uncleared firewall rules. It should be fixed in the latest release 2024.5-beta1. The fact that UDP port 443 is selected is the expected behavior for the second connection attempt.

@pallorc, does the first connection attempt still fail for you with quantum resistance consistently, or is it a sporadic issue?

pallorc commented 2 months ago

@Serock3 I've had a little more time with the beta, and now it looks like the issue is basically resolved for me. A week ago I was on a low bandwidth, high latency connection for a few days, and 2024.5-beta1 was taking a while to connect. With quantum resistant tunnels turned on, the connection was rolling over to 443 as it had been. Maybe it was the high latency.

However, now I'm back on a high bandwidth, low latency connection. Quantum resistant tunnels are reliably connecting, and they're not rolling over to 443. 🎉

Thanks for working on this issue!

Serock3 commented 2 months ago

I'm closing this issue since the bug has been resolved as of 2024.5-beta1. Please open a new issue if you find that the problem still occurs for you after this version. Keep in mind, though, as that quantum resistance takes a little longer to connect. On unreliable connections, this may cause the daemon to retry the connection using UDP with port 443 as it did for @pallorc