Wireless Network Security in pfSense

Wireless Network SecurityIn addition to strong encryption from WPA or WPA2 with AES, some users like to employ an additional layer of encryption and authentication before allowing access to network resources. The two most commonly deployed solutions used to ensure wireless network security are captive portal and VPN. These methods may be used whether you use an external access point or use an optional (OPT) interface or an internal wireless card as your access point.

Wireless Network Security: Captive Portal

By enabling captive portal on the interface where your wireless is, you can require authentication before users can access network resources, thus providing an additional layer of wireless network security. In corporate networks, this is often deployed with RADIUS authentication to Microsoft Active Directory so users can use their Active Directory credentials to authenticate while on the wireless network. I covered captive portal configuration in two separate installments: part one and part two.

Wireless Network Security: VPN

Wireless Network Security

Firewall rules for IPsec VPN. “WLAN net” is the network of the wireless interface, and “Wireless IP” is the IP address of the wireless interface. The rules are slightly different for OpenVPN and PPTP.

Adding captive portal provides another layer of authentication, but it does not offer any additional protection from eavesdropping of your wireless traffic. Requiring VPN before allowing access to the internal network and Internet adds yet another layer of authentication as well as an additional layer of encryption for your wireless traffic, and thus improving wireless network security. The configuration for your chosen type of VPN will be no different from a remote access configuration, but you will also need to configure the firewall rules on the pfSense interface to allow only VPN traffic from your wireless clients.

If you choose to allow only IPsec VPN traffic, you need to set up three rules on you wireless interface. Navigate to Rules -> Firewall, and click on the tab for the wireless interface. Press “plus” to add a new rule. For “Protocol”, select ICMP. For “Source”, select the wireless network; for “Destination”, select the wireless interface IP address. Enter a “Description” and leave the other settings unchanged. Press “Save” to save this rule. Press “plus” to create another rule, and keep the wireless network as the source and the wireless interface IP as the destination. Change the “Prototype” to UDP, and set the destination “Port” to 500. Add a description and press “Save” to save the rule. Press “plus” to create a third rule, and again keep the source as the wireless network and the destination as the wireless interface. Do not set a port and set the prototype to ESP. Then press “Save” to save the rule and on the next page press “Apply changes” to apply the changes.

If you want to use OpenVPN instead, keep the ICMP rule the same, but set the port for the UDP rule to 1194. You do not need a rule to pass ESP traffic. If you want to use PPTP, keep the ICMP rule, add a rule to pass TCP traffic on port 1723, and add another rule to pass GRE traffic on all ports. You do not need a rule to pass UDP or ESP traffic.

External Links:

pfSense OpenVPN Tutorial at YouTube

Secure Your Public WiFi Usage with pfSense IPsec Tunnels at Mostly Secure

Ad Links:

Wireless Access Point Configuration in pfSense

wireless access pointWith a wireless card that supports hostap mode, pfSense can be configured as a wireless access point. The following cards support hostap mode:

  • ath(4): Supports cards based on the Atheros AR5210, AR5211 and AR5212 chipsets.
  • ral(4): Ralink Technology wireless network driver – supports cards based on the Ralink RT2500, RT2501 and RT2600 chipsets.
  • wi(4): Supports cards based on Lucent Hermes, Intersil PRISM-II, Intersil PRISM-2.5, Intersil Prism-3, and Symblo Spectrum24 chipsets. These cards support only 802.11b.

In the past, the access point functionality in FreeBSD has suffered from serious compatibility problems with some wireless clients. With FreeBSD 7.0 and newer, this has improved significantly; however there may still be some incompatible devices. These difficulties with client compatibility are not necessarily just a FreeBSD issue. Nevertheless, you may find that a cheap consumer-grade wireless router running in access point mode may provide better compatibility than FreeBSD’s access point capabilities. There is the possibility of finding incompatible devices with any wireless access point, and FreeBSD is no exception. With every passing release of FreeBSD, wireless compatibility improves; however, it’s probably a good idea to check the ap compatibility list at pfsense.org.

As long as your wireless cards are compatible, configuring pfSense to act as a wireless access point is fairly easy. Many of the options should be familiar if you have configured other wireless routers before, and some options may be new unless you have used some commercial-grade wireless equipment. There are many different ways to configure access points. In this article, we will cover setting up pfSense as a basic wireless access point (AP) that uses WPA2 encryption.

Configuring pfSense as a Wireless Access Point

First, ensure that the wireless card is in the router, and the antenna is firmly attached. The wireless card must be assigned as an OPT interface and enabled before the remaining configuration can be completed. You need to navigate to Interfaces -> OPTn to begin configuration. Naming the access point “WLAN” (Wireless LAN) or “Wireless” will make it easy to identify a wireless interface in the list of interfaces. If you have a unique SSID, it may be a good idea to use that in the description instead. If pfSense will be driving multiple access points, there should be some way to distinguish them.

Next, since this will be a wireless access point on a dedicated IP subnet, you will need to set the “Type” to “Static” and specify an “IP Address”and subnet mask. Since this is a separate subnet from the other interfaces, it can be any subnet that is otherwise unused. For purposes of this example, assume our subnet is 192.168.10.x.

You need to set the “Wireless Standard” setting, and there are several choices, including 802.11b, 802.11g, 802.11g turbo, 802.11a, and possibly others. Here, assume we choose 802.11g. Set the “Mode” field to “Access Point”, and pfSense will use hostapd to act as an AP. Next you need to set the Service Set Identifier (SSID); this will be the name of the AP as seen by clients. This should be something readily identifiable, yet unique to your setup.

Another setting is “802.11 only”. This setting controls whether or not 802.11b clients are able to associate with this access point. Allowing 802.11b clients to use your wireless access point may be necessary in some environments if devices are still around that require it. Some devices such as the Nintendo DS are only compatible with 802.11b and require a mixed network in order to work. The down side of this is that you will see slower speeds as a result of allowing such devices on your network, as the access point will have to cater to the lowest common denominator when an 802.11b device is present.

Next, there is “Allow intra-BSS communication”. If you check this option, wireless clients will be able to see each other directly, instead of routing all traffic through the AP. If clients will only need access to the Internet, it is usually safer to uncheck this.

There is an option to “Disable SSID Broadcasting”. Normally, the AP will broadcast its SSID so that clients can locate and associate with it easily. However, this is considered by many network admins to be a security risk, as you are announcing to all who are listening that you have a wireless network available. In most cases the convenience outweighs the security risk. At the same time, the benefits of disabling SSID broadcasting are overblown, since it does not actually hide the network from anyone capable of using many freely available wireless security tools that easily find such wireless networks.

Next is “Wireless Channel Selection”. When selecting a channel, you want to be aware of any nearby radio transmitters in similar frequency bands. In addition to wireless access points, there are also cordless phones, Bluetooth, baby monitors, video transmitters, microwaves, and many other devices that use the same 2.4 GHz spectrum that can cause interference. The safest channel to use are 1, 6, and 11 since their frequency bands do not overlap each other. You can specify “Auto” to tell the card to pick an appropriate channel, but this does not work with all wireless cards.

Three types of encryption are supported for 802.11 networks: WEP, WPA, and WPA2. WPA2 with AES is considered the most secure. Even if you are not worried about encrypting the over-the-air traffic, it provides an additional means of access control. A WPA/WPA2 passphrase is also easier to work with and remember than a WEB key; it acts more like a password than a really long string of hexadecimal characters. Some older devices only support WEP or WPA, but most modern wireless cards and drivers will support WPA2. To enable WPA2, you need to uncheck “Enable WEP” and check “Enable WPA”, and set the “WPA Mode” to WPA2. To use WPA2+AES, set “WPA Pairwise” to AES.

This should be enough to get a wireless access point running with 802.11g with WPA2 + AES encryption. There are other settings you can use to tweak the AP’s behavior, but under most circumstances they are not necessary. Press the “Save” button to save the settings and on the next page press the “Apply Changes” button. Now your wireless access point should be up and running.

External Links:

One pfSense wireless config to rule them all at www.interspective.net

Ad Links:

Wireless Support in pfSense

wirelessFirst, I should mention that this is the 100th post on this blog, which if nothing else, shows an unusual (for me) level of persistance on my part. Thanks to all who have visited this blog, visited this site’s Facebook page, or subscribed to this blog’s Twitter feed. I have a number of ideas on how to improve this blog, and I hope to implement some of them in the near future. Now, onto the topic of today’s posting: wireless support in pfSense.

pfSense includes built-in wireless capabilities that allow you to either turn your pfSense box into a wireless access point, use a wireless 802.11 connection as a WAN connection, or both. You can also use another wireless router in conjunction with pfSense. But if you want to use the built-in wireless capabilties, you first need one or more wireless cards supported by pfSense.

FreeBSD has supported wireless cards for a number of years, and there are a variety of wireless cards supported in FreeBSD 8.3. Needless to say, pfSense includes support for every card supported by FreeBSD, although some are supported better than others. Most pfSense developers work with Atheros hardware, so it tends to be the most recommended hardware. Many users have had success with other cards, however, and Ralink is also a popular choice. Other cards may be supported, but do not support all available features. For example, some Intel cards can be used in infrastructure mode but cannot be run in access point mode due to limitations of the hardware itself.

Another factor to take into account is that major wireless card manufacturers commonly change the chipsets used in their wireless cards without changing the model number. As a result, there is no way to ensure a specific model card from these vendors will be compatible, since you have no way of knowing which minor card revision you will end up with. While one revision of a model may be compatible and work, another card of the same model may be incompatible. For this reason, it may be a good idea to avoid cards from major manufacturers such as Linksys, D-Link and Netgear, although if you already have one, it is worth trying to see if it is compatible.

Supported Wireless Drivers

The following drivers are included in pfSense 1.2.1 and newer kernels:

  • ath(4): Supports cards based on the Atheros AR5210, AR5211 and AR5212 chipsets. The following cards are known to work in pfSense:
    • CB9-GP-EXT Cardbus/PCMCIA
    • 5004 MP Atheros 4G
    • DCMA-82 Atheros 6G
    • DCMA-82 Industrial Temp
  • rai(4): Ralink Technology IEEE 802.11 wireless network driver – supports cards based on the Ralink Technology RT2500, RT2501 and RT2600 chipsets. There are too many cards supported to list, but the FreeBSD man page for ral has a list of supported cards.
  • wi(4): Lucent Hermes, Intersil PRISM and Spectrum24’s IEEE702.11 driver supports cards based on the Lucent Hermes, Intersil PRISM-II, Intersil PRISM-2.5, Intersil, Prism-3, and Symbol Spectrum24 chipsets. These cards support only 802.11b, and a list of cards supported can be found at the FreeBSD man mage for wi.
  • an(4): Aironet Communications 4500/4800 wireless network adapter driver supports Aironet Communications wireless network adapters and variants, such as:
    • Aironet Communications 4500 and 4800 series
    • Cisco Aironet 340 and 350 series
    • Xircom Wireless Ethernet Adapter
  • awi(4): AMD PCnetMobile IEEE 802.11 PCMCIA wireless network drive – supports cards based on the AMD 70c930 controller with Intersil PRISM radio chipset, such as:
    • BayStack 650
    • BayStack 660
    • Icom SL-200
    • Melco WLI-PCM
    • NEL SSMagic
    • Netwave AirSurfer Plus
    • Netwave AirSurfer Pro
    • Nokia C020 WLAN
    • Farallon SkyLINE

With the release of pfSense 2.0, even more wireless cards were supported. Again, the list is too large to include here, but there is a spreadsheet of compatible wireless cards that should work with 2.0. Be aware of the “hostap” column, which shows drivers capable of running in wireless access point mode. If that column is marked “N”, then the card could only be used as a client. The second tab on the sheet lists part numbers for a given driver.

In the next article in this series, I will cover how to configure your wireless card.

External Links:

Supported Wireless Cards at doc.pfsense.org

Ad Links:

© 2013 David Zientara. All rights reserved. Privacy Policy