When a captive portal is enabled on a network, users attempting to access the network from a desktop/laptop computer or mobile device are first directed to a web page. Although captive portals can be enabled on wired networks, more typically they are used as gatekeepers on wireless networks.

Captive portal pages are displayed after a user connects to a network protected by a captive portal. The user then will try to access a URL. If the URL request comes from an unknown client, the network operating system—in this case, pfSense/FreeBSD—will recognize that users must pass through the captive portal before they have full access to the network.

The user will be redirected to a web page or splash screen. They may simply have to click on a button to indicate their agreement with the network's terms of service or an End User License Agreement (EULA), or they may have to provide login credentials. Either way, once the user is authenticated, they will have access to the network.

The page you use for your captive portal must, at a minimum, allow the user to authenticate to the extent you require. There are many different examples of captive portal pages on the internet, and you should be able to find one you can use as a template. Ideally, you will want to customize your captive portal page to make it easy to use and perhaps even to advertise your business (at the very least, you will probably want to put your company's logo on the page) if you are implementing a captive portal for customers.

Implementing a captive portal on a publicly accessible network has several advantages:

• Captive portals help us to separate guest traffic, which has considerable security benefits. They help keep guests away from confidential company data, and can be an integral part of your network access-control policy.
• The terms of service (or EULA) can incorporate the right of the company to collect user data. Captive portal data can be collected based on time, date, and user, and such information can be used as you, or your company, requires. Such data can be channeled in a positive way, such as using the data to create a better user experience, or in a negative way, such as identifying users that are over-utilizing bandwidth and restricting their access.
• A captive portal landing page can be a useful means of marketing your product. Portals can also display exclusive deals and links to your company's social media accounts.
• Some users may abuse a public wireless network by downloading music, videos, other large files, or otherwise hogging bandwidth. Having a captive portal makes it easy to limit the speed at which files are downloaded and the amount of data that can be downloaded, and traffic-shaping can be used to limit how much bandwidth a single user can consume.
• It potentially protects you from legal action being taken against you. Having users agree to an EULA will (hopefully) make them understand that the network may not be secure, and it should also provide a shield from liability if an end user is the victim of a perpetrator of illegal activity on your network.

There are, however, a number of issues with networks that use captive portals, which you should consider:

• For a long time, the possibility of a third-party intercepting network traffic has been a concern. HTTPS is a protocol designed to prevent traffic-interception and alteration by nefarious third parties. But a captive portal works by intercepting and altering the connection between the end user and the network. This is not a problem with HTTP traffic, but sites secured with HTTPS will detect someone intercepting the connection, and will generate an untrusted connection warning. This captive portal can generate false positives when accessing sites that use HTTPS. Such false positives tend to train captive portal users to ignore these warnings, which, of course, is very bad, because they may then ignore an actual man-in-the-middle attack.
• Another issue is that captive portals use a web page for authentication, which makes them unsuitable for use with devices that do not have web browsers. This can cause confusion with users of such devices. Even when the device has a web browser, often the captive portal page will not show until the user accesses a web browser.
• Networks using captive portals can cause issues for browsers that use caches. For example, a user that connects to a network using a captive portal in which URLs are redirected to an authentication page may find that their browser continues to redirect to that page even after they disconnect from the captive portal network. In some cases, the only way to resolve the issue is to clear the browser cache.
• Finally, the argument can be made that captive portals are not user friendly—they force the end user to jump through hoops to connect to the network in the first place, and then often the user can be forced to jump through those hoops again if there is a time limit or data limit placed on the captive portal. Many businesses have turned off captive portals for exactly this reason.

In many cases, however, using a captive portal is the best possible option, especially if you need to have a form of user authentication for a public network, or if you need to bill customers for using your network, since captive portals provide a convenient way of determining how much data specific users are using. If you implement a captive portal, you can mitigate the effects of some of these issues by following best practices for captive portal implementation, which will also be covered in this chapter.