I agree completely. What we were using it for is all our wired clients and wireless *were* on the same internal lan. The captive portal was enabled on the LAN interface. All wired clients had mac-bypass entries, and the wireless clients had to get past the captive portal.
What I'm thinking is that I will have to investigate some sort of rouge detection, or maybe network access protection for the wired clients, and then completely separate the wireless traffic on another interface. I'm still interested though in anyone out there with large numbers of mac-bypass entries. Any takers? Cheers, P.S. Chris/PFsense team, I am consistently impressed by this product. You guys do very good work, and my team and I appreciate your efforts immensely. The coding is important, but the community support is above and beyond! On Fri, May 8, 2009 at 10:25 PM, RB <aoz....@gmail.com> wrote: > On Fri, May 8, 2009 at 22:06, Tim Dressel <tjdres...@gmail.com> wrote: >> Finally, I'd appreciate any feedback out there on installs with counts >> on mac bypass entries topping a 1000 count. I am considering tying >> together several of my networks and would like to know what the upper >> end on the captive portal looks like. > > The captive portal's default configuration is to filter users by MAC > address. The main difference between that and what you're doing is > that the MAC entries are made dynamically each time a user logs in. > That said, I have run a pair of Dell 2660s (dual 2GHz, 2GB) in that > default configuration over a high-churn environment with several > thousand unique clients per day with no ill effect. > > My concern was not whether pfSense could handle the number of entries, > but mainly administrative overhead. Maintaining a list of even 100 > MACs is terribly cumbersome, especially considering how trivial > MAC-only authentication is to bypass. Additionally, some of pfSense's > GUI components just don't scale well - there are some diagnostic pages > (DHCP status, CP status, ARP tables, etc.) that I've just become > accustomed to not using if the client count is over a couple hundred. > > Check your system's RRD graphs during the slowdown - if your states, > queues, or CPU aren't pegged, pfSense is likely not the culprit. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: support-unsubscr...@pfsense.com > For additional commands, e-mail: support-h...@pfsense.com > > Commercial support available - https://portal.pfsense.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
