1.
Wireless Access Points
May 2015 Hangout
Jim Pingle

2.
Project Notes
● pfSense 2.3 is progressing
– Conversion from PBI to pkg
– FreeBSD 10.2-RELEASE
– Bootstrap GUI
– Intel QuickAssist for SG series hardware purchased from the pfSense store
● Crypto acceleration in addition to AES-NI (AES, DES, SHA, MD5, AES-GCM)
– Target is a release later this year
● SG-8860 now shipping
– Desktop form factor C2758
– 8 core, 8GB RAM, 6x Intel 1Gb network ports, 64GB eMMC
● SG-2220 expected to begin shipping July 31
● Few slots open in June classes
– Classes will be on hold and revised during the summer, so get in now!
● Still investigating new Hangout hosting options

3.
About this Hangout
● Wireless Access Point Setup on pfSense
– Skipping many technical details of wireless in general, focusing
on pfSense specifically
● Multi-BSS (VAPs)
● Using an external access point
● Routed wireless segment
● Bridged wireless segment
● Rules for isolating users on a segment
● DNS control/redirection

4.
State of Wireless on pfSense
● Much improved over previous releases
● 802.11n is possible now with specific hardware, such as certain
Atheros cards
● No 802.11ac support at this time
● 802.11n capable Mini-PCIe kit (card, pigtails, antennas) for
RCC/SG/APU devices – http://store.netgate.com/APU-wireless.aspx
● Many other cards are supported, check the wiki/docs/forum
● We still generally recommend an external AP
– Better signal farther from network gear/rack
– Other gear may have more recent wireless support, central management
– Example: Ubiquity UniFi Access Points

5.
Before you start...
● Plan the type of deployment
– Routed segment (Best!)
– Bridged segment
● Simple bridge LAN/Wireless (meh)
● Assigned bridge interface (better)
● Pick a channel
– This is very oversimplified but gets the general idea across
– Use a survey tool such as NetSurveyor, InSSIDer, or one of many other similar
apps, tools, etc. Plenty of them for various operating systems, phones, tablets, etc
– With 802.11g and before, channels 1, 6 and 11 did not overlap. Same is not
always true with 802.11n, so don't count on that
– These tools do not generally detect other non-Wi-Fi interference on the same or
surrounding frequencies, which can also be common
– When in doubt, if the signal from the AP is weak, try another channel, may also
need better antennas

6.
Assigning the Interface
● Navigate to Interfaces > (assign)
● Select the wireless interface (e.g. ath0) from
the list and click +
● The interface will be added to the list as an
OPT interface, e.g. OPT1
● To configure the interface, visit its page under
the Interfaces menu, e.g. Interfaces > OPT1

7.
Multi-BSS (VAPs)
● Simply: The ability to have one wireless card perform multiple roles
● May be multiple access points, multiple clients, or a mix (depending on driver/card support)
– Most common example: Multiple SSIDs on the same card
● No theoretical limit on VAPs, but commonly limited to 4 by some drivers/cards
– Often can't predetermine limit until you try and it fails or panics
● Patent has familiar names! http://www.google.com/patents/US6732176
● All VAPs on a given card share some settings, such as the radio configuration (channel, regulatory
settings, antenna settings, standard)
● To create a VAP:
– First assign the “main” wireless interface
– Visit Interfaces > (assign), Wireless tab
– Click + to create a new VAP
– Choose the mode (such as Access Point)
– Add a description
– Save
– Assign the interface as before, it can have its own unique subnet/security/rules/etc

8.
Configuring the Interface
● Navigate to the interface configuration page
(Interfaces > OPTx)
● Check Enable
● Change the Description to something
noteworthy, such as “Wireless” or “GuestWiFi”
● Configure a static IP address for the interface
● Do not set a gateway

9.
Common Wireless Settings
●
These settings are common for a given wireless card, no matter which VAP is being configured
●
“Persist Common Settings” keeps these values even if all wireless interfaces for this card are
removed
●
Standard – Wireless standard such as 802.11ng, na, g, etc. List changes depending on what
the installed card and driver support
●
OFDM Protection Mode – Used for mixed B/G networks, these days can usually be left off
●
Channel – Pick a channel that isn't too busy, but it MUST be set!
– Do NOT leave on Auto when running an Access Point!
– List varies depending on the channels supported by the card
●
Antenna Settings – If multiple antenna connectors are present, the transmit and receive
antenna may be set manually. Typically left at default
●
Distance Setting – Used to tune ACK/CTS timers, typically left blank but may be set as a
distance to the client in meters
● Regulatory Settings (domain, country, location) – May be left at default but typically best to set.
In the US this is FCC, United States – (US, FCC), and then the location, typically Indoor

10.
Network-Specific Wireless Config
● Unique for each interface/VAP
● Mode – Access Point, Client: Infrastructure (BSS), Ad-Hoc (IBSS)
– For the primary wireless interface, it can be changed here. For VAPs, it must match the
mode of the VAP
● Minimum wireless standard – use to keep older clients off the network
● Allow intra-BSS communication – Lets connected clients talk to each other,
otherwise they are isolated
– This is a common need for things like wireless printers, Chromecast and similar devices
● Enable WME – Wireless Multimedia Extensions, wireless QoS
– Required for 802.11n!
● Hide SSID – Security by obscurity
– May not help as much as people think, the name can still be broadcast
– Some clients have problems
– Some still insist on using it, but it won't fool a determined malicious client

11.
Network-specific config (cont'd)
●
WEP (“Wired Equivalent Privacy”)– No excuse for using this in modern times
– Only ancient clients may need it. It offers no security currently.
●
WPA (“Wi-Fi Protected Access”) – Most common type of wireless security config. Enter a
PSK between 8 and 63 chars
●
WPA Mode – Should almost always be WPA2
●
WPA Key Management Mode – PSK, EAP, or both, depends on the remainder of the config.
– EAP typically used with 802.1x (WPA2 Enterprise), PSK for regular WPA2.
●
Authentication – Typically left at Open System Authentication unless WEP is used
●
WPA Pairwise – AES, TKIP, or Both. AES only is preferred.
– TKIP is no longer considered secure
●
Key Rotation – Time, in seconds, between GTK rotations.
– Shorter is better but can also slow down if done too often typically 60 seconds
●
Master Key Regeneration – Time, in seconds, between GMK regeneration, typically 3600
●
Strict Key Regeneration – Forces a rekey when a client disassociates. More secure, but if
there is lots of churn it may force rekeys too often

12.
802.1x (aka WPA2 Enterprise)
● Most secure option, but requires a RADIUS backend
● Can be backed by FreeRADIUS package on pfSense
● Two RADIUS servers may be configured, primary and a backup
● RADIUS server must be configured to accept access requests
from the firewall
● Any options for EAP and similar must be set on RADIUS server
and clients set to match!
● Be sure to set WPA Key Management drop-down to EAP
● Check the box to enable 802.11x, enter RADIUS server IP
address, authentication port, and shared secret

13.
Using an External Access Point
● Most wireless routers can be used as an access point instead if no true AP is available
● Common technique for many devices including *WRT/Tomato and similar
● Configure the wireless router (hereafter: AP) with a Local/LAN address in the same
subnet as the target network
– This must be different from the IP address on the firewall, and will be used for managing the AP
● Turn off DHCP on the AP
● Connect a cable from the SWITCH or LAN side of the AP to the interface on the firewall
that will handle its traffic, or plug it directly into the local switch if joining it to your
existing LAN
● Do NOT use the Internet/WAN port on the AP if it has one, unless the OS on the AP
can be configured to bridge that port to the LAN instead. This can be done with some
third-party firmware options
● Wireless clients will associate with the AP and then communicate with the LAN as
expected
● Can be connected to a separate interface/subnet on the firewall for better isolation

14.
Network Style
● Interface on its own separate subnet (preferred!)
– Most reliable
– Most secure
– Technically simpler
– Can be troublesome for broadcast/multicast protocols (“Browsing the network”, DLNA, mDNS,
some printers)
– No problems with transparent proxy, limiters, captive portal, or other options
● Interface bridged to LAN or other local network
– Conceptually simpler
– “Easier” for some protocols
– Same Layer 2 shared between wired and wireless
– Bridging can be quirky
– Less secure, can't filter L2
– Broadcast and multicast will be spread across all interfaces (which is sort of the point, but should
be noted nonetheless)
– Makes some tasks more difficult such as transparent proxy, limiters, captive portal, etc
– Needs care with rules, especially policy routing and use of macros, allowing DHCP, and others

15.
Wireless on a Separate Subnet
● Assign and configure the wireless interface, using a
unique/separate/non-overlapping subnet
● Configure DHCP on the interface (optional, but recommended)
● Configure firewall rules to allow the clients to reach the desired
destinations
– See later info for a more in-depth discussion on isolation rules
● If using manual outbound NAT, ensure the interface subnet is
included in outbound NAT rules
● Ensure any customized services are also set for the interface if
needed (DNS, UPnP, proxy, etc)
● That's all!

16.
Simple Bridge
●
Easy, but limited (no limiters, no CP, no proxy, other potential issues)
●
IP address stays on the wired LAN interface
●
If the wired LAN interface is unplugged, the wireless interface and any other bridge members
will not function
●
Assign and configure wireless
– Enable, enter a name, Leave the IP types set to None
●
Under System > Advanced on the System Tunables tab, ensure the bridge filtering sysctls
are set to filter on the members, NOT the bridge! (This is the default)
●
Create a bridge including the wireless and LAN interfaces
– Interfaces > (assign), Bridges tab
– Click +
– Select LAN and Wireless
– Save
● Add firewall rules to the Wireless interface
– Do NOT use “Wireless net” or similar macros, this interface has no subnet thus the macro is meaningless
– Pass from a source of “any”, or pass from the subnet specifically and add custom rules to pass DHCP
(UDP, source 0.0.0.0 67-68, dest 255.255.255.255 67-68)

17.
Assigned Bridge
● If a bridge must be used, this is the better way
● All members end up on a common Layer 2, but without the
previously mentioned limitations
● LAN will end up as bridge0, wired/wireless bridge members
as interfaces with no IP address
– IP Address bound to the bridge interface allows all member
interfaces to function independently. If they are up or down they do
not affect others.
– Also allows limiters, CP, proxy, and other functions to work properly
– DHCP and other services will be bound to the bridge as well, rather
than member interfaces

18.
Assigned Bridge Procedure
● Assign and configure the wireless interface
– Set the IP types to None
● If other OPT interfaces will be members of the bridge, configure them the
same way
● Create a new bridge including only the wireless and other member interfaces
– Do NOT include LAN yet!
● Add firewall rules to the bridge member interfaces if filtering will ultimately be
performed there
– As with the other scenario do NOT use “Wireless net” or similar macros
● If filtering will happen on the bridge instead, change the bridge filtering
System Tunable to NOT filter on member interfaces
– net.link.bridge.pfil_member=0

19.
Assigned Bridge Procedure (cont'd)
● If these changes are being made from LAN, at this time I recommend moving the client to another
local interface or connect via WAN to manage, LAN will be disrupted next
– Once LAN has been reassigned to the bridge, you should be able to connect there and manage the firewall
but having a backup plan is best!
● Navigate to Interfaces > (assign)
● Change the assignment of LAN to the bridge (e.g. bridge0) and click Save
– Here is where you need to relocate the client if you were managing from LAN!
● Assign the old LAN as a new OPT interface
● Enable the new interface and give it a name (e.g. “WIREDLAN”)
– Set IP type = None!
● Add this interface to the bridge
● If filtering on member interfaces, add rules to this new interface
● If filtering on the bridge, the System Tunable may now be set to filter on the bridge interface
– net.link.bridge.pfil_bridge=1
● Now the former LAN interface, wireless, and all other bridge members are on a common Layer 2
with the bridge itself handling the IP address.

20.
Isolating via Firewall Rules
●
To isolate a segment, it must pass only what is required
– Typically they must also reach the Internet
– This requires some compromise
● Easiest start: RFC1918 alias
– 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
● Pass ping, DNS, and other firewall-hosted services from the subnet to the firewall or
desired target server
● Reject all traffic to RFC1918 destinations to prevent clients from reaching other local
private networks or VPNs. Also add any other non-RFC1918 networks that need
protected.
– Reject offers a better user experience for local traffic as the user will be immediately notified of
the problem rather than having to wait for a timeout
– Blocking to all RFC1918 makes it simpler in the long run in case more subnets are added
locally or via VPN, no need to go back and add rules in more places.
● After blocking or rejecting places they should not be able to reach, pass to a
destination of “any” so that Internet access functions

21.
Limiting or Capturing DNS Traffic
● Two tactics, limit or capture
● Limit users to contact only authorized DNS servers
– Pass from clients to the desired DNS servers, reject to any other
destination using tcp/udp port 53
– Clients attempting to use other DNS servers will receive no DNS responses
● Capture DNS requests
– Use a port forward on the local interface to intercept DNS traffic and force it
to the DNS server of your choice
●
For LAN/DNS Forwarder: Interface=LAN, Proto=TCP/UDP, Source=any,
Destination=! (NOT) LAN address, Dest port = 53, NAT IP = 127.0.0.1 port 53
– Clients attempting to use other DNS servers will receive responses from
your DNS server instead

22.
Wireless Status
● Status > Wireless
● One tab per VAP
● Click Rescan to show a list of nearby access
points and Ad-Hoc peers
● List of associated clients is presented
● Flags are explained at
https://doc.pfsense.org/index.php/Wireless_Status
● Logs at Status > System Logs, General, Wireless

23.
Conclusion
● Questions?
● Ideas for hangout topics? Post on forum,
comment on the blog posts, Reddit, etc