I'm running Arch Linux on my netbook. My school have an open Access Point and we must sign into the network via a page which we are redirected to when we try to open whatever website if we are not connected.

It works on my Android Smartphone. It works on Windows. It should also works on Linux since my teacher is able to connect to it (he's running Ubuntu).

I connect to the access point with wifi-menu to generate a netctl profile. I am connected but I am not redirected to the login page, and when I type the address (taken from my phone) it don't find the server... I tried disabling IPv6, but nothing change...

  • It's running a service like networkmanager on your system?
    – mavillan
    Sep 6 '13 at 6:47
  • I don't think so... I have netctl which use wpa_supplicant... I discovered that there's also another network, which is securised by WPA. I can put login using my credentials that I should put in the login page for the open network, but I still can't access the web... Tried with my phone : it works... Sep 6 '13 at 7:28
  • It sounds like this could be an DNS issue. Can you confirm if you can access a remote host directly via an IP address? Sep 6 '13 at 19:14

If redirect page does not load, and reconnecting does not fix the issue, then the easiest next step is to address the router directly.

Try That is the most common default address, and is often not changed.

Addressing the router should send you to the redirect page.

  • 2
    Or, which worked in my case.
    – Ray
    Jul 1 '17 at 21:55
  • In my case it was ("Mikrotik hotspot") Feb 11 '19 at 9:45

What you describe is called a captive portal. They are typically used for authentication on Wi-Fi hotspots, but can be used to control wired network access as well.

There are several ways to implement a captive portal:

  • HTTP Redirection

    In this case, DNS queries from unauthenticated clients are resolved as normal. However, when the browser makes a HTTP request to the resolved IP address, the request is intercepted by a firewall acting as a transparent proxy. The client HTTP request is forwarded to a server in the local network which issues a server-side redirect with a HTTP 302 Found status code, which will redirect the client to the captive portal.

  • DNS Redirection

    In DNS based redirection the firewall ensures that only the DNS server(s) provided by DHCP may be used by authenticated clients. The firewall could also redirect any DNS queries from unauthenticated clients to the local DNS server. This DNS server will in turn return the IP address of the captive portal as a response to all DNS lookups made by unauthenticated clients.

  • IP Redirection

    In redirection working on the IP layer a router performs Destination Network Address Translation (DNAT) to reroute packets originating from an captive hosts to the captive portal. In cases where the captive portal software runs on the router itself, the packets are directed to an internal interface instead. Packets headed from the captive portal to the host get in turn their source address rewritten so that they would appear to originate from the original destination.

When troubleshooting captive portal issues, the first step would be to identify what type of redirection is in use and at which point the redirection fails. The right tool for this job is a packet analyzer, such as Wireshark. Keep in mind though, that your school's IT policy might prohibit the use of packet sniffers on the local network as such tools could easily be used to invade the privacy of others on an unencrypted network.

You could also consult the tech support at your school. They would be aware of the captive portal configuration on the local Wi-Fi network, and especially if faculty members are using Linux they probably could help in pinpointing the source of the problem.

  • @Shywim My post is not much of an answer, but it's hard to give specific advice without knowing more about the specific captive portal solution used at your school. Sep 6 '13 at 19:02
  • That's fine, it is very instructive. My problem seems to be different (I have the same problem with other networks), but I'll leave this question and accept your answer. :) Sep 9 '13 at 9:43
  • I would find it useful if this answer were edited to include information about what to look for in the packet traffic and how to respond accordingly. Dec 11 '14 at 19:11

In my case being signed in to Chrome was getting in the way. When I opened up an incognito window and went to a random webpage the redirection worked. I got this idea from a post on an Arch Linux thread.

  • 2
    I tried a few things and none worked, but this one did!
    – Wojtek
    Nov 27 '19 at 11:01

The hotel was using the 172.17.x.x network and so was my installation of docker-- since no clients were requiring me to use docker instances at present, I uninstalled it and the login redirect for signing in stopped having problems.

  • This was my problem, bad idea to use private ip range for captive portal. 172.17/16 routed out wrong interface. Thanks.
    – Pieter
    May 23 '20 at 23:03

generally the router also hosts the captive portal (but not always). If you connect to it you will generally be presented with the captive portal. To determine what the address is for the captive portal you can either look and remember the address on a device that properly redirects or you can run route -n and select the address (under Gateway) that corresponds to the default route (the top row -

Type that address (the default router address) into a browser window and hopefully you should be presented with the captive portal.


After none of the above answers got me into "Wifi on ICE" on a German train, I ran into https://gist.github.com/martinvirtel/5d35ff7a82fd4c26d502e37682a6d101. Type route -n to see the IP address of the gateway, such as         UG    600    0        0 wlp0s20f3

Then look for a bridge (br-) with the same prefix, such as     U     0      0        0 br-50e6082d8b75

Delete the bridge:

sudo ifconfig br-50e6082d8b75 down
sudo brctl delbr br-50e6082d8b75

On Ubuntu this requires the bridge-utils package.

  • This just worked for me also on WIFI on Db, life saver - thanks!
    – jfy133
    Sep 30 at 9:30

Enter http://nmcheck.gnome.org in your browser. (I added the "hotspot login" of Ubuntu 18 to my favorites and it showed that address, every time I clicked on it.) It worked for me.

  • 1
    That is a URL used by NetworkManager to test whether there is internet connectivity. It doesn't help with signing on/authenticating with the network in the first place, especially when not using GNOME.
    – JigglyNaga
    Oct 27 '18 at 0:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.