Re: [PacketFence-users] Packetfence with Cisco Meraki
Hi, I am also trying to get PF working with Meraki and have followed the instructions provided by Antoine. Everything seems to be configured correctly including the cloud IP address but I'm getting the following error in packetfence.log. Oct 14 11:35:02 httpd.portal(886) ERROR: Accessing hash config::Switch with undef key. Caller : pf::SwitchFactory::instantiate. (pfconfig::cached_hash::FETCH) (pfconfig::cached_hash::FETCH) Oct 14 11:35:02 httpd.portal(886) ERROR: WARNING ! Unknown switch(es) (pf::SwitchFactory::instantiate) Any suggestions would be appreciated. Thanks, Michael Stone -- Message: 2 Date: Tue, 13 Oct 2015 21:36:23 +0300 From: Sanya Silas <silasname...@gmail.com<mailto:silasname...@gmail.com>> Subject: Re: [PacketFence-users] Packetfence with Cisco Meraki To: packetfence-users@lists.sourceforge.net<mailto:packetfence-users@lists.sourceforge.net> Message-ID: <CAPRnQDigMiAEb+4qRTVENwX0V0hN5-1U=luut4rcf9fcncl...@mail.gmail.com<mailto:CAPRnQDigMiAEb+4qRTVENwX0V0hN5-1U=luut4rcf9fcncl...@mail.gmail.com>> Content-Type: text/plain; charset="utf-8" Thanks Antoine, I am accessing the webinterface via Meraki Cloud but there is also a smaller local page on the Meraki accessible by using my.Meraki.com while connected to the AP which I am able to resolve to an IP. Would this be the IP of the cloud controller or local AP web interface? Kind Regards, Sanya Silas Hello Silas, The documentation to configure the Meraki with PacketFence is available here(p94-95): http://www.packetfence.org/downloads/PacketFence/doc/PacketFence_Network_Devices_Configuration_Guide-5.4.0.pdf<http://www.packetfence.org/downloads/PacketFence/doc/PacketFence_Network_Devices_Configuration_Guide-5.4.0.pdf> The IP of the Meraki should be the IP of management you are using to connect the webinterface of the Meraki. Thank you, Invigor Group Limited is a company registered in Australia (ABN 75 081 368 274). This email and any attachments are intended solely for the use of the addressee(s) and may contain information that is confidential, subject to copyright and subject to legal professional privilege. If you have received this email in error, please notify the sender immediately, delete it and destroy all copies. Any views expressed are those of the individual sender unless expressly stated otherwise. In respect of this email and any attachments, to the extent permitted by law, no warranty is given and all liability is excluded,including, without limitation, liability for any loss or damage caused by way of computer virus, defect, delay, or interruption. -- ___ PacketFence-users mailing list PacketFence-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/packetfence-users
[PacketFence-users] Facebook Login Certificate Errors with Inline Reverse Proxy
Hi, We have set up an inline PacketFence system and are trying to get Facebook login working. When we redirect the user to the graph.facebook.com to authenticate via OAuth, it appears that the reverse proxy is replacing Facebook's SSL certificate with the internal PacketFence certificate. The browser then throws a certificate error and the authentication cannot be completed. Facebook uses HSTS so it is not possible to 'accept' the certificate and proceed. We've tried adding the relevant domains to the Proxy Passthroughs list but this doesn't seem to fix the issue. Has anyone else experienced this problem? There was a similar issue described in http://www.mail-archive.com/packetfence-users%40lists.sourceforge.net/msg05120.html but this involves in an internal page so adding a proper wildcard certificate for the domain will fix the problem. It is obviously not an option for us to add the correct Facebook certificate. Is there any way to hardcode the proxy passthroughs in the Apache configuration files? Thanks, Michael Invigor Group Limited is a company registered in Australia (ABN 75 081 368 274). This email and any attachments are intended solely for the use of the addressee(s) and may contain information that is confidential, subject to copyright and subject to legal professional privilege. If you have received this email in error, please notify the sender immediately, delete it and destroy all copies. Any views expressed are those of the individual sender unless expressly stated otherwise. In respect of this email and any attachments, to the extent permitted by law, no warranty is given and all liability is excluded,including, without limitation, liability for any loss or damage caused by way of computer virus, defect, delay, or interruption. -- ___ PacketFence-users mailing list PacketFence-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/packetfence-users
Re: [PacketFence-users] No answer to the RADIUS disconnect
Hi Ellyn, Have you enabled Dynamic Authorization Extensions (RFC 5176) in the hostapd.conf file on your AP? https://w1.fi/cgit/hostap/plain/hostapd/hostapd.conf # Dynamic Authorization Extensions (RFC 5176) # This mechanism can be used to allow dynamic changes to user session based on # commands from a RADIUS server (or some other disconnect client that has the # needed session information). For example, Disconnect message can be used to # request an associated station to be disconnected. # # This is disabled by default. Set radius_das_port to non-zero UDP port # number to enable. #radius_das_port=3799 # # DAS client (the host that can send Disconnect/CoA requests) and shared secret #radius_das_client=192.168.1.123 shared secret here # # DAS Event-Timestamp time window in seconds #radius_das_time_window=300 # # DAS require Event-Timestamp #radius_das_require_event_timestamp=1 Cheers, Michael Invigor Group Limited is a company registered in Australia (ABN 75 081 368 274). This email and any attachments are intended solely for the use of the addressee(s) and may contain information that is confidential, subject to copyright and subject to legal professional privilege. If you have received this email in error, please notify the sender immediately, delete it and destroy all copies. Any views expressed are those of the individual sender unless expressly stated otherwise. In respect of this email and any attachments, to the extent permitted by law, no warranty is given and all liability is excluded,including, without limitation, liability for any loss or damage caused by way of computer virus, defect, delay, or interruption. -- ___ PacketFence-users mailing list PacketFence-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/packetfence-users
Re: [PacketFence-users] No answer to the RADIUS disconnect
Hi Ellyn, The RADIUS CoA or Disconnect messages are generally sent to the IP address of the wireless LAN controller or directly to the AP in your case. I believe the IP address comes from the NAS-IP-Address attribute in the RADIUS accept-request message which is what the switch or AP thinks it's IP address is. The Controller IP setting allows you to nominated a different IP address and port for these messages. For example, in our network our switch is behind a NAT'd router in our office with an internal IP address of 192.168.10.10. PacketFence is in a totally different network (in our data centre) so if it tries to send the RADIUS messages to that internal IP address it will fail. As such, we set Controller IP to the external, static IP address of our office and then set a port forward rule in the router to forward all UDP port 3799 traffic to 192.168.10.10. From what I can understand of your network, you probably don't need to set the Controller IP value. To test what is going on, here are a few suggestions: 1. Run the RADIUS service in debug mode as follows: /usr/local/pf/bin/pfcmd service radiusd stop # stops the RADIUS server /usr/sbin/freeradius -X -d /usr/local/pf/raddb # starts a RADIUS server in debug mode 2. Check what value is defined from NAS-IP-Address in the accept-request message which should occur as soon as you connect a client to the AP. 3. Run TCPDUMP on your PacketFence server to trace the RADIUS CoA message tcpdump -i eth0 udp port 3799 -w /tmp/radius.pcap This will generate a PCAP file with just the these messages which can be viewed in Wireshark or similar. Here you will be able to see what IP address the RADIUS message is being sent to i.e. should be your AP's IP address, as well as the message attributes which may also be useful to understand what is happening. Hope this helps! Regards, Michael Stone Invigor Group Limited is a company registered in Australia (ABN 75 081 368 274). This email and any attachments are intended solely for the use of the addressee(s) and may contain information that is confidential, subject to copyright and subject to legal professional privilege. If you have received this email in error, please notify the sender immediately, delete it and destroy all copies. Any views expressed are those of the individual sender unless expressly stated otherwise. In respect of this email and any attachments, to the extent permitted by law, no warranty is given and all liability is excluded,including, without limitation, liability for any loss or damage caused by way of computer virus, defect, delay, or interruption. -- ___ PacketFence-users mailing list PacketFence-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/packetfence-users
[PacketFence-users] Open Mesh CT4 - Out of Band Support
Has anyone had a look at the new software release from Open Mesh, specifically CT4 of their CloudTrax cloud-based controller? It looks like they have added support for external RADIUS servers and splash pages which should make it easier to use PacketFence out-of-bounds. https://github.com/cloudtrax/docs/tree/master/captive_portal/splash_pages/external Basically, the redirected splash page URL is augmented with the following URL Parameters: -Client MAC -Access Point IP (UAMIP) -UAM Port -Challenge which is a randomly generated token After the user has successfully authenticated on the splash page, they need to be directed back to the AP's IP address via a request of the following structure: http://UAMIP:UAMPORT/logon?username=USERNAMEpassword=ENCRYPTED_PASSWORD Where the ENCRYPTED_PASSWORD is a hash of the Challenge combined with a Secret Key configured in the CloudTrax configuration page. Are there any switch options in PacketFence which could do this today or will it need to be built from scratch? Thanks, Michael Stone Invigor Group Limited is a company registered in Australia (ABN 75 081 368 274). This email and any attachments are intended solely for the use of the addressee(s) and may contain information that is confidential, subject to copyright and subject to legal professional privilege. If you have received this email in error, please notify the sender immediately, delete it and destroy all copies. Any views expressed are those of the individual sender unless expressly stated otherwise. In respect of this email and any attachments, to the extent permitted by law, no warranty is given and all liability is excluded,including, without limitation, liability for any loss or damage caused by way of computer virus, defect, delay, or interruption. -- ___ PacketFence-users mailing list PacketFence-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/packetfence-users
[PacketFence-users] Change IP Address for RADIUS CoA Messages
Hi all, I'm running a Ruckus ZoneDirector WLC behind a router on an internal, NAT'd IP address in our office. Our PacketFence server is on a totally separate network in our data centre. We are using WebAuth and authorization works perfectly but there is a problem with deauthorizing users. Looking at the RADIUS messages, during the accept operation the Ruckus ZD sends the internal IP address in the NAS-IP-Address field rather than the external IP address. When PF later tries to deauthorize a user, it sends the message to the internal IP address so the Ruckus ZD does not receive it. I've already talked with Ruckus but there is no way to configure the NAS-IP-Address. Is there any way to change the IP address that FreeRadius uses to send the CoA message? Thanks, Michael Invigor Group Limited is a company registered in Australia (ABN 75 081 368 274). This email and any attachments are intended solely for the use of the addressee(s) and may contain information that is confidential, subject to copyright and subject to legal professional privilege. If you have received this email in error, please notify the sender immediately, delete it and destroy all copies. Any views expressed are those of the individual sender unless expressly stated otherwise. In respect of this email and any attachments, to the extent permitted by law, no warranty is given and all liability is excluded,including, without limitation, liability for any loss or damage caused by way of computer virus, defect, delay, or interruption. -- ___ PacketFence-users mailing list PacketFence-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/packetfence-users
Re: [PacketFence-users] Ruckus RADIUS Packets not processed by radiusd
Hi Fabrice, Thanks for your help - there were a few different issues but all working now. Regards, Michael -Original Message- From: packetfence-users-requ...@lists.sourceforge.net [mailto:packetfence-users-requ...@lists.sourceforge.net] Sent: Monday, 1 June 2015 10:14 PM To: packetfence-users@lists.sourceforge.net Subject: PacketFence-users Digest, Vol 86, Issue 2 Send PacketFence-users mailing list submissions to packetfence-users@lists.sourceforge.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/packetfence-users or, via email, send a message with subject or body 'help' to packetfence-users-requ...@lists.sourceforge.net You can reach the person managing the list at packetfence-users-ow...@lists.sourceforge.net When replying, please edit your Subject line so it is more specific than Re: Contents of PacketFence-users digest... Today's Topics: 1. Re: Ruckus RADIUS Packets not processed byradiusd (Fabrice DURAND) -- Message: 1 Date: Mon, 01 Jun 2015 08:13:42 -0400 From: Fabrice DURAND fdur...@inverse.ca Subject: Re: [PacketFence-users] Ruckus RADIUS Packets not processed by radiusd To: packetfence-users@lists.sourceforge.net Message-ID: 556c4c76.8020...@inverse.ca Content-Type: text/plain; charset=windows-1252 Hello Michael, What happen if you do /usr/local/pf/bin/pfcmd service radiusd status Can you do that: /usr/local/pf/bin/pfcmd service radiusd stop radiusd -d /usr/local/pf/raddb -X And retry a connection ? And did you check on the PacketFence side with tcpdump the radius traffic ? Regards Fabrice Le 2015-06-01 02:50, Michael Stone a ?crit : Hi, We are testing PacketFence with our Ruckus WLC but for some reason the RADIUS traffic is being ignored by FreeRadius. I can see the Ruckus RADIUS traffic on the management port using TCPDUMP but there is nothing in the radius.log to suggest it has been processed. I know that FreeRadius is running because RADIUS traffic generated by the NATRadPing Test utility is appearing in the logs (as well as the TCPDUMP. Below is the TCPDUMP results for the Ruckus traffic and the NATRadPing traffic. Note I have configured NATRadPing to replicate RADIUS attributes in the Ruckus RADIUS packets. Can anyone help work out what is going wrong? Thanks, *Michael Stone* *Invigor Group* * * *Ruckus RADIUS Packet* * * *16:26:29.647203 IP (tos 0x0, ttl 61, id 0, offset 0, flags [DF], proto UDP (17), length 231)* *203-174-136-114.syd.static-ipl.aapt.com.au.46363 packetfence.radius: [udp sum ok] RADIUS, length: 203* *Access Request (1), id: 0x02, Authenticator: e7fd1f94199b81e812979a2ab10f4d2a* * Username Attribute (1), length: 19, Value: 98:03:D8:88:52:36* *0x: 3938 3a30 333a 4438 3a38 383a 3532 3a33* *0x0010: 36* * Password Attribute (2), length: 34, Value:* *0x: 517d f3df d789 37ad d425 6526 9836 f8b9* *0x0010: 03bf 2544 47ff 6561 19f1 ab32 8747 14bb* * Calling Station Attribute (31), length: 19, Value: 98-03-D8-88-52-36* *0x: 3938 2d30 332d 4438 2d38 382d 3532 2d33* *0x0010: 36* * NAS IP Address Attribute (4), length: 6, Value: 10.10.10.92* *0x: 0a0a 0a5c* * Called Station Attribute (30), length: 34, Value: 84-18-3A-18-4E-18:Ruckus-PF-Free* *0x: 3834 2d31 382d 3341 2d31 382d 3445 2d31* *0x0010: 383a 5275 636b 7573 2d50 462d 4672 6565* * Service Type Attribute (6), length: 6, Value: Framed* *0x: 0002* * NAS Port Type Attribute (61), length: 6, Value: Wireless - IEEE 802.11* *0x: 0013* * NAS ID Attribute (32), length: 19, Value: 84-18-3A-18-4E-18* *0x: 3834 2d31 382d 3341 2d31 382d 3445 2d31* *0x0010: 38* * Vendor Specific Attribute (26), length: 22, Value: Vendor: Unknown (25053)* *Vendor Attribute: 3, Length: 14, Value: Ruckus-PF-Free* *0x: 61dd 0310 5275 636b 7573 2d50 462d* *0x0010: 4672 6565* * Message Authentication Attribute (80), length: 18, Value: .A.d.f..* *0x: a241 0164 0566 0b01 00bf b95c b760 db5f* * * *NATRadPing Test Radius Traffic (with response)* * * *16:48:53.267082 IP (tos 0x0, ttl 125, id 4843, offset 0, flags [none], proto UDP (17), length 188)* *203-174-136-114.syd.static-ipl.aapt.com.au.29436 packetfence.radius: [udp sum ok] RADIUS, length: 160* *Access Request (1), id: 0x2b, Authenticator: 202020202020313431343133* * Username Attribute (1), length: 19, Value: 98:03:D8:88:52:36
[PacketFence-users] Ruckus RADIUS Packets not processed by radiusd
Hi, We are testing PacketFence with our Ruckus WLC but for some reason the RADIUS traffic is being ignored by FreeRadius. I can see the Ruckus RADIUS traffic on the management port using TCPDUMP but there is nothing in the radius.log to suggest it has been processed. I know that FreeRadius is running because RADIUS traffic generated by the NATRadPing Test utility is appearing in the logs (as well as the TCPDUMP. Below is the TCPDUMP results for the Ruckus traffic and the NATRadPing traffic. Note I have configured NATRadPing to replicate RADIUS attributes in the Ruckus RADIUS packets. Can anyone help work out what is going wrong? Thanks, Michael Stone Invigor Group Ruckus RADIUS Packet 16:26:29.647203 IP (tos 0x0, ttl 61, id 0, offset 0, flags [DF], proto UDP (17), length 231) 203-174-136-114.syd.static-ipl.aapt.com.au.46363 packetfence.radius: [udp sum ok] RADIUS, length: 203 Access Request (1), id: 0x02, Authenticator: e7fd1f94199b81e812979a2ab10f4d2a Username Attribute (1), length: 19, Value: 98:03:D8:88:52:36 0x: 3938 3a30 333a 4438 3a38 383a 3532 3a33 0x0010: 36 Password Attribute (2), length: 34, Value: 0x: 517d f3df d789 37ad d425 6526 9836 f8b9 0x0010: 03bf 2544 47ff 6561 19f1 ab32 8747 14bb Calling Station Attribute (31), length: 19, Value: 98-03-D8-88-52-36 0x: 3938 2d30 332d 4438 2d38 382d 3532 2d33 0x0010: 36 NAS IP Address Attribute (4), length: 6, Value: 10.10.10.92 0x: 0a0a 0a5c Called Station Attribute (30), length: 34, Value: 84-18-3A-18-4E-18:Ruckus-PF-Free 0x: 3834 2d31 382d 3341 2d31 382d 3445 2d31 0x0010: 383a 5275 636b 7573 2d50 462d 4672 6565 Service Type Attribute (6), length: 6, Value: Framed 0x: 0002 NAS Port Type Attribute (61), length: 6, Value: Wireless - IEEE 802.11 0x: 0013 NAS ID Attribute (32), length: 19, Value: 84-18-3A-18-4E-18 0x: 3834 2d31 382d 3341 2d31 382d 3445 2d31 0x0010: 38 Vendor Specific Attribute (26), length: 22, Value: Vendor: Unknown (25053) Vendor Attribute: 3, Length: 14, Value: Ruckus-PF-Free 0x: 61dd 0310 5275 636b 7573 2d50 462d 0x0010: 4672 6565 Message Authentication Attribute (80), length: 18, Value: .A.d.f.. 0x: a241 0164 0566 0b01 00bf b95c b760 db5f NATRadPing Test Radius Traffic (with response) 16:48:53.267082 IP (tos 0x0, ttl 125, id 4843, offset 0, flags [none], proto UDP (17), length 188) 203-174-136-114.syd.static-ipl.aapt.com.au.29436 packetfence.radius: [udp sum ok] RADIUS, length: 160 Access Request (1), id: 0x2b, Authenticator: 202020202020313431343133 Username Attribute (1), length: 19, Value: 98:03:D8:88:52:36 0x: 3938 3a30 333a 4438 3a38 383a 3532 3a33 0x0010: 36 NAS IP Address Attribute (4), length: 6, Value: 10.10.10.92 0x: 0a0a 0a5c NAS Port Type Attribute (61), length: 6, Value: Async 0x: Calling Station Attribute (31), length: 19, Value: 98-03-D8-88-52-36 0x: 3938 2d30 332d 4438 2d38 382d 3532 2d33 0x0010: 36 Called Station Attribute (30), length: 34, Value: 84-18-3A-18-4E-18:Ruckus-PF-Free 0x: 3834 2d31 382d 3341 2d31 382d 3445 2d31 0x0010: 383a 5275 636b 7573 2d50 462d 4672 6565 Service Type Attribute (6), length: 6, Value: Framed 0x: 0002 NAS Port Type Attribute (61), length: 6, Value: Wireless - IEEE 802.11 0x: 0013 NAS ID Attribute (32), length: 19, Value: 84-18-3A-18-4E-18 0x: 3834 2d31 382d 3341 2d31 382d 3445 2d31 0x0010: 38 Vendor Specific Attribute (26), length: 25, Value: Vendor: Unknown (1983730293) Vendor Attribute: 99, Length: 107 (bogus, goes past end of vendor-specific attribute) 0x: 763d 5275 636b 7573 2057 6972 656c 6573 0x0010: 732c 2049 6e63 2e 16:48:53.281113 IP (tos 0x0, ttl 64, id 15135, offset 0, flags [none], proto UDP (17), length 104) packetfence.radius 203-174-136-114.syd.static-ipl.aapt.com.au.29436: [bad udp cksum 0x84d8 - 0x8d54!] RADIUS, length: 76 Access Reject (3), id: 0x2b, Authenticator: 7d7630cd4906ee5492263b1fcd7f2b82 Reply Attribute (18), length: 56, Value: Network device does not support this mode of operation 0x: 4e65 7477 6f72 6b20 6465 7669 6365 2064 0x0010: 6f65 7320 6e6f 7420 7375 7070 6f72 7420 0x0020: 7468 6973 206d 6f64 6520 6f66 206f 7065 0x0030: 7261 7469 6f6e Invigor Group Limited is a company registered in Australia (ABN 75 081 368
[PacketFence-users] Inline Mode over the Internet
Hi all, This may seem like a dumb question but is it possible to use PacketFence's inline mode over the internet? We are interested in using PacketFence as a captive portal for basic wireless routers installed in cafés and bars. The wireless routers will each have their own ADSL or 3G/4G USB connection to the internet and our PacketFence server is installed in our data centre. I understand this means all traffic needs to pass through our PacketFence server. Does PacketFence need to provide DHCP/DNS for the wireless routers as well? Thanks, Michael Stone Invigor Group Invigor Group Limited is a company registered in Australia (ABN 75 081 368 274). This email and any attachments are intended solely for the use of the addressee(s) and may contain information that is confidential, subject to copyright and subject to legal professional privilege. If you have received this email in error, please notify the sender immediately, delete it and destroy all copies. Any views expressed are those of the individual sender unless expressly stated otherwise. In respect of this email and any attachments, to the extent permitted by law, no warranty is given and all liability is excluded,including, without limitation, liability for any loss or damage caused by way of computer virus, defect, delay, or interruption. -- ___ PacketFence-users mailing list PacketFence-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/packetfence-users
[PacketFence-users] Portal Profile Files Documentation
Hi, Is there any documentation or guidance on the files created for each portal profile? By trial and error I've worked out that login.html is the main landing page and a few other things but many of the other files are a mystery. For example, I'm trying to work out how to change the welcome text which is generated via the Template Toolkit code below. [%# Welcome text %] div id=about img src=/content/images/lock.png alt=You are not authorized / p[% i18n(register: all systems must be registered) %]/p p[% i18n(register: to complete) %]/p hr/ /div Somehow this displays the following text: As we may need to contact users regarding individual systems, all systems on this network must be registered. To complete the registration process, you will need to authenticate using your username and password. Where is this text held so it can be modified? Thanks, Michael Stone Invigor Group Invigor Group Limited is a company registered in Australia (ABN 75 081 368 274). This email and any attachments are intended solely for the use of the addressee(s) and may contain information that is confidential, subject to copyright and subject to legal professional privilege. If you have received this email in error, please notify the sender immediately, delete it and destroy all copies. Any views expressed are those of the individual sender unless expressly stated otherwise. In respect of this email and any attachments, to the extent permitted by law, no warranty is given and all liability is excluded,including, without limitation, liability for any loss or damage caused by way of computer virus, defect, delay, or interruption. -- ___ PacketFence-users mailing list PacketFence-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/packetfence-users
