Captive Portal weirdness - client not being redirected to login page



  • I have a client machine (Ubuntu 16.04) which is not being redirected to the captive portal login page. The only way I can get the redirection to CP login page is by entering 10.10.10.10 in the browser.

    IP and DNS on the client are automatically served from pfSense (2.3.2 i386 nanobsd) and look normal.

    Other clients are being redirected in the expected manner.

    Weird thing is, if I boot the errant machine using a live USB stick, it works as expected. What could be up with it? It's my testing/setup pc so I'd really like to sort it out.  :'(


  • Netgate

    Completely up to the client. Nothing to do with the portal.



  • and yet it works perfectly with captive portal disabled, using the DNS specified by pfSense



  • @Grogorio:

    ….
    Weird thing is, if I boot the errant machine using a live USB stick, it works as expected. What could be up with it? It's my testing/setup pc so I'd really like to sort it out.  :'(

    Using other words : when you change the settings on your machine, it works.
    This pretty well explains what's up  ;D



  • Well thanks guys, but I'd pretty much worked the WHAT out for myself. What I'm trying to understand is WHY?  ::)

    So far I've traced it to the /etc/resolv.conf part of the client networking and some extra DNS entires my VPN client quietly added there, but I'm still struggling to fix it.

    Even though this appears to boil down to a linux networking issue I still feel it's relevant to this forum, since the problem is only manifest when attempting to connect via a captive portal.

    If I find a fix I will post it, in the meantime any constructive suggestions or insights are welcome


  • Netgate

    If a client is configured (by VPN or whatever) to use DNS servers that are not passed by the captive portal things are not going to work right. That client is going to have to do something like use a browser on 10.10.10.10 to get the portal to come up.



  • @Grogorio:

    Even though this appears to boil down to a linux networking issue I still feel it's relevant to this forum, since the problem is only manifest when attempting to connect via a captive portal.

    If your VPN software changes the routing table, and overrides everything your device gets from DHCP, then yes, classic : a portal (any portal, goto McvDnalds and  it won't work neither) won't work.

    VPN software 'thinks' that it has a direct Internet connection - establishes a connection to the VPN server - and changes the routing si any traffic goes to this server and now where else.

    What you can do : DO not start the VPN client at boot - first : login to the Captive portal. Your connecting will be ok. THEN (and only then) launch VPN client.



  • If a client is configured (by VPN or whatever) to use DNS servers that are not passed by the captive portal things are not going to work right. That client is going to have to do something like use a browser on 10.10.10.10 to get the portal to come up.

    VPN is definitely NOT active in this case (If my VPN is active, I cannot even connect to pfSense). However I think you are right in the sense that something is up with that VPN.

    What I tried was removing the VPN nameservers in my /etc/resolv.conf file. Didn't work. However if I replace them with pfSense nameservers it works, but I think it's a bit of a fudge, client shouldn't have to edit system files to get things moving. Seems even when the VPN is not active there is something lurking in the system from the previous session.

    I would need to investigate further, but need to get back to work and right now I'm just happy it's working again.  ;D


  • Netgate

    Again, all those are client problems and have nothing to do with the captive portal.



  • Have you tried to add the VPNs DNS IPs to the Allowed IP Addresses?

    If that works then you may request a feature to pfsense CP for having a per MAC address Allowed IP Addresses.