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

[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