[PacketFence-users] Cisco Catalyst 9300 and 9400 support

2017-12-14 Thread Jeremy Plumley via PacketFence-users 
Just reaching out to see if anyone has implemented Packetfence on a Cisco 
Catalyst 9300 or 9400 model switch? This seems to be Cisco's new line that will 
probably phase out 4500 and 6500 model switches.

Jeremy Plumley
ITS Network Administrator
Ext 50024
E-Mail correspondence to and from this address may be subject to the North 
Carolina Public Records Law and shall be disclosed to third parties when 
required by the statutes (G.S. 132-1.)
--
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
PacketFence-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/packetfence-users

[PacketFence-users] Dynamic authentication methods based on browser

2017-12-14 Thread Thomas M. Wilson via PacketFence-users 
I'm trying to set up our portal to not display Google authentication as
a choice when the device that's connecting is an iPhone. Why? Well,
OAuth doesn't work anymore with iPhones since Google changed things and
required a full-blown browser when doing OAuth rather than the mini
browser that iPhones use when authenticating to a portal (the dreaded
403 "disallowed_useragent" error).

My first thought was to have a completely different connection profile
strictly for iPhones that wouldn't have Google as an authentication
choice. However, using device_class == "iPhone" in the advanced filter
on the profile doesn't seem to work so users see the default portal
that has Google listed. In fact, the advanced filter doesn't seem to
work at all - changing the default profile to have a filter of
device_class == "Windows" still shows that portal for all devices.

Anyways, my next thought was to modify the content-with-choice.html
file to look at the user agent and filter out the Google authentication
if the user agent contained "iPhone". The problem I'm having here is
determining which variable holds the user agent. What I want to do is
something like:
[% FOREACH module in modules %]
[% IF module.id == "Guest_root+Guest_authentication+Guest_Google" &&
user_agent =~ "iPhone" %]

[% ELSE %]

[% END %]
[% END %]

Has anyone else done this? Or better yet, how is everyone else dealing
with the Google/iPhone issue?

Thanks
Tom



smime.p7s
Description: S/MIME cryptographic signature
--
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
PacketFence-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/packetfence-users

[PacketFence-users] Cluster - Portal opening

2017-12-14 Thread Luís Torres via PacketFence-users 
 

Hi mates, 

is there a way to speed up the opening of the portal
webpage? in the cluster it takes a few seconds to open it... 

cheers 
 --
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
PacketFence-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/packetfence-users

Re: [PacketFence-users] Turning on Firewall SSO causing pfdhcplistener process to stall

2017-12-14 Thread Torry, Andrew via PacketFence-users 
Follow up to my issues with pfdhcpdlistener process stalling when using 
Fortigate firewall SSO

This seems to be some sort of race condition in the API processing of DHCP.

As far as I can tell the pfdhcplistener process analyses the DHCP packet and 
punts it on to the
pf:dhcp:processor.pm:process_packet via the API.

The pf:dhcp:processor.pm module registers the IP and MAC addresses extracted 
from the DHCP packets
in the nodes table of the database. At this point it also performs the SSO to 
the firewall. This SSO request
is punted to the pf:firewallsso module again via the API.

When I turn on the SSO everything works fine for a while. Every so often the 
QUEUE length for the pfdhcplistener
process will rise to about 15 and then drop back to 0 but eventually (about 20 
minutes) a spike in the the QUEUE length for
the pfdhcplistener process rises to over 30 but then does not drop back to 0 
but very rapidly rises to several 1000 at which
time the whole pf:dhcp:processor.pm module stops getting any more packets from 
the API.

I cannot find any ERROR messages in the log files (under TRACE mode) for any of 
the systems. The only thing I have
noted is that more than 1 pfdhcplistener is picking up the same DHCP packet 
from the queue:-

Dec 13 14:52:32 pfqueue(20439) INFO: [mac:unknown] APKT---DHCPACK for 
88:e8:7f:cd:85:d5(10.240.240.28) for 1800 seconds 
(pf::dhcp::processor::process_packet)
Dec 13 14:52:32 pfqueue(20439) INFO: [mac:unknown] The listener process is on 
the same server as the DHCP server. (pf::dhcp::processor::pf_is_dhcp)
Dec 13 14:52:32 pfqueue(20439) INFO: [mac:unknown] DHCPACK from 10.30.249.118 
(00:26:98:0a:86:41) to host 88:e8:7f:cd:85:d5 (10.240.240.28) for 1800 seconds 
(pf::dhcp::processor::parse_dhcp_ack)
Dec 13 14:52:32 pfqueue(20439) INFO: [mac:unknown] The listener process is on 
the same server as the DHCP server. (pf::dhcp::processor::pf_is_dhcp)
Dec 13 14:52:32 pfqueue(20439) INFO: [mac:unknown] Updating iplog for 
88:e8:7f:cd:85:d5 -> 10.240.240.28 (pf::dhcp::processor::handle_new_ip)
Dec 13 14:52:32 pfqueue(20455) INFO: [mac:unknown] APKT---DHCPACK for 
88:e8:7f:cd:85:d5(10.240.240.28) for 1800 seconds 
(pf::dhcp::processor::process_packet)
Dec 13 14:52:32 pfqueue(20455) INFO: [mac:unknown] The listener process is on 
the same server as the DHCP server. (pf::dhcp::processor::pf_is_dhcp)
Dec 13 14:52:32 pfqueue(20455) INFO: [mac:unknown] DHCPACK from 10.30.249.118 
(00:26:98:0a:86:41) to host 88:e8:7f:cd:85:d5 (10.240.240.28) for 1800 seconds 
(pf::dhcp::processor::parse_dhcp_ack)
Dec 13 14:52:32 pfqueue(20455) INFO: [mac:unknown] The listener process is on 
the same server as the DHCP server. (pf::dhcp::processor::pf_is_dhcp)
Dec 13 14:52:32 pfqueue(20455) INFO: [mac:unknown] Updating iplog for 
88:e8:7f:cd:85:d5 -> 10.240.240.28 (pf::dhcp::processor::handle_new_ip)
Dec 13 14:52:32 pfqueue(20439) INFO: [mac:88:e8:7f:cd:85:d5] Found locationlog 
entry with role : with start date 2017-11-09 12:54:07 
(pf::dhcp::processor::check_for_parking)
Dec 13 14:52:32 pfqueue(20439) WARN: [mac:88:e8:7f:cd:85:d5] 88:e8:7f:cd:85:d5 
STUCK on the registration role for 2944705 seconds 10.240.240.28. Triggering 
parking violation (pf::dhcp::processor::check_for_parking)
Dec 13 14:52:32 pfqueue(20455) INFO: [mac:88:e8:7f:cd:85:d5] Found locationlog 
entry with role : with start date 2017-11-09 12:54:07 
(pf::dhcp::processor::check_for_parking)
Dec 13 14:52:32 pfqueue(20455) WARN: [mac:88:e8:7f:cd:85:d5] 88:e8:7f:cd:85:d5 
STUCK on the registration role for 2944705 seconds 10.240.240.28. Triggering 
parking violation (pf::dhcp::processor::check_for_parking)
Dec 13 14:52:32 pfqueue(20439) INFO: [mac:88:e8:7f:cd:85:d5] Updating SSO for 
88:e8:7f:cd:85:d5 -> 10.240.240.28 (pf::dhcp::processor::handle_new_ip)
Dec 13 14:52:32 pfqueue(20455) INFO: [mac:88:e8:7f:cd:85:d5] Updating SSO for 
88:e8:7f:cd:85:d5 -> 10.240.240.28 (pf::dhcp::processor::handle_new_ip)

In this log extract you can see that two separate pfqueue processes are parsing 
the same DHCP packet 20455 and 20439.

I would have thought that the API hands the call to the 
pf:dhcp:processor:process_packet module and then it is removed
from the redis queue and then move on to the next one but it seems to be 
handing the same request to two processes.

Something seems very wrong with this to me but I do not really understand how 
the ‘redis’ stuff works exactly.

Andrew



Andrew Torry

Senior Infrastructure Engineer



Tel: 01326 370760

Email: andrew.to...@fxplus.ac.uk




[cid:image006688.PNG@e19eb3b5.47ba8025]
[Falmouth Exeter Plus]  
[cid:imageebb35e.PNG@c222caf4.4ca49032]


[Twitter]   [Facebook] 
[Instagram] 
 [YouTube] 


[cid:imagecdefb1.PNG@7255074d.4f8bc57a]


[Falmouth University]

Re: [PacketFence-users] Ubiquiti UniFi AP Captive Portal

2017-12-14 Thread Timothy Mullican via PacketFence-users 
I was able to manually update my docker container, and I can confirm dynamic 
VLAN assignment is still present for 802.1x SSIDs, at least in my instance 
running the latest firmware (5.6.26). See photo below:
https://i.imgsafe.org/1b/1b9c0cf761.png
I wonder if some kind of configuration on your controller got messed up. Not 
sure.
On Wednesday, December 13, 2017, 10:35:21 AM CST, Timothy Mullican 
 wrote:  
 
 It shows up fine for me using the linuxserver/UniFi docker container (running 
5.6.22 on CentOS 7.3). Weird it disappeared for you. They did just release 
5.6.26 two days ago though. I haven’t upgraded to the latest yet. Perhaps they 
changed something. 

Sent from mobile phone
On Dec 13, 2017, at 10:08, E.P. via PacketFence-users 
 wrote:



#yiv9027254960 #yiv9027254960 -- _filtered #yiv9027254960 {panose-1:2 4 5 3 5 4 
6 3 2 4;} _filtered #yiv9027254960 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 
3 2 4;} _filtered #yiv9027254960 {font-family:Tahoma;panose-1:2 11 6 4 3 5 4 4 
2 4;} _filtered #yiv9027254960 {font-family:Consolas;panose-1:2 11 6 9 2 2 4 3 
2 4;} _filtered #yiv9027254960 {}#yiv9027254960 #yiv9027254960 
p.yiv9027254960MsoNormal, #yiv9027254960 li.yiv9027254960MsoNormal, 
#yiv9027254960 div.yiv9027254960MsoNormal 
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;color:black;}#yiv9027254960 
a:link, #yiv9027254960 span.yiv9027254960MsoHyperlink 
{color:blue;text-decoration:underline;}#yiv9027254960 a:visited, #yiv9027254960 
span.yiv9027254960MsoHyperlinkFollowed 
{color:purple;text-decoration:underline;}#yiv9027254960 p 
{margin-right:0in;margin-left:0in;font-size:12.0pt;color:black;}#yiv9027254960 
pre 
{margin:0in;margin-bottom:.0001pt;font-size:10.0pt;color:black;}#yiv9027254960 
span.yiv9027254960HTMLPreformattedChar 
{font-family:Consolas;color:black;}#yiv9027254960 
span.yiv9027254960EmailStyle20 {color:#1F497D;}#yiv9027254960 
.yiv9027254960MsoChpDefault {font-size:10.0pt;} _filtered #yiv9027254960 
{margin:56.7pt 42.5pt 56.7pt 85.05pt;}#yiv9027254960 
div.yiv9027254960WordSection1 {}#yiv9027254960 _filtered #yiv9027254960 {} 
_filtered #yiv9027254960 {} _filtered #yiv9027254960 {}#yiv9027254960 ol 
{margin-bottom:0in;}#yiv9027254960 ul {margin-bottom:0in;}#yiv9027254960 
Hm…

This is interesting. I’m building the whole packetfence solution for a large 
WiFi network distributed through 20 sites and built on Ubiquiti Unifi. What was 
your previous controller version, Fabrice ? I’m also on 5.6.22 now

  

Eugene

  

From: Fabrice Durand via PacketFence-users 
[mailto:packetfence-users@lists.sourceforge.net] 
Sent: Wednesday, December 13, 2017 7:51 AM
To: packetfence-users@lists.sourceforge.net
Cc: Fabrice Durand
Subject: Re: [PacketFence-users] Ubiquiti UniFi AP Captive Portal

  

Hello Guys,

just upgraded my controller and oh surprise dynamic vlan assignment disappear 
 


Regards
Fabrice



Le 2017-12-13 à 02:40, Timothy Mullican via PacketFence-users a écrit :


Geert,

First in order to use 802.1x (and MAC-based auth for the open network) with the 
UniFi you must apply the patch at:

https://patch-diff.githubusercontent.com/raw/inverse-inc/packetfence/pull/2735.diff

  

You can run the following commands to accomplish this:

# sudo wget -P /usr/local/pf/ 
https://patch-diff.githubusercontent.com/raw/inverse-inc/packetfence/pull/2735.diff
 

# cd /usr/local/pf

# sudo patch -p1 < 2735.diff

  

Also have a look at:

https://community.ubnt.com/t5/UniFi-Wireless/Packetfence-7-1-Out-of-Band-Dynamic-VLAN-with-Unifi/td-p/1990175

https://community.ubnt.com/t5/UniFi-Wireless/Feature-request-disable-pmksa-caching/m-p/2112479

  

You might need to restart your PacketFence box here (or at least the services), 
since it won't respond to new RADIUS requests from the UniFi without the patch.

  

Next go to 
https://github.com/inverse-inc/packetfence/blob/ae18f50b4879cc2d4132490fcee33f2fbe53b36f/docs/PacketFence_Network_Devices_Configuration_Guide.asciidoc#ubiquiti-1
 and read through the VLAN enforcement "Secure SSID" section. On the UniFi 
controller you have to create a file called "config.properties" in the current 
site (e.g., /usr/lib/unifi/data/sites/default/config.properties or 
C:\Users\\Ubiquiti Unifi\data\sites\default\config.properties) and 
insert the appropriate "config.system_cfg.[number (start with 1 and increment 
each line)]=aaa.[profile id].auth_cache=disabled" to disable pmksa caching ONLY 
for the 802.1x SSIDs, otherwise RADIUS deauth won't work. Once you do that you 
need to force re-provision the UniFi AP by clicking on it (from the controller 
web ui), selecting config->Manage Device, and click Provision.

  

On the PacketFence web UI, make sure the interface connected to your UniFi 
controller/AP has the RADIUS daemon enabled (click on the interface under 
Configuration->Network Configuration->Interfaces and click the text box next to 
"Additional listening daemons").

  

Next, make

Re: [PacketFence-users] Ubiquiti UniFi AP Captive Portal

2017-12-14 Thread Timothy Mullican via PacketFence-users 
It sounds like the invalid VLAN error might be a problem on the UniFi 
controller/AP itself: 
https://community.ubnt.com/t5/UniFi-Wireless/MAC-Radius-Authentication-Issue/td-p/2141662
 

On Wednesday, December 13, 2017, 5:42:37 PM CST, Timothy Mullican 
 wrote:  
 
 I was able to manually update my docker container, and I can confirm dynamic 
VLAN assignment is still present for 802.1x SSIDs, at least in my instance 
running the latest firmware (5.6.26). See photo below:
https://i.imgsafe.org/1b/1b9c0cf761.png
I wonder if some kind of configuration on your controller got messed up. Not 
sure.
On Wednesday, December 13, 2017, 10:35:21 AM CST, Timothy Mullican 
 wrote:  
 
 It shows up fine for me using the linuxserver/UniFi docker container (running 
5.6.22 on CentOS 7.3). Weird it disappeared for you. They did just release 
5.6.26 two days ago though. I haven’t upgraded to the latest yet. Perhaps they 
changed something. 

Sent from mobile phone
On Dec 13, 2017, at 10:08, E.P. via PacketFence-users 
 wrote:



#yiv1659415244 -- filtered {panose-1:2 4 5 3 5 4 6 3 2 4;}#yiv1659415244 
filtered {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;}#yiv1659415244 
filtered {font-family:Tahoma;panose-1:2 11 6 4 3 5 4 4 2 4;}#yiv1659415244 
filtered {font-family:Consolas;panose-1:2 11 6 9 2 2 4 3 2 4;}#yiv1659415244 
filtered {}#yiv1659415244 p.yiv1659415244MsoNormal, #yiv1659415244 
li.yiv1659415244MsoNormal, #yiv1659415244 div.yiv1659415244MsoNormal 
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;color:black;}#yiv1659415244 
a:link, #yiv1659415244 span.yiv1659415244MsoHyperlink 
{color:blue;text-decoration:underline;}#yiv1659415244 a:visited, #yiv1659415244 
span.yiv1659415244MsoHyperlinkFollowed 
{color:purple;text-decoration:underline;}#yiv1659415244 p 
{margin-right:0in;margin-left:0in;font-size:12.0pt;color:black;}#yiv1659415244 
pre 
{margin:0in;margin-bottom:.0001pt;font-size:10.0pt;color:black;}#yiv1659415244 
span.yiv1659415244HTMLPreformattedChar 
{font-family:Consolas;color:black;}#yiv1659415244 
span.yiv1659415244EmailStyle20 {color:#1F497D;}#yiv1659415244 
.yiv1659415244MsoChpDefault {font-size:10.0pt;}#yiv1659415244 filtered 
{margin:56.7pt 42.5pt 56.7pt 85.05pt;}#yiv1659415244 
div.yiv1659415244WordSection1 {}#yiv1659415244 filtered {}#yiv1659415244 
filtered {}#yiv1659415244 filtered {}#yiv1659415244 ol 
{margin-bottom:0in;}#yiv1659415244 ul {margin-bottom:0in;}#yiv1659415244 
Hm…

This is interesting. I’m building the whole packetfence solution for a large 
WiFi network distributed through 20 sites and built on Ubiquiti Unifi. What was 
your previous controller version, Fabrice ? I’m also on 5.6.22 now

  

Eugene

  

From: Fabrice Durand via PacketFence-users 
[mailto:packetfence-users@lists.sourceforge.net] 
Sent: Wednesday, December 13, 2017 7:51 AM
To: packetfence-users@lists.sourceforge.net
Cc: Fabrice Durand
Subject: Re: [PacketFence-users] Ubiquiti UniFi AP Captive Portal

  

Hello Guys,

just upgraded my controller and oh surprise dynamic vlan assignment disappear 
 


Regards
Fabrice



Le 2017-12-13 à 02:40, Timothy Mullican via PacketFence-users a écrit :


Geert,

First in order to use 802.1x (and MAC-based auth for the open network) with the 
UniFi you must apply the patch at:

https://patch-diff.githubusercontent.com/raw/inverse-inc/packetfence/pull/2735.diff

  

You can run the following commands to accomplish this:

# sudo wget -P /usr/local/pf/ 
https://patch-diff.githubusercontent.com/raw/inverse-inc/packetfence/pull/2735.diff
 

# cd /usr/local/pf

# sudo patch -p1 < 2735.diff

  

Also have a look at:

https://community.ubnt.com/t5/UniFi-Wireless/Packetfence-7-1-Out-of-Band-Dynamic-VLAN-with-Unifi/td-p/1990175

https://community.ubnt.com/t5/UniFi-Wireless/Feature-request-disable-pmksa-caching/m-p/2112479

  

You might need to restart your PacketFence box here (or at least the services), 
since it won't respond to new RADIUS requests from the UniFi without the patch.

  

Next go to 
https://github.com/inverse-inc/packetfence/blob/ae18f50b4879cc2d4132490fcee33f2fbe53b36f/docs/PacketFence_Network_Devices_Configuration_Guide.asciidoc#ubiquiti-1
 and read through the VLAN enforcement "Secure SSID" section. On the UniFi 
controller you have to create a file called "config.properties" in the current 
site (e.g., /usr/lib/unifi/data/sites/default/config.properties or 
C:\Users\\Ubiquiti Unifi\data\sites\default\config.properties) and 
insert the appropriate "config.system_cfg.[number (start with 1 and increment 
each line)]=aaa.[profile id].auth_cache=disabled" to disable pmksa caching ONLY 
for the 802.1x SSIDs, otherwise RADIUS deauth won't work. Once you do that you 
need to force re-provision the UniFi AP by clicking on it (from the controller 
web ui), selecting config->Manage Device, and click Provision.

  

On the PacketFence web UI, make sure the interface connected to