Repeated DHCP Lease / Captive Portal change - USD 350
-
I have an environment where both customers and employees can access the open Wifi network, however it is only supposed to be used by customers. Employees have their own work-provided computers, and it's against policy for employees to be on the customer wifi.
What I want: A script run daily <configurable>from cron to scrape the DHCP logs for MAC addresses and if it sees the same MAC twice in <configurable time="">add a rule to so that they can only see a separate captive portal page. Building the webpage they see is not a requirement of the bounty, but blocking Internet access and walling them in to one page is.
It should also have an exclusion capability, excluding MACs that are OK to connect.
MAC addresses should be removed after <configurable>days or hours.How I would use it: We rarely have a customer in the building for more than a day at a time, and I would use this to allow any MAC access for 24 hours, then if it sees it again within the next month would block access. It would reset the MAC after a month.
The final deliverable should benefit all and can be incorporated into future versions of pfSense. Payment can be made via Paypal.</configurable></configurable></configurable>
-
Why don't you use CP+vouchers for such thing and contribute dollars to pfSense?!
-
Because the employees that would give out the vouchers to the customers with the code can't be trusted to give them out to other employees or use them themselves. I can only solve this one through technology. Even the managers have been told to write up people that they find bringing in their own equipment, and nothing gets done so I would rather eliminate the ability for them to get online this way or at least make it pointless.
Sure one person one day will be smart enough to go changing their wireless mac around.. there's always a way you know - still won't stop making their own hotspots with smartphones etc..
If I set a delicious cake in the customer lounge and put a sign up saying "PLEASE - CUSTOMERS ONLY" and then walk away, hold a meeting saying any employee that eats the cake we've purchased for the customers will be written up, you bet I'll have employees eating cake. They just don't care. Wifi is cake :)
I have no problem donating to pfSense but I truly would like to have this feature available. Even if it was a simple hourly cron called script to build a text file with X,Y,NN:NN:NN:NN:NN:NN in it, where X is hours since first ACK (loops @ 720 for a month maybe?), Y is hours since last seen, N's being the MAC, and if X were less than 24 hours nothing changes, if X is > 24 hours would add a rule to give them an IP but redirect (still based on the MAC) their traffic to the denied page.. meh, this is why I want it coded, I'm sure there's a smart way to do this. -
I don't know, this sounds kind of unreliable. When you say "rarely", count on a customer to come in the next day and can't go online and he is ticked and no-one knows why.
-
That's definitely a possibility but a risk I'm willing to take, and if it happens can be remedied quickly. I'd still like this functionality if anyone is willing to code it.
-
If it's that much of a problem, the next thing you'll see is people changing their MAC address every day. :) A bit of Googling and even a non-technical person could figure out how to do that. Or who's to say someone won't report to you that a customer's access is blocked when it's not a customer. There aren't good technical solutions to people problems.
That said, it is feasible to have something run in the background and create a database of used MAC addresses, then check each new portal access request against that list to allow/deny access. I'll private message you on an offer to proceed.
-
I'll likely go with the support option late this month to get it done.
If they go that far I'll make sure they either get written up or terminated. I'd file that under the "Locks only keep honest people honest" mentality - if they have been told not to do it, I've done what I can to keep them out and yet make it seamless for the customer, and the employee(s) STILL get around it, then they should find employment elsewhere. HR and IT considers it theft of service but management thinks they should be able to do whatever and they don't see the many risks and potential problems involved.sigh…. It's a thorn in my side that I really want gone.
-
If they go that far I'll make sure they either get written up or terminated. I'd file that under the "Locks only keep honest people honest" mentality - if they have been told not to do it, I've done what I can to keep them out and yet make it seamless for the customer, and the employee(s) STILL get around it, then they should find employment elsewhere. HR and IT considers it theft of service but management thinks they should be able to do whatever and they don't see the many risks and potential problems involved.
sigh…. It's a thorn in my side that I really want gone.
Is it really that much of a risk? The only problem there is people wasting company time and bandwidth. If management doesn't care about the former, you can take care of the latter reasonably by putting a speed limit on the captive portal, enough that general web browsing is fine but people can't go hog wild with P2P or anything else. The customer network should be completely segregated from your internal network, so aside from wasting time and bandwidth I don't see an issue.
-
This is what might eventually turn me away from pfSense because I see it numerous times in the threads. Different admins, different circumstances, and different geographical areas make for different ideological patterns. Tasked with managing networks, IT admins everywhere have certain rules we would all agree on. Keep the bad out, keep the network up, and so forth. Suggestions on managing networks should always be welcome to any IT administrator, and I thank ermal for the captive portal / voucher suggestion. cmb you are without a doubt a very valuable member of the pfSense community.
But when an admin has a clear idea of what he or she wants to accomplish, it shouldn't be met with resistance. I would consider that the person has done their research, has been at this a while, and has a problem that needs to be resolved and they have come up with an idea that would work in their situation - surely not all situations. Maybe even this one place. But it's there. For anyone to use if they see fit.
I've never used –no-motd in rsync. I doubt I ever would. I know it's there because someone had a need, I would wager it's there because of an automated script that didn't play well with it. Maybe that script couldn't be altered. Maybe it was a binary that the source for was long gone. Who knows?
I'd love to be able to code things from scratch but I've never gotten the hang of it. Modifying some source and bash scripts are fine. I say this because I'd love to be able to write this code and contribute it back but I lack that talent, and am willing to pay for it.Wow.. long post. Sorry - I respect the pfSense team, the FreeBSD developers etc. I'm not trying to make enemies but I just don't see why there's so much "You're doing it wrong!" mentality - maybe it's all in my head, in which case never mind ;)
-
We're just trying to help, offering suggestions. Sometimes what people set out to solve isn't what they really need to solve, or they're looking at things only one way when there are other approaches possibility equivalent, and some feedback from those of us who do nothing but build solutions like this for a living have alternatives that may achieve the end result. Don't be offended by people trying to help. Especially where offering alternatives is possibly talking ourselves out of work.
-
I agree with those statements. I'll follow up on your PM later this month if you believe this package can be coded.