Support logging in to captive portals without disabling the VPN

[jSadoski]

This is an insignificant issue, but it would be a cool feature. Currently, when I have the app open/active (blocking connections) on my Macbook Pro (High Sierra) and I'm trying to connect to a public wifi, e.g. the library or at a coffee shop, I have to "Disconnect" in order to raise the network login window. This makes sense why this would happen, but it's a problem when I have to shut down my VPN, connect to the network, then start the VPN again. The services already open on my laptop start transmitting info as soon as I connect and before I can start the VPN again. This happens even when Local Network Sharing is on.

I'm not certain how this would be technically possible, but if Mullvad could create an allowance for the local WiFi sign-in when it can't connect, I feel it would be much more secure.

I'm currently using release 2018.1.

[faern]

These kind of wifi login capture portals are evil and messy. It would be very hard for us to let their traffic through without risking other types of leaks. Capture portals use normal HTTP and all of them are hosted on different IPs and domain names. It would be impossible for us to have a complete list of capture portals (moving target), and it would be very hard to automatically detect what traffic is to one of them. I agree this is a cool feature, but unlikely something we can do too much about. I will leave this issue open however, since it's a good thing to have and if we come up with some idea later.

Btw, 2018.1 is incredibly old. I would strongly recommend you try to upgrade to 2018.5.

[jSadoski]

Thank you for your reply. Yes, it's exactly as I suspected but I figured opening the issue might permit some brainstorming on the topic.

I also realized after posting my version how out of date I was. I'm now on 2018.5. Thanks!

[bjowes]

When connected to an open wifi, but the login hasn't been processed, the client cannot reach anything on the internet. This situation shouldn't be hard for the Mullvad client to detect. It could then hint the user to temporarily disable the VPN to perform the login (dialog box?, notification?). By monitoring when internet becomes available, the VPN could automatically be enabled again.

I think this would improve the usability a lot.

[ibejoeb]

Google Fi does this. I'm not sure how it's implemented, or if it relies on having two interfaces. Perhaps the client itself could attempt an https connection to a well-known uri (e.g., captive.apple.com) and interpret the result.

[DianaNites]

Hit this problem and found this issue on google

It'd be great if the client could provide a way to use captive portals without disconnecting. Take advantage of split tunneling, use Electron to open the captive portal?

Split tunneling would also work as a workaround that doesnt leave every connection briefly insecure, if you're willing to install a spare browser just for this..

[real-or-random]

The problem here is DNS. You can run mullvad-exclude but that still won't give the DNS config set by NetworkManager (via DHCP).

Here's a first attempt at a workaround. Create a new firefox profile "captive" and use this script.

#!/bin/sh
# SPDX-License-Identifier: MIT-0
sudo -E unshare --mount bash -c "mount -o bind /var/run/NetworkManager/resolv.conf /etc/resolv.conf ; su $(whoami) -c 'mullvad-exclude firefox -P captive'" 

I know this is ugly and can be probably be improved and can made more secure. I'm open for suggestions.

It probably makes sense to disable telemetry in this Firefox profile. I also set a special theme to make sure I won't mix up the browser windows. It could also make sense to use private mode (--private-window) but I don't know how deleting cookies will interact with some captive portals.

edit: this is a similar project: https://github.com/FiloSottile/captive-browser

[real-or-random]

This is a version that works if you use systemd-resolved:

#!/bin/sh
# SPDX-License-Identifier: MIT-0 
sudo systemctl mask --now --runtime systemd-resolved
sudo -E unshare --mount bash -c "mount -o bind /run/NetworkManager/no-stub-resolv.conf /etc/resolv.conf ; su $(whoami) -c 'mullvad-exclude firefox -P ephemeral'"
sudo systemctl unmask --runtime systemd-resolved

It would be great to have a solution that doesn't require root and doesn't shut down systemd-resolved. This could probably be done by starting the browser in a sandbox (e.g., using bubblewrap) and deny it access to systemd-resolved.

[MarkusPettersson98]

Hello! We made improvements in the 2023.1-beta2 release which has been out for a while. Is this still an issue as of late? If not, I'll go ahead and close this issue.

[real-or-random]

Well, these improvements were for macOS. The issue still persists on Linux.(You could say that it's tracked #4483, but that one is specifically about mullvad-exclude. Not sure what has been done for macOS to make the captive portals open automatically. If the same is conceivable on Linux, then I'd argue it makes sense to leave this issue open.

[wisp3rwind]

Same here, with version 2024.8 on Linux, the issue persists (tested today).

For what it's worth,

• Firefox has a detection mechanism for captive portals: https://support.mozilla.org/kb/captive-portal which seems to involve connecting to detectportal.firefox.com,
• GNOME seems to use NetworkManager to detect captive portals: https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3408
• NetworkManager has a configurable connectivity-check URL: https://networkmanager.pages.freedesktop.org/NetworkManager/NetworkManager/NetworkManager.conf.html
• Fedora sets this to uri=http://fedoraproject.org/static/hotspot.txt

Maybe allowing some of these in a manner similar to the domains on Mac would be a partial solution?

EDIT: Newer report of the same issue (on Windows): #6419

[infogulch]

This would be great. All it would need to do is connect to any http site. That's how all of these captive portal detection tools work: try to connect to an http site, if there's a captive portal then it will redirect to the portal page. I personally use http://neverssl.com.

This repo run by the Wireless Broadband Alliance contains "documentation of captive network portal behavior on different devices" and may be relevant to any implementation here: https://github.com/wireless-broadband-alliance/captive-behavior

[MrRinkana]

I suspect this is only an issue with the "kill switch" active, right?

The android app seems to be able to connect to wifis behind captive portals, which I suspect is because the captive portal detection is being done by android itself.

At least on Linux with KDE this task seems to be on the browser to solve, which firefox does by testing with "http://detectportal.firefox.com/canonical.html". With VPN turned on firefox is simply offline, but disable the VPN and instantly a "Open sign in page for the network" (I don't remember the exact phrasing) opens.

Maybe a app level exclusion for domains that popular browsers use to detect captive portals could be excluded? In my experience all of the captive portals sit on a local IP such that if mullvad is run with "allow local ip ranges" connecting to the captive portal should be possible?

In other words: exclude "detectportal.firefox.com" (etc) from network block when not connected + allow local connections = working captive portals?

One of the great uses of a VPN is to sneak past any bullshittery the public wifis might be doing, but temporarily disabling the VPN in order to connect might give time for other stray connections (such as already open browsertabs, OS, w/e) to make connections before vpn is active ..