Firefox VPN Beta connects but all traffic times out – MASQUE endpoint on port 2499 unreachable
Categories
(Firefox :: IP Protection, defect)
Tracking
()
People
(Reporter: 19nowakowski98, Unassigned, NeedInfo)
References
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:155.0) Gecko/20100101 Firefox/155.0
Steps to reproduce:
Start Firefox 155.0 (64-bit) on Windows.
Enable Firefox VPN Beta.
Select any VPN location (tested Germany, USA, Singapore and others).
Wait until Firefox reports that the VPN is connected.
Open any website, for example https://google.com or even http://1.1.1.1.
The problem occurs on every VPN location I tested and on two different Internet connections (my normal connection and a mobile hotspot).
I also reproduced the problem with a new Firefox profile, in Troubleshoot Mode, and with Firefox 154.0.
Actual results:
Firefox VPN reports that it is successfully connected, but all network requests through the VPN time out.
Firefox works normally immediately after the VPN is disabled.
A Firefox about:logging network log shows traffic being routed through a MASQUE endpoint:
muc139.m1.fastly-masque.net:2499
which resolves to:
23.235.42.8
The connection to this endpoint does not establish.
I also tested it independently of Firefox:
curl -v --connect-timeout 10 https://muc139.m1.fastly-masque.net:2499/
Result:
Trying 23.235.42.8:2499...
Connection timed out after 10009 milliseconds
The same curl timeout occurs through a mobile hotspot.
DNS and normal Internet connectivity work correctly. nslookup google.com, ping google.com, and ping 1.1.1.1 all succeed.
Firefox VPN was working normally on this same computer approximately two days before this issue started.
Expected results:
After Firefox VPN reports that it is connected, web traffic should be routed through the selected VPN location and websites should load normally.
|
||
Comment 1•1 day ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Networking' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Comment 2•1 day ago
|
||
Feel free to send this back if you think this is a gap in necko, but it seems that either the connection is blocked after we first establish it, or the IPProtection code doesn't properly check the connection is up?
Description
•