I took my personal T480 (Fedora 40, Kinoite) to work the other day so I could fill out some work-related forms on it. My office has a “Guest Network”, where you connect to an open wifi, and it directs your browser to a login page. My plan was to get connected, then connect to my Mullvad VPN, and get to work. I know better than to trust random open wifi.
I tried connecting several times, with my Mullvad VPN turned off, and Firefox open (I also tried Chrome). My laptop kept refusing to connect, and would show me the following notification.
Since that didn’t work, I gave up and tethered to my phone and all was well.
This sort of Guest Network is often finicky to connect to, but I have been able to do it on Linux laptops in the past.
I’m just curious whether there is a trick to it, something extra to configure or install, or more information I can provide that will help figure this out.
First, I knew there must be a name for it, now I know that name is “Captive Portal”.
Second, Yes, I have HTTPS-only turned on in both FF and Chrome. Mullvad provides its own DNS, but I had Mullvad turned off during the connection. I figured a captive portal would need to do some DNS trickery to send that first request to their login page.
I’m probably better off tethered to my phone anyhow, but this piqued my curiosity, and tethering isn’t always an option.
FF has its integrated captive portal check, this works pretty well.
Try a vanilla profile, with firefox -p
Using mullvad-exclude firefox -p didnt work for me when keeping MullvadVPN on. No idea why but this is obviously way worse than on Android.
But it should absolutely work.
So the issue is in the phase connecting to the network? Normally it should connect but have no internet, all HTTP requests are rerouted to a different site.
Just enter http://httpforever.com for example, or many other captive portal (HTTP-only) sites in the browser
No I didn’t, because I’m not at the office today. I marked your other reply as the Solution because it made sense. I’ll take my laptop to the office next week and give it a try!
I quit Firefox and then tried mullvad-exclude firefox -p, and then I went to mullvad.net, and it showed me “not connected”, even though I was running Mullvad, so it seems to work. I just had to quit Firefox first to get out of my default profile.
Yes, the problem actually seemed to be during the connection phase. I didn’t get captures of the attempt to connect, but it would connect and say that it was negotiating an address, and then show the Authorization supplicant timeout notification I shared earlier.
It depends on what DNS do you use. If you are using systemd-resolved (Fedora default), can you please share output of resolvectl command in terminal?
What should help would be directing whatever domain that network uses for captive portal login to its interface nameservers.
First, run in terminal command curl -Lv http://fedoraproject.org/static/hotspot.txt on that network. It should redirect you to its own name, lets say http://portal.example.net. Then you need to direct portal.example.net into that interface. Let’s say your wifi interface is wlp4s0. Then command sudo resolvectl domain wlp4s0 ~portal.example.net should redirect that domain to its resolver.
Problem is this is not a permanent change. To make it permanent with NetworkManager, use nmcli c to list connections. Copy UUID of that connection, then use sudo nmcli c edit ${UUID}. There, use set ipv4.dns-search ~portal.example.net, followed by save and activate. Then quit.
That should in theory make your captive portal accessible. I don’t use systemd-resolved myself and do not often visit captive portals. But for dnsmasq configured by NM, just omit the ~ character, otherwise do it the same via NM. It should work even if you use just example.net domain, because it would redirect also all subdomains.
You need something, which can do client split-DNS. That is some local DNS cache. I doubt Mullvad VPN supports it, but I never tried it myself. These things happens, if you do not use network provided DNS, but something on internet instead, like dns.google or cloudflare-dns.com. Which without special support cannot pass captive portals. We do not have such special support (yet).
