Setting up a Wi‑Fi captive portal in an air‑gapped system

This setup was used as a demo unit at a conference to provide insight into the cybersecurity concerns around public Wi‑Fi networks. The project emulates a captive portal‑based Wi‑Fi network, such as ones found in Hotels, Airports, and Coffee shops. The setup is completely air‑gapped and does not require any form of internet connection to function.

Products used

• FortiGate 100E Firewall
  • Device was factory reset, and no Fortinet licenses were applied
• FortiSwitch 48‑port PoE switch
  • Joined via FortiLink and managed within the FortiGate console
• FortiAP
• Raspberry Pi 4B
  • 32 GB SD Card with Raspberry Pi OS (32‑bit) installed
  • Connected to the Raspberry Pi screen and wireless keyboard and mice
• Some form of internet connection to download and update the Pi
  • This will only be needed for the initial set‑up. I used a cellphone with USB tethering.
• Power and network cables for all devices
• Basic "Microsoft‑login‑style" captive portal
• Find the "Microsoft Style Portal file on my page for reference

Process

Initial Setup

• Flash the Raspberry Pi OS
  • I used the official Raspberry Pi imager, set the hostname “demopi” with an appropriate password. SSH was disabled because I have a screen and keyboard & mouse to interact with the Pi.
• Complete the initial setup for FortiGate
  • Setup admin username/password
  • Add Managed FortiSwitch
  • Add Managed FortiAP

Configuring the devices

FortiGate has a built‑in captive portal that we will be using. The issue is that FortiGate will not proceed with the captive portal unless it is connected to the internet. Hence, this won’t work for an air‑gapped system. This is where the Raspberry Pi comes in. It acts as a gateway and essentially fakes a network connection to allow the FortiGate to pass the mobile device “Captive Network Assistant” (CNA) check and display the captive portal.

Configuring the Raspberry Pi

• Update the Pi prior to starting. Connect to a Wi‑Fi network or your hotspot. Leave the Ethernet port open for use.

  $ sudo apt update
  $ sudo apt upgrade

• Set up the network gateway
  • The Pi needs a static IP for itself

    $ sudo nmtui    # access the built‑in network utility
    # Use the arrow keys and Enter to navigate.
    # Choose the wired connection (usually “eth0”).
    # Set IPv4 Configuration → Manual.
    # Add address 192.168.100.1/24.
    # Use the same address as DNS.
    # Save and quit.

  • The Pi needs to provide DHCP for the firewall
  • The Pi needs to provide DNS

    $ sudo apt install dnsmasq
    $ sudo systemctl stop dnsmasq
    $ sudo mv /etc/dnsmasq.conf /etc/dnsmasq.conf.bak
    $ sudo nano /etc/dnsmasq.conf
    
    # Add at the bottom:
    interface=eth0
    dhcp-range=192.168.100.10,192.168.100.50,12h
    dhcp-option=3,192.168.100.1
    dhcp-option=6,192.168.100.1
    
    $ sudo systemctl start dnsmasq

  • The Pi needs to forward IPv4 traffic

    $ sudo nano /etc/sysctl.conf
    # Uncomment: net.ipv4.ip_forward=1
    $ sudo sysctl -p

  • Configure iptables for NAT

    $ sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
    $ sudo apt install iptables-persistent   # persist across reboots

  • The Pi needs to fake the CNA check

    $ sudo nano /etc/dnsmasq.conf
    # Append:
    address=/#/192.168.100.1

Configuring the FortiGate and FortiAP

• Setup a new Guest user group within “User & Authentication”.
• Create a new SSID in “Wi‑Fi and Switch Controller”
  • Name it “Public Wi‑Fi”.
  • Authentication → Captive Portal → “Authentication only”.
  • Create a firewall policy:
    • Source Interface → Public Wi‑Fi
    • Destination Interface → WAN
    • Source → Guest User Group
    • Services → all
    • Action → Accept
• Within the “Settings” → “Replacement Messages”
  • Edit the Login and Login Failed HTML pages.
  • Use a Microsoft‑login‑style page for the login screen.
  • Customize the Login Failed page to warn users against entering corporate or personal credentials on unknown networks.

After completing the steps above, a Wi‑Fi network will appear that any mobile device can join. The device will be redirected to the captive‑portal page; if credentials are entered, the user is taken to the “Login Failed” page.

Note on Samsung devices: Samsung’s Knox suite uses a hard‑coded CNA address, so the standard captive‑portal flow does not trigger. To support those devices, add a DNS override for the Samsung CNA host:

$ sudo nano /etc/dnsmasq.conf
# Add:
address=/www.samsung.com/192.168.10.1
$ sudo systemctl restart dnsmasq

This forces Samsung phones to resolve the CNA check to the Pi, allowing the captive‑portal to appear.