"you are connected" after user has been disconnected
-
captive portal has been running for a couple of months. there are a few issues though. Some users connect just fine to the open wifi, get the pfsense captive portal, input their voucher or logon details and it works.
Others (mainly IOS it seems) dont get the captive portal page, they simply get a "you are connected" or a timeout.
Others (mainly android) get the captive portal logon, input their voucher or username which doesnt accept and the page timesout. DNS is resolved in all cases (tested with FING)
If I "disconnect all" then ALL people get to captive portal and log in just fine. I wait a week and the issues start to return.
what I have observed is that:
- starting from a "disconnect all"
- User "fred" connects and logs onto captive portal ok. Can use internet. DHCP gives 10.20.20.1
- User "bob" connects and logs onto captive portal ok. Can use internet. DHCP gives 10.20.20.2
- User "jim" connects and logs onto captive portal ok. Can use internet. DHCP gives 10.20.20.3
- User "Fred" does not log on for a number of days. His DHCP lease expires.
- User "mike" connects and logs on but gets "you are connected". DHCP gives 10.20.20.1
- PFSENSE->STATUS->CAPTIVE PORTAL shows that IP and MAC for "fred" is listed. No IP or MAC for "mike" - this is expected as "mike" has not seen a captive portal address.
- If I disconnect "fred" residing on 10.20.20.1 "mike" can now get to the captive portal page, logon and use the internet.
- Captive portal gives "mike" 10.20.20.1 with his MAC address.
- "bob" does not log on for a few days. His DHCP lease expires.
- "fred" logs back on and gets DHCP 10.20.20.2
- "fred" gets a "you are connected" rather than a captive portal.
etc
I thought the captive portal worked only on MAC address and didnt care about IP address? Either that or I have messed up my settings somehow. My DHCP lease is 2 days.
Incidentally, DNS is the usual culprit. DNS is set as "pfsense forwarder service" with strict interace binding for the VLAN used by captive portal network. This VLAN is exclusive to WIFI SSID with no other traffic. A couple of local addresses are set as host overrides (intranet web servers). Rules are simple and allow all DNS servers explicitly (and intranet web servers). For testing I am allowing ALL traffic to pass on rules.
DNS tested on guest clients using FING (ping) utility.
-
t seems the IP is used. If I took time to read the footnote:
Don't forget to enable the DHCP server on the captive portal interface! Make sure that the default/maximum DHCP lease time is higher than the hard timeout entered on this page. Also, the DNS Forwarder or Resolver must be enabled for DNS lookups by unauthenticated clients to work.
I dont have a hard timeout, it was default "blank". I have the luxury of an entire 16 subnet for this VLAN so thats plenty of IPs for a 370 day lease on 365 day hard timeout. Teachers will get upset if they have to reauthenticate every day/week or even month. Annual will be fine though.
-
You,ve set up a hard time out and a soft time out ?
Also, lower your DHCP lease for the portal net. Like twice the hard time out.The portal uses both MAC and IP to keep track of users.
When you see .you are already connected then the used user name, IP and Mac is already in the connected user database.
At that moment a firewall rules permits that IP / MAC to use the internet.You are using 2.6.0 with all available portal patches from the pfsense system patches package ?
Edit : teachers could be considered as trusted users and you could consider adding the MAC of all there devices to the MAC allowed list.
All the others : hard time out 10 hours and soft time out one hour or so. -
Hah I think we posted at the same time. I didnt have a hard nor soft timeout. I do now - 525600 minutes which is 365 days. My DHCP lease is higher.
Clients shouldnt get recycled IP addresses from the DHCP server that might conflict with captive portal now. I have a 16 subnet available on this VLAN (it is only used for guest wifi) so plenty of IPs....
I didnt know there were portal patches. I will look those up.
-
@jimmychoosshoes
525600 minutes : your portal database will grow to sizes that will give issues for sure.
A couple of hundreds, probably even a couple of thousands will do, beyond that ……. I’m not sure / never saw that.
The portal uses a "pipe", one for each user and there is a maximum 63535 pipes = logged in users.Btw the portal states that a time out must be set (hard and/or soft), not doing so will bring you into issue-land.
By nature, a captive portal is good for temporary non trusted user access, let’s say for the day.
Not for a year.
And this is just IMHO : I don’t trust vouchers for longer as a week or so. -
I think pfsense captive portal will be a stopgap measure if we are asking too much. Im going to look at a packetfence again, although last time I looked it wasnt playing nicely with our UNIFI kit.
We are almost entirely authorised users (secondary authentication is radius for our portal), the voucher users will timeout themselves as they are all limited 2 day vouchers. Our users will not be happy putting their details into the portal weekly.
Thanks for the insight though.