The purpose of this document is to describe the implementation of a WiFi Access Point using Zeroshell on a system with a WiFi network card containing an Atheros chipset. The document is subdivided into the following sections:
- Why implement a Wireless Access Point with Linux Kernel modules from the MadWifi project?
- Manage wireless interfaces and Multi SSID with the wifi-manager
- Map the Wireless LAN on the VLAN with tags
- Extend the Wireless geographically through OpenVPN
Thanks to the use of the MadWifi modules by the Linux kernel, it is possible to implement a Wireless Access Point with a Personal Computer or an Embedded Device that has a WiFi network card (PCI or MiniPCI) with an Atheros chipset. This feature is available starting with version 1.0.beta8 of Zeroshell, which introduces WiFi support in either AP (Access Point) or STA mode (in which a Zeroshell router/bridge can be associated as a client in a Wireless LAN).
The option to use the MadWifi drivers, combined with the use of wpa_supplicant and hostapd packages, is due to their ability to perform the functions of an AccessPoint with advanced features, for example:
- Access authentication and wireless traffic encryption through WPA/WPA2 (RSN). It is supported either in WPA-PSK mode, in which the client, in order to be associated to an SSID, must know the Pre-Shared Key, or WPA-EAP mode, also known as WPA Enterprise, in which a user can become authenticated with Username and Password or a X.509 digital certificate validated by a Radius server. Both the TKIP encryption algorithm and the more secure CCMP, based on AES, are supported;
- Management of the Multiple SSID mode (also called Virtual SSID), thanks to which it is possible to create up to 4 virtual standalone Access Points for each WiFi network card in the system. It is clear that virtual SSIDs belonging to the same WiFi network card share the radio channel being used, and thus the available bandwidth. Moreover, for each virtual SSID it is possible to establish a standalone authentication and encryption scheme (plain-text, WPA-PSK, WPA Enterprise or WEP at 128 bits).
Of the four possible SSIDs one can also work in Managed mode and associate to a WLAN as a client. For example, this is useful to extend the range of the Wireless network itself by implementing repeaters that work in WDS (Wireless Distribution System) but do not need to be interconnected by means of a Wired network.
- Compatibility with network channels in the 5GHz (802.11a) band and the 2.4GHz (802.11b and 802.11g) band. In particular, in case the 802.11g mode is selected, compatibility is guaranteed for older clients that only have 802.11b.
Zeroshell identifies each virtual SSID as if it were an Ethernet interface (ETHnn). It allows operating on Wi-Fi networks, using a web interface, as well as wired interfaces. In other words, on the SSID it is possible:
- To add IP addresses, do static routing and enable the RIP v2 protocol to acquire and propagate dynamic routes;
- Apply QoS classes to do traffic shaping by assigning different priority levels, maximum and guaranteed bandwidth to different types of traffic (VoIP, P2P, SSH, HTTP, …);
- Do bridging with Ethernet interfaces, VLAN 802.1q, VPN LAN-to-LAN or other SSIDs. In particular, the possibility of making a bridge or Layer 2 link with a Virtual SSID that works as a Client with one acting as an Access Point, allowing the so-called WiFi Repeater (or WDS) that extends the coverage area of the WLAN;
- Activate services, including DHCP and Captive Portal and apply traffic filters by means of the Firewall.
- Apply bonding, that is to add two or more interfaces in such a way as to increase bandwidth (load balancing) and reliability (fault tolerance). Naturally, in order to have wireless bonding it is necessary that the Virtual SSIDs that comprise it belong to different WiFi interfaces in order to balance traffic on different radio channels.
Although by using Zeroshell’s web interface (see figure) it is possible to manage the network interfaces representing the SSIDs, operations for the creation and management of the latter regarding wireless parameters like the channel to be used, transmission power in dBm and encryption, all are managed by a script that is called by the shell command wifi-manager from a serial RS232 or VGA console or by a remote SSH session. Below you can see the main menu of the wifi-manager:
root@gw-adsl root> wifi-manager [wifi0] Chipset AR5413 802.11abg NIC (rev 01) -- If -- Mode -- SSID --------------------------- Hide -- Security - >> ETH02 AP WLAN with Captive Portal no Plaintext ETH03 AP WLAN with Pre-Shared Key no WPA-PSK ETH04 AP WLAN with 802.1x Radius Auth. no WPA-EAP ETH05 AP WLAN with WEP no WEP128 [wifi1] Chipset AR5413 802.11abg NIC (rev 01) -- If -- Mode -- SSID --------------------------- Hide -- Security - ETH06 STA wrap-psk no WPA-PSK COMMANDS <N> New SSID <M> Modify SSID <D> Delete SSID <I> Show Information <C> Std/Channel/Tx-Power <L> List Stations <S> Channel Scanning <R> Restarting Devices <Q> Quit >>
As you can see, this illustrative system is made with an ALIX 2C2 Embedded PC with 2 WiFi interfaces with the Atheros AR5413 802.11abg chipset, capable of operating either in 802.11b/g or 802.11a. On the wifi0 wireless interface 4 virtual Access Points sharing the same radio frequency are defined, each with its own authentication and encryption scheme.
- The ETH02 interface corresponds to the WLAN where the SSID is “WLAN with Captive Portal“. No encryption (Plaintext) is defined above it, but the authentication is successively delegated to the Captive Portal;
- The ETH03 interface corresponds to a “WLAN with Pre-Shared Key” SSID with WPA-PSK protection, which can be accessed by knowing the shared key defined during the creation of the SSID. This protection mode, which substitutes WEP, by then quite vulnerable with the capture of a certain number of packets, is considered sufficiently secure if it uses a Preshared Key with adequate size and complexity. Naturally, as with WEP, the administrator must communicate this key to all users who will be able to access the wireless network, and must change it periodically. This is feasible in small setups, like a domestic or SOHO configuration, but it becomes cumbersome when the number of users and Access Points grows;
- The ETH04 interface refers to the virtual Access Point with “WLAN with 802.1x Radius Auth.” SSID where a WPA-EAP encryption scheme has been configured. This kind of protection method is the most secure and flexible, and is thus used in large setups and therefore WPA-EAP is also known as WPA Enterprise. Its flexibility is due to the fact that the encryption keys are not generated by the administrator but automatically by a RADIUS service through 802.1x, which authenticates the user by means of a username and a password (using PEAP with MsCHAPv2 or EAP-TTLS) or by means of an X.509 digital certificate (using EAP-TLS). During the SSID configuration with WPA-EAP, one can choose to use the local Zeroshell RADIUS server or make a reference to an external RADIUS server. In the first case it is not necessary to configure any Shared Secret, whereas in the second case using an external RADIUS it is necessary to specify it.
- WEP 128-bit encryption is defined on the last interface. If not strictly necessary due to the existence of old clients that are not compatible with WPA/WPA2, WEP is to be avoided given the low level of protection it guarantees.
On the wifi1 interface only one SSID is defined in client mode. This interface connects to the wireless network called “WRAP-PSK“, protected by a Pre-shared Key. Please note that from one WiFi card can have a maximum of one SSID acting as a client. The other SSIDs must correspond to the Virtual Access Points. Moreover, since all SSIDs belong to the same WiFi card and share the channel, the latter will coincide with the radio channel of the external WLAN. This inevitably means sharing the bandwidth.
Considering the simplicity of the wifi-manager, it is useless to describe now each single command, since its use should be very intuitive. The only notice is with respect to the “Std/Channel/Tx-Power” voice that is activated with the key C from the menu. With this it is possible to implement the standard (802.11a, 802.11b and 802.11g and later, with the new versions of the MadWiFi driver, also for 802.11n, still in in draft), the available high-frequency radio channel for the chosen standard and a transmission power expressed i dBm or mW. In particular, it is necessary to set this last parameter carefully to avoid going over the power limit allowed by the law where they are located.
As already hinted, once the SSIDs are created and configured with the wifi-manager, whether they correspond to Virtual Access Points or client connections, they appear in all and to all as Ethernet (ETHnn) interfaces that can be manipulated through the Zeroshell web interface. In the example illustrated in the figure below, the four wireless Multi SSIDs and the wired ETH00 interface are briged in a single BRIDGE00(ETH00,ETH02,ETH03,ETH04,ETH05) interface.
Doing it, all 4 WLANs, regardless of their access mode (WPA-PSK, WPA-EAP, Captive Portal or WEP), share the same layer 2 of the LAN that is accessible through the Ethernet ETH00 interface. The fact of sharing the Data Link level for several SSID components, it makes possible to use the LAN DHCP server (if existing) or only needs to activate a single DHCP subnet hooked to the bridge interface. Obviously, since the Firewall and QoS classification also act on the bridged interfaces, it is possible to apply independent access and traffic shaping rules for each SSID. For example, it were possible to benefit the users that access through the Enterprise WPA with respect to those that use the Captive Portal, since we have seen that in the latter traffic is not encrypted.
If virtual LANs are defined on LAN switches in the sense their ports are logically regrouped so they appear as belonging to different (virtual) switches, the communication between these switches is possible by means of trunk ports or trunking. Those ports are characterised by belonging simultaneously to more than one VLAN; the packets going through them are to be identified by tags (or VIDs) that identify the source/target VLAN. One of the most widely used trunking protocols is the one defined in the IEEE 802.1q standard, which has a 12-bit tag with a range of valid values from 1 to 4094. What is more, it defines the concept of Native VLAN, that is the VLAN whose packets go through the trunk as normal, untagged Ethernet frames. Native VLANs are also assigned management tasks. The dissemination of this standard has allowed the interoperability between different network device brands and models, even Virtual LANs are present. In particular, the feature of mapping the VLANs into which the LAN is subdivided on different wireless SSIDs is becoming more widespread. This allows homogeneity in the allocation of subnet IPs between the VLANs comprising the LAN and the SSIDs constituting the WLAN. Thanks to Zeroshell’s support of VLAN 802.1q, the management of Multiple SSIDs per single Access Point and the possibility of bridging the interfaces that represent the VLAN with those representing the SSIDs, this is now possible and economical, without having to use a (physical) Access Point for each Virtual LAN that is to be reached via wireless network.
For example, let’s suppose an organisation has its LAN subdivided into 2 VLANs:
- A VLAN to allow access to service hosts and the desktops of the organisation’s permanent personnel. This VLAN, on which no restrictions are defined by the Firewall regarding internal network resources, has VID (VLAN ID) 1220 and must be accessible via wireless through an SSID called “Trusted Network“. Access to this WLAN must be allowed only to those possessing a Smart Card or eToken with a personal X.509 certificate, this through WPA-EAP with RADIUS enabled to respond to EAP-TLS;
- A VLAN to allow the guests with theirs laptops to access Internet, but with some firewall rules that limit the access to the internal network resources. Such VLAN, whose VID is established as 2350, is also via wireless with an unencrypted SSID called “Guest Network“. Although traffic travels unencoded on this WLAN, access authentication is requested from the Captive Portal to which access is granted through a username and temporary password given to the guests. The choice of using the Captive Portal for this VLAN is motivated by the simplicity of access, which does not constrain the guests to configure their WiFi supplicant to request access to the WPA Enterprise. This last operation is not always immediate and/or readily supported by all operating systems, whereas the Captive Portal provides access regardless of the system type as long as it has a web browser.
As illustrated below, two virtual SSIDs are created through the wifi-manager: “Trusted Network” corresponds to the Ethernet ETH02 interface, and has WPA Enterprise active; “Guest Network” corresponds to ETH03 instead. Even though the hardware we are using possesses 2 WiFi network cards (wifi0 and wifi1), it was decided to create both SSIDs on wifi0. This would save a radio channel, which is a precious resource when using 802.11b/g, since there are only three channels without frequency overlapping (1,6 and 11).
root@multi-AP root> wifi-manager [wifi0] Chipset AR5413 802.11abg NIC (rev 01) -- If -- Mode -- SSID --------------------------- Hide -- Security - >> ETH02 AP Trusted Network no WPA-EAP ETH03 AP Guest Network no Plaintext [wifi1] Chipset AR5413 802.11abg NIC (rev 01) -- If -- Mode -- SSID --------------------------- Hide -- Security - COMMANDS <N> New SSID <M> Modify SSID <D> Delete SSID <I> Show Information <C> Std/Channel/Tx-Power <L> List Stations <S> Channel Scanning <R> Restarting Devices <Q> Quit >>
Now, let’s suppose that the Ethernet ETH00 interface is connected to a switch on a trunking port through which the two VLANs are carried with tags 1220 and 2350 in addition to the native VLAN: using the button [Create VLAN] we add the aforementioned Virtual LAN. Once this is done, we create two bridges by pressing [Make BRIDGE]: BRIDGE00 must connect ETH00.1220 (VLAN 1220) with ETH02 (SSID “Trusted Network“) in layer 2, while BRIDGE01 must connect ETH00.2350 (VLAN 2350) with ETH03 (SSID “Guest Network“). Everything is illustrated in the figure below:
You may notice that it is not strictly necessary to allocate an IP address to both bridges, whereas the ETH00 interface, which corresponds to the Native VLAN, is assigned IP address 192.168.0.75, connecting to it to execute Zeroshell’s management options.
Here, to complete this task, it is enough to activate the Captive Portal from session [Captive Portal]->[Gateway] on interface ETH03 (SSID “Guest Network“) in Bridge Mode.
Zeroshell uses OpenVPN with Tap (virtual Ethernet) devices as a Site-to-Site VPN solution. This offers advantages over protocols like IPsec in the sense it allows connecting organisation sites that are geographically distant using layer 2. In fact, since the Tap interface (Zeroshell calls it VPNnn) is very similar to the Ethernet interface (ETHnn), the VPNs can be bridged with the latter and also with wireless SSIDs. Thus, since there are no routing processes between the LAN and the WLAN, whether local or remote connected via VPN, the same IP subnet can be used everywhere. Therefore, not only a single DHCP server can be used to distribute the same IP address to each client, regardless of the site and connection type (Wired or Wireless), but protocols like NetBIOS, used to share Windows resources like printers and folders, can operate without having to use a WINS server in order to discover network resources, since broadcast traffic is uniformly propagated on the LAN and WLAN (local and remote).
Always thanks to the similarity between the VPNs made with OpenVPN and actual Ethernet connections, it is possible to generalise the previous example by transporting 802.1q VLANs in remote sites as well, extending them via wireless by bridging the interfaces that represent the VLAN transported by the VPN (in the previous example they are VPN00.1220 and VPN00.2350) with “Trusted Network” and “Guest Network” SSIDs.