Your setup intrigues me. It may be possible to do what you want using existing features in PF.
This is just a thought and I have not tested it, but it may at least point you in the right direction. >From your description you have 2 portals with different auth sources, right? In auth source "A" assign a role like "Reg-A" and in the other something like "Reg-B" Then write a vlan filter that checks for the role and matches it to the current portal (owner.portal?). If it matches all is good; if not then you set the action to de-register and proceed as normal. If you can't check for the portal, you could try checking against the switch group(?). If I understand your requirement correctly something like that SHOULD work. A side effect will be that ANY TIME a user roams between portals they will have to re-register the device. I hope that helps. Also, if you haven't already, you can reach out to Inverse for this kind of custom stuff and they can get you fixed up in no time. They are also able to do custom development for very fair price. I seriously suggest having Inverse professional support, it has saved my bacon a few times when I have made a fat fingered mistake. I'm really curious if this will work, I may lab it out on my own ... if you do get it working let me know. Jake Sallee Godfather of Bandwidth System Engineer University of Mary Hardin-Baylor WWW.UMHB.EDU 900 College St. Belton, Texas 76513 Fone: 254-295-4658 Phax: 254-295-4221 ________________________________________ From: viny <[email protected]> Sent: Friday, January 13, 2017 4:01 PM To: [email protected] Cc: [email protected] Subject: Re: [PacketFence-users] PF on Ubiquity AP In principle, in the hospital where I work, what we wanted was to use PacketFence to manage both of our wireless networks, as I reported here: https://sourceforge.net/p/packetfence/mailman/message/35511813/ > Unless you configure PacketFence otherwise [...] We would like to configure PacketFence so that it automatically unregisters any node that leaves a first network and enters a second one, showing that node the second network's captive portal so it must register again to use the second network. But we don't know how to achieve that. Do you have any idea on how to do it? If you could shed some light on that problem, we would be very thankful. We could shutdown pfSense and use only PacketFence. Let me explain our setup. In our first experiment with PacketFence, we have set up its interfaces this way: - eth0: Management - eth0 VLAN ID 500: Inline Layer 2, IP address 10.100.32.1/20 - eth0 VLAN ID 600: Inline Layer 2, IP address 10.100.64.1/20 And we have set up Ubiquiti APs to serve two wireless networks: (1) SSID Corporative Wi-Fi: VLAN ID 500 (2) SSID Patients Wi-Fi: VLAN ID 600 Following the Administration Guide, in PacketFence: - We have created two user roles: (1) Employee and (2) Patient - We have added two authentication sources: (1) Active Directory with a rule so that Role = Employee and (2) external HTTP API with a rule so that Role = Patient - We have created two portal profiles: (1) Employee, with a filter Network = 10.100.32.0/20 and Source = Active Directory and (2) Patient with a filter Network = 10.100.64.0/20 and Source = external HTTP API So, what happens? (let me retype the relevant portion of my first email) > We have noticed that if we connect to the Corporative Wi-Fi and authenticate through the captive portal, then disconnect and connect to the Patients Wi-Fi, its captive portal is not shown and access to that second network is granted. In the end, the device is shown on the Nodes table with an IP Address from the Patients network, but Role = Corporative. > > Enabling the option Reauthenticate node (Should have to reauthenticate the node if vlan change) in Configuration > Main > Inline did not help. > > Is there any way we could enforce reauthentication if the user exits one network and enters another? Thank you in advance! Antonio Em Sex, 2017-01-13 às 14:53 -0500, Derek Wuelfrath escreveu: > > As we realized a bug on PacketFence that if we logged in one > > network > > then switched to the other the captive portal was not shown and > > access > > was automatically granted, now we have PacketFence managing only > > one of > > those networks and we came back to pfSense (the other server we > > used to > > present a captive portal to our Wi-Fi users) to manage the other > > one. > > Just as a side information, what you call a “bug” is actually the > normal workflow. > If the device you logged with is registered in PacketFence and you > changed connection from one network to another, the device will still > be registered in PacketFence and it will be granted access. > Unless you configure PacketFence otherwise, there is no “automatic > unregistration of a device” if you connect to a different SSID. > Devices registration (the process which shows the portal) are > “global” and not “per SSID” based. > > Cheers! > -dw. > > -- > Derek Wuelfrath > [email protected] :: +1.514.447.4918 (x110) :: +1.866.353.6153 (x110) > Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence > (www.packetfence.org) > > > On Jan 13, 2017, at 14:08, antonio <[email protected]> wrote: > > > > Where I work, we have a dozen of Ubiquiti UniFi AP-LR access > > points, as > > well as other models of access points, most of them less > > sofisticated. > > You can configure Ubiquiti APs to serve one, two or more Wi-Fi > > networks > > (with different SSIDs corresponding to different VLANs). We > > downloaded > > PacketFence ZEN (the virtual machine ready to use) and put it on a > > XenServer. We have created two VLANs for two Wi-Fi networks we have > > (two SSIDs) and added them to all the switches on the way between > > the > > access points and the virtual machine. Then, we set up the two > > VLANs on > > PacketFence as inline enforcement. > > > > As we realized a bug on PacketFence that if we logged in one > > network > > then switched to the other the captive portal was not shown and > > access > > was automatically granted, now we have PacketFence managing only > > one of > > those networks and we came back to pfSense (the other server we > > used to > > present a captive portal to our Wi-Fi users) to manage the other > > one. > > > > It's working for us :) > > > > > > Em Sex, 2017-01-13 às 13:04 -0500, Louis Munro escreveu: > > > > > > > On Jan 13, 2017, at 12:55 PM, Sallee, Jake <[email protected] > > > > u> > > > > wrote: > > > > > > > > I need to apologize. > > > > > > > > I realize that last email may not come off as light hearted > > > > which > > > > is what I intended. > > > > > > > > My apologies, I did not intend to sound condescending or rude. > > > > I > > > > was going for cordial and friendly. > > > > > > > > I blame the allergy medication. > > > Rude or not, you are correct. > > > > > > There is no way PF will run on such a limited device. > > > > > > It's a NAC. It's meant to run on a server or VM. > > > > > > > > > -- > > > Louis Munro > > > [email protected] :: www.inverse.ca > > > +1.514.447.4918 x125 :: +1 (866) 353-6153 x125 > > > Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and > > > PacketFence (ww > > > w.packetfence.org) > > > > > > --------------------------------------------------------------- > > > ---- > > > ----------- > > > Developer Access Program for Intel Xeon Phi Processors > > > Access to Intel Xeon Phi processor-based developer platforms. > > > With one year of Intel Parallel Studio XE. > > > Training and support from Colfax. > > > Order your platform today. http://sdm.link/xeonphi > > > _______________________________________________ > > > PacketFence-users mailing list > > > [email protected] > > > https://lists.sourceforge.net/lists/listinfo/packetfence-users > > ----------------------------------------------------------------- > > ------------- > > Developer Access Program for Intel Xeon Phi Processors > > Access to Intel Xeon Phi processor-based developer platforms. > > With one year of Intel Parallel Studio XE. > > Training and support from Colfax. > > Order your platform today. http://sdm.link/xeonphi > > _______________________________________________ > > PacketFence-users mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/packetfence-users > > ------------------------------------------------------------------- > ----------- > Developer Access Program for Intel Xeon Phi Processors > Access to Intel Xeon Phi processor-based developer platforms. > With one year of Intel Parallel Studio XE. > Training and support from Colfax. > Order your platform today. http://sdm.link/xeonphi > _______________________________________________ > PacketFence-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/packetfence-users ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ PacketFence-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/packetfence-users ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ PacketFence-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/packetfence-users
