Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
4 additions
and
149 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,150 +1,5 @@ | ||
| ================ | ||
| Wireless support | ||
| ================ | ||
| Please refer to http://www.packetfence.org/about/supported_switches_and_aps.html for | ||
| the latest list of supported equipment. | ||
|
|
||
| There are two approaches to wireless networks. One where a controller handles | ||
| the Access Points (AP) and one where AP act individually. PacketFence supports | ||
| both approaches. | ||
|
|
||
| Wireless controllers | ||
| -------------------- | ||
|
|
||
| When using a controller, it does not matter to PacketFence what individual AP | ||
| are supported or not. As long as the AP itself is supported by your controller | ||
| and that your controller is supported by PacketFence it will work fine. | ||
|
|
||
| Access points | ||
| ------------- | ||
|
|
||
| Some Access Points behave the same if they are attached to a controller or not. | ||
| Because of that you might want to try a controller module if a controller from | ||
| the same vendor is supported in the list above. | ||
|
|
||
| Wireless hardware not on the list? | ||
| ---------------------------------- | ||
|
|
||
| Eventhough this list is small, PacketFence may support many other access points | ||
| as long as they have the following features: | ||
| - Definition of several SSID with several VLANs inside every SSID (minimum | ||
| of 2 VLANs per SSID) | ||
| - RADIUS authentication (MAC Authentication / 802.1X) | ||
| - Dynamic VLAN assignment through RADIUS attributes | ||
| - A means to de-associate or de-authenticate a client through CLI (Telnet or | ||
| SSH), SNMP, RADIUS Dyn-Auth* or WebServices | ||
|
|
||
| Most of these features work out of the box for enterprise grade Access Points | ||
| or Controllers. Where the situation starts to vary is for de-authentication | ||
| support. | ||
|
|
||
| - CLI (SSH or Telnet) | ||
| An error prone interface and requires preparation for the SSH access or is | ||
| insecure for Telnet. Not recommended if you can avoid it. | ||
|
|
||
| - SNMP | ||
| SNMP de-authentication works well when available. However Vendor support is | ||
| not consistent and the OID to use are not standard. | ||
|
|
||
| - RADIUS Dynamic Authorization (RFC3576) | ||
| RADIUS Dynamic Authorization also known as RADIUS Change of Authorization (CoA) | ||
| or RADIUS Disconnect Messages is supported by PacketFence starting with version 3.1. | ||
| When supported it is the preferred technique to perform de-authentication. | ||
| It is standard and requires less configuration from the user. | ||
|
|
||
|
|
||
| LinkUp/Down traps | ||
| ----------------- | ||
|
|
||
| - the switch sends a LinkUp trap when the port ifOperStatus is set to 1 | ||
| - the switch sends a LinkDown trap when the port ifOperStatus is set to 0 | ||
|
|
||
| This is the most basic setup and it needs a VLAN called the MAC detection VLAN. | ||
| There should be nothing in this VLAN (no DHCP server) and it should not be | ||
| routed anywhere, it is just an empty VLAN. | ||
|
|
||
| When a host connects to a switch port, the switch sends a LinkUp trap to | ||
| PacketFence. Since it takes some time before the switch learns the MAC address | ||
| of the newly connected device, PacketFence immediately puts the port in the MAC | ||
| detection VLAN in which the device will send DHCP requests (with no answer) in | ||
| order for the switch to learn its MAC address. Then pfsetvlan will send | ||
| periodical SNMP queries to the switch until the switch learns the MAC of the | ||
| device. When the MAC address is known, pfsetvlan checks its status (existing? | ||
| registered ?, any violations ?) in the database and puts the port in the | ||
| appropriate VLAN. When a device is unplugged, the switch sends a LinkDown | ||
| trap to PacketFence which puts the port into the MAC detection VLAN. | ||
|
|
||
| IMPORTANT: | ||
| When a computer boots, the initialization of the NIC generates several link | ||
| status changes. And every time the switch sends a linkup and a linkdown trap to | ||
| PacketFence. Since PacketFence has to act on each of these trap, this generates | ||
| unfortunately some unnecessary load on pfsetvlan. In order to optimize the trap | ||
| treatment, PacketFence stops every thread for a LinkUp trap when it receives a | ||
| LinkDown trap on the same port. But using only LinkUp/LinkDown traps is not the | ||
| most scalable option. For example in case of power failure, if hundreds of | ||
| computers boot at the same time, PacketFence would receive a lot of traps almost | ||
| instantly and this could result in network connection latency… | ||
|
|
||
|
|
||
| MAC notification traps | ||
| ---------------------- | ||
|
|
||
| If your switches support MAC notification traps (MAC learnt, MAC removed), we | ||
| suggest that you activate them in addition to the LinkUp/LinkDown traps. This | ||
| way, pfsetvlan does not need, after a link up trap, to query the switch | ||
| continuously until the MAC has finally been learned. When it receives a LinkUp | ||
| trap for a port on which MAC notification traps are also enabled, it only needs | ||
| to put the port in the MAC detection VLAN and can than free the thread. When the | ||
| switch learns the MAC address of the device it sends a MAC learnt trap | ||
| (containing the MAC address) to PacketFence. | ||
|
|
||
|
|
||
| Port Security traps | ||
| ------------------- | ||
|
|
||
| In its most basic form, the Port Security feature remembers the MAC address | ||
| connected to the switch port and allows only that MAC address to communicate on | ||
| that port. If any other MAC address tries to communicate through the port, port | ||
| security will not allow it and send a port-security trap. | ||
|
|
||
| If your switches support this feature, we strongly recommend to use it rather | ||
| than LinkUp/LinkDown and/or MAC notifications. Why ? Because as long as a MAC | ||
| address is authorized on a port and is the only one connected, the switch will | ||
| send no trap whether the device reboots, plugs in or unplugs. This drastically | ||
| reduces the SNMP interactions between the switches and PacketFence. | ||
|
|
||
| NOTE: | ||
| When you enable port security traps you should not enable LinkUp/LinkDown nor | ||
| MAC notification traps. | ||
|
|
||
|
|
||
| 802.1X | ||
| ------ | ||
|
|
||
| 802.1X provides port-based authentication, which involves communications between | ||
| a supplicant, authenticator, and authentication server. The supplicant is often | ||
| software on a client device, such as a laptop, the authenticator is a wired | ||
| Ethernet switch or wireless access point, and an authentication server is | ||
| generally a RADIUS database. | ||
| The supplicant (i.e., client device) is not allowed access through the | ||
| authenticator to the network until the supplicant’s identity is authorized. | ||
| With 802.1X port-based authentication, the supplicant provides credentials, such | ||
| as user name / password or digital certificate, to the authenticator, and the | ||
| authenticator forwards the credentials to the authentication server for | ||
| verification. If the credentials are valid (in the authentication server | ||
| database), the supplicant (client device) is allowed to access the network. | ||
|
|
||
| ================================== | ||
| Hardware apparently not supported? | ||
| ================================== | ||
|
|
||
| Your network hardware is not on these lists? Chances are that it works with a | ||
| similar module already. Try this first and if it does work, let us know what | ||
| module you used on what hardware and your firmware version. You can | ||
| communicate that information to us by filing a ticket in our bug tracking | ||
| system under the category 'hardware modules': | ||
|
|
||
| http://www.packetfence.org/bugs/bug_report_page.php | ||
|
|
||
| Otherwise, we are always interested in adding new hardware support into | ||
| PacketFence. Please contact us at info@inverse.ca or via our web form: | ||
|
|
||
| http://www.inverse.ca/english/about/contact.html#c1538 | ||
| For a technical introduction on how PacketFence interacts with the equipment, please | ||
| refer to http://www.packetfence.org/about/technical_introduction.html |