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

[pallorc]

Is it a bug?

• [X] I know this is an issue with the app, and contacting Mullvad support is not relevant.

I have checked if others have reported this already

• [X] I have checked the issue tracker to see if others have reported similar issues.

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]

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]

Same on my end.

[pallorc]

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]

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]

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]

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]

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]

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]

This appears to be fixed with the latest beta.

[pallorc]

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

[Serock3]

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]

@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]

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