Captive portal assign ip only if user has voucher code, no security on ssid
-
hi
I am in the process of establishing a captive portal and want the only mean of authentication to be set to voucher code.
For this i have set no security on the SSID and anyone can connect to it and obtain an ip. the ssid is broad casted via cisco lightweight ap managed via controler.once a user gets an ip they are redireted to captive portal authentication page and after entering voucher they get online.
The problem is that everyone connects to the ssid whetehr they have the voucher or not hence starving the pool.
Is there an possiblity so that a client gets an ip only if they have a valid voucher code ?
also any idea how people are using Cisco WLC and pfsense captive portal for guests ?
Regards
-
Nope. You have to add security on the WiFi or size your pool so it can accommodate the "churn" of devices through your network.
An IP address is required to enter the voucher code into the portal so DHCP has to come first.
Why would using a controller change anything? Layer 2 is layer 2.
-
Nope. You have to add security on the WiFi or size your pool so it can accommodate the "churn" of devices through your network.
An IP address is required to enter the voucher code into the portal so DHCP has to come first.
Why would using a controller change anything? Layer 2 is layer 2.
Immense thanks.
are you or anybody else aware of how it is integreated with cisco wlc ?
what style is it used in ? i need some hints on how to integrate it with cisco. -
You probably want a Cisco forum. Like I said, there is nothing special about using a controller-based WiFi system with pfSense as the router/gateway.
-
Nope. You have to add security on the WiFi or size your pool so it can accommodate the "churn" of devices through your network.
An IP address is required to enter the voucher code into the portal so DHCP has to come first.
^^ This exactly, with a captive portal on a Cisco WLC providing guest access you have two ACLs, a pre auth and a post auth ACL, the pre auth basically has the server with the login portal and the post auth defines where they can access post auth.
If you have a lot of guest clients reduce the DHCP lease time or increase the pool size.
https://www.cisco.com/c/en/us/td/docs/wireless/technology/guest_access/technical/reference/4-1/GAccess_41.html#wp1000808
How many access-points are you using, it might just be easier to buy a Unifi Cloud Key and access-point, the guest portal feature is very easy to configure with vouchers being easily made via the web or phone app.
Even the Ubiquity guest policy has a pre and post access.
-
"The problem is that everyone connects to the ssid whetehr they have the voucher or not hence starving the pool."
Your pool is not properly sized for number of clients your seeing connect with too long of lease.. Shorten you lease, up your pool size should solve this issue.
"Is there an possiblity so that a client gets an ip only if they have a valid voucher code ?"
So clearly you were not thinking it all they way through when you asked that question ;) heheheeh
-
"The problem is that everyone connects to the ssid whetehr they have the voucher or not hence starving the pool."
Your pool is not properly sized for number of clients your seeing connect with too long of lease.. Shorten you lease, up your pool size should solve this issue.
"Is there an possiblity so that a client gets an ip only if they have a valid voucher code ?"
So clearly you were not thinking it all they way through when you asked that question ;) heheheeh
Not able to decipher it :) trying to understand it.
-
"Not able to decipher it :) trying to understand it."
Your pool has X number of IP it can hand out… Lets call it 100..
192.168.1.100 to .200Lets say your dhcp lease is 24 hours... Client connects and gets .100 the dhcp server leases this IP to that client MAC for 24 hours.. At the 12 hour mark if the client is still around it would "renew" that lease for another 24 hours... This cycle continues.
While that client has the lease out.. 100 can not be given to any other clients.. If the client goes away for say 20 hours, and then comes it could ask for that 192.168.1.100 address back.. (would depend on what other networks the client has been on, etc.) Since the 24 hours has not expired then the dhcp server would lease that .100 to that client again for 24 hours..
So your problem is if your running out of IPs in your pool, that 101 clients come and ask for an IP.. All within 24 hour period.. Now your dhcp server is out leases.. So change the number of IPs you can hand out..
So vs handing out 192.168.1.100-200, hand out 192.168.0.0/22 or 1024 address not just 100... So even with your 24 hour lease, as long as you still only get your 101 clients per 24 hours you will never have a problem... Even if 1000 clients come and grab an IP and go away, every 24 hours those lease will expire and can be handed out again..
You can also decrease the lease time... So vs being 24 hours, set it to say 1 hour.. Now client comes and gets IP and goes away.. That IP is not tied up for 24 hours - its only tied up for 1 hour.. If client is online he will just renew it ever 1/2 hour is all. But once he leaves that IP will be freed up for the next guy..
So if you have a large pool say /22 or 192.168.0.1 to 192.168.3.254 - 1024 address.. And you make the lease only say 1 hour.. You could have hundreds of clients connecting and never doing anything in 1 hour period lease will go back into the pool to be able to be handed out again.. As long as you don't get more than 1024 address in 1 hour you will not run out of IPs.
Does that make more sense? You can modify the default lease times on your dhcp server settings on pfsense. See attached. You can increase the number of IPs by adjusting the netmask on pfsense from say /24 to /23 or /22 etc. .. To allow for more IPs
-
To add: you must also be sure that your Captive Portal settings are compatible with your DHCP lease lifetimes.
You must make sure the captive portal session has expired before the DHCP lease gets reissued to another user.
It is a balancing act.
Since you are using vouchers you also have the ability to automatically add MAC addresses to the passthrough list. This disconnects the captive portal session from the IP/MAC pairing and instead only looks at the MAC address. This allows users to maintain their CP sessions even if they leave and return and they get a new IP address from the DHCP server. That MAC address is automatically removed from the pass list when the voucher expires by the CP pruner process. So you can issue vouchers for intervals far longer than your DHCP lease time allowing you to shorten the lease to something like an hour or two so the pool can be smaller.
-
The passthru of mac seems like a great solution…
I put in my voucher that gives me 24 hour access.. I got address .100 when first here, leave for a few hours come back and get .101 this time - Im still good since my mac is listed as passthru...
That would allow for a very short lease time, and small pool and be able to handle lots of clients coming and going..
-
I used it with great success for vouchers good for days or weeks. Set max clients to 1 and even if they change devices the old MAC gets bumped but they still get access. They do have to enter the voucher again to change devices but such is life.
Actually that is a mis-statement. You can either allow simultaneous use (no limit on the number of MAC addresses on a voucher) or disallow simultaneous use (A new entry of the voucher bumps the old MAC address).
A welcome feature would be to put the number of allowed MACs on a voucher in the voucher roll itself. That would be great but it doesn't currently exist.
