Thank you for the reply Olivier, I actually found a work around that works for our environment by tweaking some things in our end. The more I get to know PF the more I like it. Basically for anyone interested, what we did is change the VLAN that returns from our production DB once a client has registered through our own portal. This VLAN that comes from the controller is the PF Registration VLAN. We have added registration expire settings in PF to kick people out after a certain amount of time and force them to re-authenticate.
Q1) I added an expire.node to the conf but it's not taking effect. I look in the status of the Node in the GUI, and regardless whether the clients wireless adapter is on or off, it always shows as currently active, I'm sure this is the problem. How does PF determine whether a client is active or not?
I've set up FreeRadius to forward all MAC auth to our production RADIUS server, return the correct VLAN. The client gets put in the right VLAN, now my issue is adding RADIUS auth for that username/password field for registration. I've configured registration to radius, and all clients are allowed in (from the documentation and testing purposes), but I don't see the RADIUS request package coming into PF. I'm trying to look at some of the scripts to see what's going on at the captive portal side.
From: Olivier Bilodeau [mailto:obilodeau@...]
Sent: Tuesday, February 15, 2011 11:20 AM
Subject: Re: [Packetfence-devel] Login-VLAN
On 14/02/11 11:43 AM, Manueco, Antonio wrote:
> Hello everyone,
> What we're trying to accomplish:
> Migrate to 802.1x and still support our current captive portal.
> With that said, how can we add a Login VLAN? This VLAN's purpose would
> be to place users in a captive portal before accessing the network.
> They'd have to put in their username/password before getting placed in
> the Production VLAN, kind of like how registering works, but this would
> be to check credentials against a db every time they connect before
> getting placed in the Production VLAN.
We tried various techniques for automatic de-registration of users
per-login instead of keeping them registered all the time. Most of them
have terrible user experience because wireless devices tend to
disconnect/reconnect very often (sleep, power-management, etc.). What we
recommended most of our users is to unregister clients after 1hr / 4hrs
/ daily instead. This can be done by setting the node's unregdate on the
captive portal authentication. Enable the pf::web::custom extension
point and set unregdate on registration. I think there's even an example
> I see PF acting as the DNS and DHCP server in that VLAN and with an
> Access-Accept from the RADIUS server, PF would disassociate them and
> push a new VLAN to the controller for that client. Eventually the lease
> would time out (8hrs) and then they would need to hit that captive
> portal once again. I know 802.1x solves this, which is why we're pushing
> it but as much as I'd like to drop what we currently have and do 802.1x
> across the board, the powers above me pay the bills.
Wireless 802.1X is great but, as you can see, there are ways to
accomplish what you are looking for with an Open SSID.
obilodeau@... :: +1.514.447.4918 *115 :: http://www.inverse.ca
Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
Packetfence-devel mailing list