Hi all, I realize there are already many similar posts out there, but I’ve gone through quite a few of them and still have not resolved my issue.
The hotel I’m in has a captive portal. When I connect to this network and try to access a webpage, I do not get redirected. When I try http://neverssl.com, it can’t resolve the domain.
I’ve found out so far that the nameserver is at 192.168.184.1. The network offers me DNS servers 8.8.8.8 and the one I just mentioned.
The address, hoteltyrol.inwya.com, appears to be at 95.110.157.37 on the internet, but hitting that directly, redirects me to wifioscar.com. For which again I get a “cannot resolve” error.
DoH is off. I tried with google chrome secure DNS off. I really don’t know what to do anynmore.
Importantly, my phone (android) can connect. But I cannot seem to get any useful details from my phone (DNS is just 8.8.8.8 for example). Tethering through my phone when my phone is on wifi does not work.
and the same for the other two. And similar for other urls.
But, nonetheless, every ip address that I try (so not FQDN), redirects me to that long hotel.inwya.com link from the pastebin, which then cannot be resolved. Even 185.146.22.247 redirects me. I’m guessing that’s the portal being injected, but I don’t know why that can’t be resolved.
Indeed, resolvectl does not work. I don’t understand why:
thomas@fedora ~ resolvectl --no-pager query inwya.com
inwya.com: Name 'inwya.com' not found
This is the output from resolvectl --no-pager status, for completeness:
Global
Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Link 2 (wlo1)
Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
Protocols: +DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.184.1
DNS Servers: 192.168.184.1 8.8.8.8
DNS Domain: coova.org
Default Route: yes
Yes, it is quite unfortunately Fedora has no good support for captive portal, when any kind of localhost DNS cache is present. It has problems with default systemd-resolved, but also with unbound, dnsmasq and anything else.
You can find uri used for connectivity check by command NetworkManager --print-config | grep ^uri=. When on captive portal network, make a resolution of uri hostname via DNS provided by network. It will usually redirect you to some locally served hostname. All you need to do is to identify those local domains and use resolvectl domain wlo1 ~portal.example.net, where portal.example.net is the hostname part from Location: header in curl, where it tries to redirect you.
URI="$(NetworkManager --print-config | grep ^uri=| cut -d= -f2-)"
ALL_DNS=$(awk '$1 == "nameserver" {print $2}' /run/NetworkManager/no-stub-resolv.conf | xargs)
# Gets IP of fedoraproject.org and redirect you somewhere else.
for NS in $ALL_DNS; do
IP=$(dig +short @$NS fedoraproject.org | head -1);
[ -n "$IP" ] && curl -sfLI --resolve "fedoraproject.org:80:$IP" "$uri" | grep -i ^Location: && break; done
This might help you getting target redirection names. Then you can redirect those domains to your link. You can use then nmcli c command to add such domains prefixed with ~ into ipv4.dns-search in NM. That should make it permanent and it should work next time, until they change used names again.
Edit: In your concrete example, it should help if you use this command as root: sudo resolvectl domain wlo1 ~hoteltyrol.inwya.com. That should make it temporary. DNSSEC validation to Yes won’t work, disable it on this network. If that works, you can make it permanent:
nmcli c # choose correct $UUID for your network
sudo nmcli c modify $UUID "+ipv4.dns-search ~hoteltyrol.inwya.com"
You may need to iterate few times with multiple domains, if more of them are needed. The most simple solution is to comment out any global DNS= in /etc/systemd/resolved.conf while you stay in this place.
The uri for connectivity is http://http.mgz.de/hotspot.txt. This resolves to 45.141.37.223, which again redirects to hoteltyrol.inwya.org. Your script gives me no output, but I’m also not really sure what all of the curl options there do.
Setting sudo resolvectl domain wlo1 ~hoteltyrol.inwya.com. does not appear to have any effect.
I get the feeling I’m missing something obvious but I have no idea. I’m also not using VPN or anything. Thanks for helping me anyway! I gotta go but I’ll try again tomorrow.
Modifying the /etc/systemd/resolved/conf did have an effect: it started taking a minute or so before the redirect to hoteltyrol.inwya.org (as opposed to an instant redirect). But otherwise, no change unfortunately.
It is poorly documented if not at all. Firefox have settings for captive portal in “about:config”. NetworkManager with Gnome desktop seems to also be able to do captive portal, but to work with plasma, plasma needs to implement this as well. NetworkManager can’t do this on its own as it can’t display the dialogue.
NetworkManager has some support for detecting captive portal presence, yes. But it has no support for sending detected redirection on connectivity URI, which is needed by any cache running on localhost to redirect link-specific domains to link provided DNS. It is the Gnome shell, which executes captive portal web page.
Problem is that global DNS servers, either configured by DNS over TLS or only plain UDP, will not allow you to pass login page in typical case. That is where support of DNS cache is needed and is still lacking. I do not know how much Plasma supports something similar. Usually all it needs is explicit usage of http:// protocol, which is then redirected. Tested URL does not matter, except it might reveal something more about your machine.
No, using global DNS= in resolved.conf will not help. Typically before you pass whatever condition on captive portal, your machine is not allowed to contact outside internet. DNSOverTLS won’t help. Usually DNS is not intercepted nor modified, but port http(80) traffic is.
As I said, using only network provided DNS will usually help, at least until you pass captive portal page and get full internet access. Then you can switch to encrypted global DNS again.
This is in general true, but only if you are using DNS servers provided by the captive portal network and no global DNS servers you have configured yourself. For example protected by encryption. That is not well handled by any desktop environment nor distribution that I would know.
That is obvious if you know how the captive portal works. The magic is that the provided DNS server will answer with the IP number of the portal web page for any http:// request. And it can only do that if you use the network provided DNS. Only after you have interacted with the captive page will the DNS server start working normally.
It can work as you described, but then there’s no need and maybe even detrimental to announce a public DNS, unless they intercept it, otherwise it opens a possibility for exploiting their permissive forwarding rules.
Whether it’s just a misconfiguration or intentional for this specific captive portal, it won’t hurt to try, as the restrictions may be limited to L3 and not necessary involve L4.
Yes, sorry, that’s what I meant. I opened that URI and I get redirected to hoteltyrol.inwya.com again, which still doesn’t get resolved.
I also tried this “nss-dns” now, and that also does not seem to change anything. Any webpage or IP address that I try either can’t be resolved, or redirects me to that same inwya url again, which also can’t be resolved. NetworkManager created the following /etc/resolv.conf when I tried it:
For security reasons, it is best to keep nss-dns off, and also disable avahi when on a hotel network. The same goes for LLMNR. Both protocols may broadcast your hostname and ip numer on the hotel network to other connected users.
Please remove nameserver 8.8.8.8. You need to ask always the internal DNS server only for captive portal. Asking google will have wrong results. DNS caches do not make the request always in the order of nameservers written in /etc/resolv.conf, but prefer the fastest one. But in that case names resolvable only on the server 192.168.184.1 will return NXDOMAIN by 8.8.8.8.
Ehm, no? nss-dns is provided by glibc and reads servers written in /etc/resolv.conf. There is nothing dangerous about that. You may configure NetworkManager to ignore DNS from the network and write user specified one. That is secure, but will likely have problems with any Captive Portal.
For LLMNR and mDNS protocols, yes it might help disabling them. But unless your host queries for *.local names, it is somehow safe. Better way would be blocking it by firewall on untrusted networks. At least Avahi does not yet support runtime reconfiguration depending on network settings.