Captive portal ignores auth
-
Captive portal was authenticating normally in AD until a few days ago. I did not understand what happened, but now it is like if the authentication configuration is ignored.
I use CP to authenticate users on a wireless network. Currently the user is no longer being redirected to the login screen. He/She connects and browses normally, but if I type in the browser http://ip_address_pfsense:8004/index.php?zone=testzone, the login screen appears and the authentication works if you type valid credentials.
It does not appear to be a firewall or DNS, as navigation works. It's just not intercepting traffic and redirecting to the login screen anymore. The behavior is as if there was no authentication configured.
-
Did the wireless AP start doing NAT/routing instead of bridging?
-
No @jimp , nothing like that happened.
-
Does anyone show online in the Captive Portal status? Do you actually see all the clients in the active DHCP leases?
The AP doing NAT is about the only thing that would explain your symptoms. The first person to come online would auth but then everyone else would pass through, because pfSense would only see the IP:MAC of the wireless router.
-
No one shows online on the CP status, unless the user forces the auth by typing the full url of the login page.
They receive an ip address through DHCP, they can even browse normally in any website.
No nat in the AP is used.
-
@aaloise said in Captive portal ignores auth:
They receive an ip address through DHCP, they can even browse normally in any website.
But do you see the client IP addresses in the DHCP lease list on pfSense?
Or is DHCP provided by some other system?
Do you see the individual clients in the ARP table?
Do you maybe have IPv6 enabled, and client traffic is exiting with IPv6? (Captive Portal does not support IPv6)
-
@aaloise said in Captive portal ignores auth:
but if I type in the browser http://ip_address_pfsense:8004/index.php?zone=testzone, the login screen appears
Check if ipfw is set up as should be : use the commands from here : https://docs.netgate.com/pfsense/en/latest/captiveportal/captive-portal-troubleshooting.html
On the client side : gateway is ok ? It should be the IP of the interface on which the captive portal is running.
-
@jimp Yes, I see see the client IP addresses in the DHCP lease list on pfSense
DHCP used is the one from pfSense. I can see the individual clients in the ARP table?
IPv6 is disabled.
-
@Gertjan I followed all the options in that link, unfortunately none solved the problem.
Gateway is ok. The ip address is the one from the interface on which the captive portal is running.
-
@aaloise said in Captive portal ignores auth:
Gateway is ok. The ip address is the one from the interface on which the captive portal is running.
And the second most important one : the DNS ? Same as the Gateway IP ? ( == pfSense Portal IP) ?
If that's so, even when your are not logged in the captive portal, you still can resolve. Is that the case ? (do a dig google.com nslookup google.com, or whatever your device offers you, it should return Google's IP)
Typically, to start, the default Resolver settings work well. -
Also make sure you didn't add some overly permissive entry in the bypass lists (IP address or hostname)
-
@Gertjan DNS and gateway are not the same IP, but always have been this way. I don't use DNS Forwarder or DNS Resolver from PfSense, but it was never a problem.
dig and nslookup return google's IP.
-
@jimp I checked it, the only ip address that bypass is the one from my DNS server (NxFilter).
-
Well, for some reason that I can't understand, there was a MAC address on the MAC's bypass list. It was a MAC unrelated to anything but a client device on our network.
All I know is that once that MAC was removed, CP started to work again. The problem is solved, but I'm not fully convinced I about the reasons that generated this problem.
