How to Set Up Guest Wi-Fi 101 - Aerohive Boundless
This is the first in a series on setting up a guest WLAN.
Many studies have shown that providing wireless LAN (WLAN) guest access is beneficial to your business.
- Improved Productivity: Customers and contractors often need access to the Internet to accomplish job-related duties. If customers and contractors are more productive, your company employees will also be more productive.
- Customer Loyalty: In today’s world, business customers have come to expect Guest WLAN access. Free guest access is often considered a value-added service. There is a good chance that your customers will move towards your competitors if you do not provide WLAN guest access.
Guest user traffic should always be segmented from employee user traffic. Four guest WLAN best practices include:
- Guest SSID: Wireless guest users should always connect to a separate guest SSID because it will have different security policies than a corporate or employee SSID.
- Guest VLAN: Guest user traffic should be segmented into a unique VLAN tied to an IP subnet that does not mix with the employee user VLANs.
- Captive Web Portal: A captive web portal can be used to accept guest login credentials. More importantly, the captive web portal should have a legal disclaimer.
- Guest Firewall Policy: A From-Access guest firewall policy is the most important component of WLAN guest management.
A From-Access guest firewall policy is by far the most important component of WLAN guest management. The goal is to keep wireless guest users away from corporate network resources and only allow them access to a gateway to the Internet, which is especially important if you do not configure a separate VLAN for guest users. Figure 1 shows an example of the default Guest Firewall Policy in HiveManager.
The guest firewall policy can be much more restrictive. A good practice is to block SMTP so users cannot SPAM through the guest WLAN. If necessary, many more ports and/or applications can be blocked. Ports that should be permitted include DNS/UDP port 53, DHCP-server/UDP port 67, HTTP/TCP port 80 and HTTPS/TCP port 443. So that guest users are capable of using an IPsec VPN when connected to the guest wireless network, IKE/UDP port 500 and IPsec NAT-T/UDP port 4500 should be also permitted.
The firewall is built into every Aerohive access point; therefore the guest user traffic firewall policies are always enforced at the edge of the network.
As shown in Figure 2, Aerohive Networks application visibility and control also gives you the ability to permit or block access to Layer 7 applications at the user level.
Guest users should always be prevented from peer-to-peer connectivity on the guest VLAN/subnet. This prevents your guest users from attacking each other while they are connected to the same guest WLAN. Peer-to-Peer blocking can be configured in the Guest SSID Profile settings: Optional Settings > DoS Prevention and Filter >Traffic Filter. As shown in Figure2, all you need to do is uncheck: Enable Inter-station Traffic.
Another good idea is to always rate limit the bandwidth for the guest WLAN. No senses in allowing your guest users to operate as bandwidth hogs. Guest traffic can be throttled with a rate control policy. Bandwidth throttling can be configured in User Profiles > Optional Settings > QoS Settings > Rate Control and Queuing Policy. Figure 4 depicts a good guest rate control policy that limits your guest users to 1 Mbps.
All guest WLANs should have a captive web portal login pages. Captive web portals may be linked to a backend RADIUS server for authentication purposes, users might self-register via a captive web portal login page, or maybe only a simple use-policy acceptance page is required. The legal disclaimer is one of the main reasons for a captive web portal login page. Guest users need to promise to behave themselves when using your guest WLAN and furthermore they should understand that your business is not liable if they somehow get hacked while using your guest network.
As shown in Figure 5, when a guest user browses to a URL, a DNS redirect is used to send the guest user to the captive portal login pages. If a captive portal stops working, there is most likely a DNS problem. If guest user authentication is required, the AP will then query a RADIUS server with an authentication protocol such as MS-CHAPv2.
Aerohive has a large selection of pre-configured captive web portals. The captive web portal pages use cascading style sheets so that they display properly on a computer screen, tablet screen, or smart phone screen. Upon authentication, guests can be redirected to external URL or the initially requested URL.
As shown in Figure 7, the captive web portal pages can be customized within HiveManager. Advanced customization can be done with an external HTML editor and pages can be imported back into the system and then used as templates.
Some examples of the available web portal login pages include user authentication, self-registration, and use-policy acceptance as seen in Figure 8.
Aerohive also offers multiple language support as shown in Figure 9.
The robust firewall that is built into every Aerohive access point is more than capable of providing protection at the edge of the network as discussed earlier in this blog. However, sometimes a customer may have a written security policy that mandates that the guest VLAN not reside at the edge of the network. The guest VLAN can only exist in a DMZ. If that is the case, Aerohive APs can be configured to tunnel the guest traffic back to a HiveOS Appliance server that resides in the DMZ as shown in Figure 10.
Aerohive does not recommend “open” guest WLANs. You should always use encryption to protect your guest users. In my next blog about guest WLANs, I will discuss the many ways Aerohive can provide secure guest management.