Captive Portal bypass for Apple updates and Chromebook authentication

In this example, you will allow WiFi traffic to specific destinations from Apple devices or Google Chromebooks to bypass your Captive Portal. This allows those devices to receive updates or device logon authentication, a process which a Captive Portal would interrupt.

Not all users or traffic types need to be authorized and authenticated by the Captive Portal. In some circumstances the authentication required by the Captive Portal can cause problems impacting the functionality of your users mobile device or laptop.

Chromebooks require user authentication to log onto the device, which can be blocked by the captive portals requirement for user authentication, to gain network access.

Apple devices make use of Captive Network Assistant (CNA) which can detect the use of a captive portal. The apple device attempts to visit the page captive.apple.com. If the apple device is successful, the CNA doesn’t load, but if it unsuccessful, then it launches a browser to prompt the user with the login page from the captive portal. When this browser is inadvertently closed or ignored, the device is disconnected from the network. Often times the user is unaware and does not know why email and updates are not being downloaded.

1. Creating a user account and user group
Go to User & Device > User Definition and create a Local user. Create additional users as needed. You can use any authentication method.
Go to User & Device > User Groups. Create a user group for employees and add the new user(s) to the group.
2. Creating firewall addresses
We need to create address objects to be used for the exemptions. Go to Policy & Objects > Addresses and create an FQDN address for accounts.google.com.
Create an FQDN address object for gstatic.com.
Create an IP/Netmask address object for the apple Subnet range 17.0.0.0/8.
Create an FQDN address object for captive.apple.com.
Create IP/Netmask address object(s) for any external DNS servers the client computers might use.
3. Creating the SSID
Go to WiFi Controller > SSID and configure your wireless network.
Configure DHCP addressing for clients.
Configure Captive Portal authentication using the Forti-WiFi-users user group. Set Exempt Destination Services to exempt the addresses created in the previous step.
4. Creating the security policy
Create an address for your SSID, using the same IP range that was set on the DHCP server.
Go to Policy & Objects > IPv4 Policy and create a policy allowing WiFi users to connect to the Internet. Select the Fortinet-WiFi-IP-range for the permitted Source Addresses. Enable NAT. The Web Filter and Application Control security profiles are enabled, so we can see the results of our configuration. Enable these profiles and others to provide secure internet access to your wireless clients.
5. Connecting and authorizing the FortiAP
Go to System > Interface and edit the interface the FortiAP connects to. Set Administrative Access to allow CAPWAP.
The FortiAP will broadcast for the controller using the CAPWAP protocol. Go to WiFi Controller > Managed FortiAPs. The FortiAP is listed, with a grey question mark beside it because the device is not authorized.
Highlight the FortiAP unit on the list and select Authorize.
A green check mark is now shown beside the FortiAP, showing that it is authorized and online.
Go to WiFi Controller > WiFi Network > FortiAP Profiles and edit the profile. For each radio: Enable Radio Resource Provision. Select your SSID.
6. Results
Connect your Chromebook or Apple device to the captive portal SSID. The user’s device shows the WiFi network as “open” and associates with it without requesting credentials. On the Chromebook you will be able to log onto the device and authenticate with Google accounts. On the Apple device you will not get the CNA prompt with the captive portal popup, requesting you to authenticate. The Apple device will stay connected to the WiFi.
Go to WiFi Controller > Monitor > Client Monitor to see connected users.
In this example a Chromebook is displayed with the IP address of 192.168.20.3. The user has authenticated against the portal. An iPhone is listed with the IP address of 192.168.20.4. A User is not listed as they have not yet authenticated against the portal. We can see in the Bandwidth TX/RX column, that there is bidirectional traffic.
Go to FortiView > Sources Review the current sessions of the connected network clients, by drilling down through each layer to view the related sessions.
In this example, we see the sessions for the connected Chromebook. You can see towards the bottom that the sessions happened prior to the user authentication against the portal. This proves the result of our exemption list.
Go to FortiView > Policies Review the current sessions of the connected network clients for the SSID to internet security policy, by drilling down through each layer to view the related sessions.
In this example, we see the sessions for the connected iPhone. We see that the user has not yet authenticated against the portal, but the iPhone is making DNS requests and accessing the apple subnet. This proves the result of our exemption list.
Go to Log & Report > Forward Traffic Log Review the traffic and destinations for the Apple iPhone.
In the these logs you can see that the iPhone is receiving push notifications prior to the captive portal logon.
The first time that a wireless user attempts to use a web browser, the captive portal login screen is displayed. Users who are members of the Forti-WiFi-users group can log on using their username and password and proceed to access the wireless network.