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
    Commented Sep 6, 2013 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... Commented Sep 6, 2013 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? Commented Sep 6, 2013 at 19:14

8 Answers 8


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
    Commented Jul 1, 2017 at 21:55
  • In my case it was ("Mikrotik hotspot") Commented Feb 11, 2019 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.

  • 1
    @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. Commented Sep 6, 2013 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. :) Commented Sep 9, 2013 at 9:43
  • 1
    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. Commented Dec 11, 2014 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.

  • 4
    I tried a few things and none worked, but this one did!
    – Wojtek
    Commented Nov 27, 2019 at 11:01
  • 2
    Ah-HA! This was the only answer which worked for my Lubuntu laptop. To be clear, I had to open a website which I had never visited before in an incognito window. Worked like a charm!
    – Ben Blank
    Commented Dec 25, 2021 at 1:49
  • Didn't work for me. I am using Ubuntu 22.04
    – Coder
    Commented Feb 9, 2023 at 18:03

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.

  • 1
    This just worked for me also on WIFI on Db, life saver - thanks!
    – jfy133
    Commented Sep 30, 2021 at 9:30
  • This is what finally worked for me, had to delete five extraneous bridges and then the captive portal worked perfectly.
    – labarna
    Commented Sep 17, 2022 at 16:44
  • Since bridge-utils may not be installed always, one can also delete it from Advanced Network Configuration. However this did not work for me.
    – Coder
    Commented Feb 9, 2023 at 18:02
  • For completeness sake on Ubuntu, without having to install route or bridge-utils: List bridges with ip link show type bridge and delete a bridge with sudo ip link delete br-4aab526d8051 type bridge
    – JonasV
    Commented Jul 25, 2023 at 12:38

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.

In case the colliding docker needs to be kept installed, the network device should be possible to bring down using something like ip link delete docker0. If not having the required tools installed, one can do docker network prune to free up the bridge network. It might not work if having containers actively using that network, but at the very least it does not require having to completely uninstall Docker.

  • This was my problem, bad idea to use private ip range for captive portal. 172.17/16 routed out wrong interface. Thanks.
    – Pieter
    Commented May 23, 2020 at 23:03
  • The same on me. My hotel is trying to direct me to a portal at 172.17.x.x. After running ip link delete docker0 I can load this page successfully Commented Jan 1, 2022 at 11:07

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.


I had a Docker bridge network that was clobbering the IP address of the gateway (see cayhorstmann's answer for info on how to figure that out).

I couldn't use cayhorstmann's answer because I couldn't install bridge-utils, but I ran docker network prune and that was able to free up that bridge network. It might not work if you have containers actively using that network, but at the very least you don't have to completely uninstall Docker.

  • To my eyes this answer appears practically identical to BradChesney79's existing answer. I'll recommed the answer to be deleted, as the question is not mentioning docker and it has already been bought up as a potential culprit.
    – sampi
    Commented Mar 24, 2023 at 17:00
  • 1
    I agree that they're similar. I wanted to leave this as a comment on BradChesney79's answer, but I don't have the reputation on Stack Exchange to comment on someone else's answer. I'd argue that there's value in having docker network prune documented since if the user can't connect to WiFi they can't install bridge-utils. If someone can put that as a comment under Brad's answer I'd be happy to have this deleted. Commented Mar 26, 2023 at 17:53
  • Oh! The struggle when not having sufficient reputation. I feel your struggle @tyler-smith. I've made an attempt at incorporating both the existing comment and your addition into the existing Docker answer. Lets see if it passes the review needed to make this answer situation neater.
    – sampi
    Commented Mar 29, 2023 at 10:49

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
    Commented Oct 27, 2018 at 0:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .