Netgate is offering COVID-19 aid for pfSense software users, learn more.
Configuring a Secure Wireless Hotspot¶
A company or organization may wish to provide Internet access for customers or guests using an existing Internet connection. This can be a boon to the customers and business, but can also expose the existing private network to attack if not done properly. This section covers the common means of providing Internet access to guests and customers, while protecting the internal network.
Multiple firewall approach¶
For the best protection between a private network and a public network, obtain at least two public IP addresses from the ISP and use a second firewall for the public network. To accommodate this, place a switch between the Internet connection and the WAN interface of both firewalls.
This has the added benefit of putting the public network on a different public IP address from the private network, so if a report of abuse is received, it is easy to tell the origin. The firewall protecting the private network will see the public network no differently than any Internet host and vice versa.
Single firewall approach¶
In environments where the multiple firewall approach is cost prohibitive or otherwise undesirable, the internal network can still be protected by connecting the public network to an OPT interface on a firewall running pfSense®. Assign a dedicated private IP subnet to this OPT interface, and configure its firewall rules to allow access to the Internet but not the internal network.
In Rules to allow only Internet access from wireless the firewall rules allow clients to reach
the firewall for DNS requests and ICMP echo request (ping), but prevent all
access to other private networks. The RFC1918 alias referenced in the figure
includes the RFC1918 private network list,
Access control and egress filtering considerations¶
Other than not allowing traffic from the publicly accessible network to the private network, there are additional things to consider in the configuration of a hotspot.
Restrict network access¶
While many hotspots use open wireless networks with no other authentication, consider additional protections to prevent network abuse. On wireless, consider using WPA or WPA2 and providing the passphrase to guests or customers. Some businesses taking this approach display the passphrase on a placard in the lobby or waiting area, posted in a guest room, or provide it upon request. Also consider implementing Captive Portal on pfSense (covered in Captive Portal). This helps prevent people in other offices and outside the building from using the wireless network even if it is open access.
Disable Intra-BSS communication¶
If the access point allows, disable intra-BSS communication. This option is also sometimes called “AP Client Isolation”. This prevents wireless clients from communicating with other wireless clients directly, which protects users from intentional attacks from other wireless users as well as unintentional ones such as worms.
Intra-BSS communication may be required for certain functions such as wireless printers, Chromecast devices or similar cases when two wireless devices must talk directly to each other, but this is rarely if ever required in the context of a public hotspot.
Consider what kind of egress policy to configure. The most basic, allowing access to the Internet without allowing access to the private network, is probably the most commonly deployed but consider additional restrictions.
To avoid having the public IP address of the firewall black listed because of infected visiting systems acting as spam bots, consider blocking SMTP. Several large ISPs already block SMTP outbound because clients have moved to using authenticated access on the submission port (587) rather than using port 25 directly. An alternative that still lets people use their SMTP e-mail but limits the effect of spam bots is to create an allow rule for SMTP and specify Maximum state entries per host under Advanced Options when editing the firewall rule. Ensure the rule is above any other rules that would match SMTP traffic, and specify a low limit. Because connections may not always be properly closed by the mail client or server, do not set this too low to prevent blocking legitimate users, but a limit of five connections should be reasonable. Maximum state entries per host can be set on all firewall rules, but keep in mind that some protocols will require dozens or hundreds of connections to function. HTTP and HTTPS may require numerous connections to load a single web page depending on the content of the page and the behavior of the browser, so don’t set the limits too low.
Balance the desires of users against the risks inherent in providing Internet access for uncontrolled systems, and define a policy that fits the environment.