# How to Set Up a FortiAP at a Remote Site Over the Internet (FortiGate Remote AP Guide)
> A FortiAP doesn't have to sit on the same network as its FortiGate. This guide covers how to put one at a remote site, tunnel it home over the internet, and broadcast an SSID whose clients land on your main network. It includes requirements, firmware notes, limitations, a step-by-step build, verification, and rollback.
- Source: https://bytesizedtechsolutions.com/guides/fortiap-remote-site-over-internet/
- Author: Craig Miller
- Published: 2026-11-03
- Tags: fortinet, fortiap, fortigate, wireless, capwap, guide, homelab
- License: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/)
I built this in my homelab and tested the core build on live hardware. Where something comes from Fortinet's documentation rather than my own testing, I say so.
Illustration of a FortiAP 23JK, not a product photo. Traffic for your network rides the encrypted tunnel home, and everything else leaves from the remote site.
## What it is
A FortiAP is a *thin* access point. It has no configuration of its own worth speaking of: a FortiGate acting as its wireless controller tells it what to broadcast, over a protocol called **CAPWAP**. CAPWAP is ordinary routed traffic, so nothing requires the AP to be on the same LAN as its controller.
That means you can plug a FortiAP into **any internet connection** (a house, a small office, a hotel desk), have it find your FortiGate across the internet, and broadcast an SSID whose clients get addresses from, and land on, your main network. Fortinet calls this **Remote AP**. Many people who run FortiGates have never heard of it.
What you get:
- Devices at the remote site join a normal Wi-Fi network and are simply *on* your main network, with no VPN client on any of them.
- The FortiGate's security policy, logging, and DNS filtering all apply to them.
- By default **all** of a remote AP's traffic tunnels home, so the FortiGate inspects everything. With **split tunneling**, only traffic for your main network goes home, and everything else uses the remote site's own internet.
## When to use it, and when not to
**A good fit:**
- A small remote site, home office, or second home that needs a few devices on the main network.
- Devices that can't run a VPN client: printers, smart TVs, IoT, consoles.
- Places where you can't or don't want to install a firewall.
**Not a good fit:**
- A site that must keep working when the main site's internet is down. A tunnel-mode SSID **disappears** when the AP can't reach its controller. If that's a dealbreaker, put a firewall at the remote site and build a site-to-site VPN.
- A remote network where outbound UDP 5246–5247 is blocked. Guest networks and hotels often block it.
- Reusing an existing **bridge-mode** SSID at the remote site. A tunnel-mode SSID can be broadcast by on-site and remote APs alike, but a bridge-mode one can't be (see *Limitations*).
## What you need
| Requirement | Why |
|---|---|
| A FortiGate with a **publicly reachable** address | The AP has to reach the controller. CGNAT on the *controller's* connection breaks this. CGNAT at the *remote* site is fine, because the AP connects outbound. |
| A **stable** address, or a plan for discovery | The AP's static controller setting accepts only an IP address. See *Decisions* below. |
| A free **managed-AP slot** | Remote APs count against the FortiGate model's managed-AP limit. Check the datasheet. |
| A FortiAP model your FortiOS release manages | Recommended: a current, in-support model on up-to-date firmware. It gets security fixes, and the remote AP is the hardest one to reach for an update. |
| Outbound **UDP 5246 and 5247** at the remote site | CAPWAP control and data |
| **PoE**, either a switch or an injector | Most FortiAPs have no separate power brick |
| **Physical access to stage the AP** | With the staged approach, discovery settings are applied and checked while the AP is still on your LAN. Zero-touch provisioning is the alternative (see *Decisions*). |
## Firmware and version notes
- **`capwap` is not an `allowaccess` value on current FortiOS.** Fortinet's own remote-AP page says to enable "CAPWAP" on FortiOS 6.2.2 and earlier, and **Security Fabric Connection** on FortiOS 6.2.3 and later. The CLI value is `fabric`. Nearly every forum post and blog says `capwap`, and on a modern FortiGate that token doesn't exist.
- **"Set `wtp-mode` to remote" is dead advice.** That setting is gone from modern FortiOS. The `wtp-mode: normal` you'll see in diagnostic output is read-only.
- **`ipsec-sn-vpn`**, an IPsec data channel that also carries the AP's serial number in the IKE exchange, was added in FortiOS 7.4.0. Fortinet's documents spell it both `ipsec-vpn-sn` and `ipsec-sn-vpn`, sometimes on the same page, so check with `set dtls-policy ?` on your own device.
- **Virtual patching on local-in policies** (see *Security best practices*) is available on recent releases and needs a FortiGuard firmware virtual-patch license.
- **`apcfg-profile`** pushes discovery settings to the AP from the FortiGate, so you don't need the AP's own CLI.
- **Check which FortiOS releases manage your AP model.** Major releases can drop older models: FortiOS 8.0 stops managing several E-series units. An in-support model on current firmware is the recommended choice, because it keeps getting fixes.
- I tested this build on the FortiOS 7.6 branch. Before you script anything, settle field names against your own build's live schema: `GET /api/v2/cmdb/wireless-controller/vap?action=schema`.
## Limitations
- **Tunnel down means SSID down.** No internet at the main site means no Wi-Fi at the remote one.
- **Bridge-mode SSIDs don't travel.** An SSID object's mode and VLAN apply everywhere it's deployed. If your existing SSID is **tunnel** mode, the remote AP can broadcast it too, and Fortinet's deployment guide does exactly that. If it's **bridge** mode, as most on-site SSIDs are, it won't work remotely. FortiOS also won't let a second SSID object broadcast the same name (`node_check_object fail!` / `-651`), so the remote AP needs its own, distinctly named tunnel-mode SSID.
- **Discovery is fragile with a dynamic WAN address.** Covered next.
- **Overhead.** CAPWAP inside IPsec adds encapsulation. If the remote link is already tunneled (PPPoE, a carrier tunnel), you may need to tune the tunnel MTU (`tun-mtu-uplink` / `tun-mtu-downlink` on the AP profile). I didn't hit this, so treat it as a lead from Fortinet's documentation rather than something I tested.
## Decisions to make before you build
### Tunnel mode, not bridge mode
This is the most expensive thing to get wrong. I got it wrong twice, once in each direction, before testing it:
| SSID on the remote AP | Where the client lands |
|---|---|
| Bridge, untagged | The **remote** site's own network. Its router hands out the address, and the FortiGate issues no lease. |
| Bridge, VLAN-tagged | Nowhere. Nothing at the remote site serves that VLAN, so the client ends up with a `169.254` address. |
| **Tunnel** | **Your main network.** The FortiGate hands out the address across the tunnel. |
A bridged AP tags frames onto whatever it's plugged into. At home that's a switch trunk that honors the tag. At a remote site it's a router that has never heard of your VLAN.
Fortinet does recommend bridge mode for APs managed across a WAN. That advice is for branch offices whose users should stay on their *local* network and internet. To put remote clients on your main network, the SSID must be **tunnel** mode.
### How the AP will find the controller
The AP looks for its controller in this order: static IP, DHCP, DNS, Fortinet's cloud service, multicast, broadcast. Across the internet only the first three matter.
- **Static (`AC_IPADDR_1`) accepts only an IP address, never a hostname.** If the main site's public address changes, the AP is stranded. This is what happened to mine.
- **DNS (`AC_HOSTNAME_1`)** takes only a short name. The AP appends the domain suffix that the *remote* site's DHCP server hands out (option 15). You can't type a full hostname on the AP, and many consumer routers can't set option 15. Confirm the remote router can before the AP ships.
- **Best option with a dynamic address:** build a site-to-site VPN from the remote router to a dynamic-DNS name, and point the AP at the FortiGate's **private** address. That address never changes, and you no longer need a CAPWAP listener open to the internet at all.
### Full tunnel or split tunnel
Fortinet's default is to tunnel **all** remote-AP traffic home. Fortinet calls this the most secure option, because the FortiGate inspects everything. Split tunneling sends only chosen traffic home, which saves your main site's bandwidth, but internet traffic from the remote clients is then not inspected. Split tunneling has two modes (`split-tunneling-acl-path`):
| Mode | Default for unlisted traffic | What you list |
|---|---|---|
| `tunnel` | Stays local | The networks that go **home**. If you list none, **nothing** is tunneled. |
| `local` | Goes home | The networks that stay **local**. Fortinet says to enable *Include Local Subnet* "in almost all situations", so devices like a local printer still work. |
Either way, decide which networks should go home and which destinations and services the remote clients may reach, and write it down. It becomes the split-tunnel list and the firewall policy. This guide uses `tunnel` mode.
### Staged on your LAN, or zero-touch
- **Staged:** authorize the AP and push its discovery settings while it's on your LAN, then ship it. That's what this guide does.
- **Zero-touch:** with **FortiDeploy** (through FortiLAN Cloud in Fortinet's deployment guide), you add the AP to cloud inventory using its FortiCloud key and point it at your FortiGate's external IP or hostname. The AP can then ship straight to the remote site, unstaged, and find its controller once it's online. This needs the AP's FortiCloud key, or a FortiDeploy key ordered with the hardware. I haven't tested it, including whether a hostname survives an address change.
## Step-by-step build
Placeholders: `` is the FortiGate's internet interface, `` is the new SSID name, `` is the AP model, `` is the AP's serial number.
### 1. Build the fence before you open the door
Create a service for CAPWAP, then **local-in policies** that allow it only from where you expect the AP to be, and deny everything else. This comes first so the listener is never open to the whole internet, even briefly.
```
config firewall service custom
edit "CAPWAP"
set udp-portrange 5246-5247
next
end
config firewall local-in-policy
edit 0
set intf ""
set srcaddr ""
set dstaddr "all"
set action accept
set service "CAPWAP"
set schedule "always"
next
edit 0
set intf ""
set srcaddr "all"
set dstaddr "all"
set service "CAPWAP"
set schedule "always"
next
end
```
- `edit 0` appends, so create the allow **before** the deny. An allow that lands below a deny for the same service silently does nothing.
- A deny rule shows no `set action` line. Confirm it by the *absence* of `set action accept`.
- If the WAN is in an SD-WAN zone, `intf` takes the zone name.
- Virtual patching can be enabled on the allow rule. See *Security best practices*.
- This is defense in depth. The AP is still authorized by serial number.
### 2. Open the listener
```
config system interface
edit ""
set allowaccess ping fabric
next
end
```
`set allowaccess` **replaces** the whole list. Run `show system interface ` first and restate every existing value plus `fabric`, or you'll lose WAN-side access you meant to keep.
### 3. Create the tunnel-mode SSID, its interface, and DHCP
```
config wireless-controller vap
edit ""
set ssid ""
set security wpa3-sae
set sae-password
set split-tunneling enable
next
end
```
- **Leave `local-bridging` unset.** Its default, `disable`, *is* tunnel mode.
- Create the SSID with a throwaway password, then set the real one in the GUI **before** the SSID is assigned to any radio, so the throwaway is never broadcast and the real one never sits in your shell history.
- `wpa3-sae` is WPA3-Personal, which requires Protected Management Frames. Use `wpa3-sae-transition` if some devices only support WPA2, or an 802.1X mode if you have RADIUS. With 802.1X, the RADIUS conversation happens between the FortiGate and the RADIUS server, so the remote AP never needs to reach it. See *Security best practices*.
Creating the SSID auto-creates an interface with the same name. Give it an address and a DHCP server, and set `dns-service specify` with both DNS servers if you want clients to use your own resolvers. Both default to `0.0.0.0`.
### 4. Firewall policy
Create a policy from `` to your internal network. A new policy defaults to **deny**, so `set action accept` is required.
- **Enumerate destinations and services.** The remote AP sits on a network you don't control and holds a trusted tunnel into yours. Policy scope is your biggest lever if it's ever compromised.
- **Internet access depends on your tunnel choice.** With split tunneling in `tunnel` mode, internet traffic leaves at the remote site and needs no policy. With a full tunnel, add an internet policy for the remote SSID, with the security profiles you use elsewhere.
- Leave NAT off so logs show real client addresses.
### 5. The remote AP profile
```
config wireless-controller wtp-profile
edit "-Remote"
config platform
set type
end
set dtls-policy ipsec-vpn
set split-tunneling-acl-path tunnel
config split-tunneling-acl
edit 1
set dest-ip
next
end
config radio-1
set vap-all manual
set vaps ""
end
config radio-2
set vap-all manual
set vaps ""
end
next
end
```
- **`dtls-policy` defaults to `clear-text`.** On a LAN that's fine. Across the internet it means every client frame crosses the public network unencrypted. This is the most important line in the profile. IPsec is also faster than DTLS: FortiGates with NP6 chips can offload IPsec in hardware, and DTLS can't be offloaded at all.
- **`split-tunneling-acl-path tunnel`** means the list says what goes *home*. With `local` the meaning flips, and getting it backwards silently tunnels everything or nothing.
- **Always use `vap-all manual`.** A radio set to `tunnel` or `bridge` automatically adopts every new SSID of that mode the moment it's created. A freshly adopted AP on a stock profile once broadcast my open guest network and none of the real ones.
- Profiles are tied to a platform, so each AP model needs its own. If one model serves both on-site and remote roles, it needs two profiles.
- Fortinet's deployment guide recommends enabling **radio resource provisioning** on remote profiles (`set darrp enable` under each radio), so the AP picks channels for its own surroundings.
- Split-tunneling options are hidden in the GUI by default. `config system settings` / `set gui-fortiap-split-tunneling enable` shows them.
- Decide on the AP hardening options in *Security best practices* before the AP ships, while it's still easy to change.
- If you script this, assign SSIDs to radios with the CLI, not a REST `PUT` to a radio sub-object. A partial `PUT` wipes the channel list.
### 6. Stage the AP on your LAN
Authorize the AP, assign the remote profile, and push its discovery settings from the FortiGate with an `apcfg-profile`:
```
config wireless-controller apcfg-profile
edit "Remote-AP-Discovery"
set ac-type specify
set ac-ip
set ac-timer 10
config command-list
edit 1
set name "AC_IPADDR_1"
set value ""
next
end
next
end
config wireless-controller wtp
edit ""
set apcfg-profile "Remote-AP-Discovery"
next
end
```
`ac-type specify` with `ac-timer` is a safety net: if the AP can't rejoin within the timer after applying the settings, it rolls them back.
**Then confirm it applied** with `diagnose wireless-controller wlac -c wtp`. Both `cfg-apcfg-prof` and `oper-apcfg-pro` should name your profile, with a completed status. If they don't, stop and fix it now. This is the last moment you can reach the AP.
## Verify it works
Do these in order. Each one gates the next.
0. **Optional dry run.** Fortinet suggests temporarily broadcasting the remote SSID from an on-site AP first. That validates the SSID, DHCP, and firewall policy before the remote AP is in the picture.
1. **The AP connects from outside.** Take it off your LAN and plug it into a genuinely separate internet connection. A FortiAP's uplink is wired, so it can't join a phone hotspot by itself. I used a spare router on its own, separate internet connection, so the AP sat behind a different public address and its own NAT, just like a real remote site. A travel router that uses a phone as its internet and gives the AP an Ethernet port works too. `diagnose wireless-controller wlac -c wtp` should show `Connected` with the remote site's *public* address as the peer. An internal address means you're still testing the LAN. Allow up to five minutes while it cycles through discovery methods.
2. **The data channel is encrypted.** `show wireless-controller wtp-profile -Remote` should show `ipsec-vpn` (or `ipsec-sn-vpn`). If it says `clear-text`, stop.
3. **A client gets an address from the FortiGate.** `execute dhcp lease-list` should show the client in the remote SSID's range. That's the whole point of the feature.
4. **That client reaches an allowed internal service.**
5. **The tunnel behaves as you chose.** With split tunneling, from the client, run a traceroute to any internet address. The first hop should be the remote site's router. If it's your FortiGate, all of the remote site's traffic is hairpinning through your main site, and everything will still *look* fine. That's the defect you're least likely to notice, which is why it gets its own check. With a full tunnel, the first hop should be your FortiGate.
Use `diagnose` output as proof of what's running, not `show` output, which is only configuration.
## Troubleshooting and gotchas
- **The AP never shows up in the controller.** Check the switch port before the wireless config. Mine was on a port labeled "AP" that was still running NAC and parking it on an onboarding VLAN.
- **A long CLI line fails with `value parse error` / `-173`.** If you're automating over SSH, the client may be wrapping long lines. Keep lines short and read the config back. Don't trust the echo.
- **The AP was working and went dark.** Check whether the main site's public address changed. With a static `AC_IPADDR_1` there's no remote fix. This is why the discovery decision matters.
- **A delete is refused.** FortiOS won't delete an object that's still referenced. Work in reverse creation order.
## Rollback
Reverse the build order:
1. Move the AP to a default profile, or `set admin disable` on it.
2. Delete the remote AP profile.
3. Delete the firewall policy, then any objects it used.
4. Delete the DHCP server, then the SSID.
5. Remove `fabric` from the WAN's `allowaccess`. This closes the listener.
6. Delete both local-in policies, then the CAPWAP service.
Close the listener (step 5) **before** removing its fence (step 6), never the other way round.
If the AP is already remote and unreachable, don't start by closing the listener, or you lose your last way to reconfigure it. Revoke it explicitly with `set admin disable`, and **change the SSID passphrase**, since the AP still holds it.
## Security best practices
Security decisions for any network belong to the network administrator, who knows its risks, requirements, and constraints. This section lays out the recommended best practices for a remote AP and names the industry standard or vendor guidance behind each one, so you can weigh them against your own environment.
The standards referenced are the **CIS FortiGate Benchmark**, **NIST SP 800-153** (*Guidelines for Securing Wireless Local Area Networks*), the **Wi-Fi Alliance's WPA3** certification, and Fortinet's own documentation and PSIRT advisories.
A remote AP is worth this attention because of where it sits. On-site APs sit behind the firewall, on a switch you control. A remote AP sits on a network you don't control, holds an encrypted tunnel into yours, and stores your Wi-Fi credentials.
### Minimize the FortiGate's exposure
The CAPWAP listener is real attack surface. CVE-2024-35279 (FG-IR-24-160) was a stack buffer overflow in FortiOS's CAPWAP handling, reachable without authentication on any interface with `fabric` enabled. Fortinet's published workarounds line up with the first three practices below.
| Recommended practice | Why | Basis |
|---|---|---|
| **Prefer a design with no internet-facing listener.** Use a site-to-site VPN, and point the AP at the FortiGate's private address. | Removes the exposure entirely. It needs a remote router that can build a VPN. | Fortinet PSIRT workaround (remove `fabric`) |
| **Restrict CAPWAP with local-in policy.** Allow UDP 5246 only from expected sources, and deny everything else. | The narrowest source is the remote site's static public address. A geography object is a broader fallback. | CIS 2.4.6 *Apply Local-in Policies*. Fortinet PSIRT workaround. |
| **Enable virtual patching** (`set virtual-patch enable`) on the local-in allow rule | The FortiGate's IPS engine drops local-in traffic that matches known FortiOS exploits, covering the window between an advisory and your upgrade. It needs the FortiGuard firmware virtual-patch license. Fortinet notes it breaks agentless VPN and ZTNA connections that use client certificates. | CIS 2.4.8 *Virtual patching on the local-in management interface*. Fortinet PSIRT workaround. |
| **Pre-authorize APs by serial number and disable discovery on the WAN** (`set ap-discover disable`) | Only APs you added by hand can register, and unknown APs never appear. | Fortinet *Discovery and authorization of APs*. Fortinet's deployment guide calls auto-authorizing on the WAN "very poor security practice", and FortiOS doesn't offer it on WAN interfaces. |
| **Keep management services off the WAN, and restrict admins to trusted hosts** | A remote AP needs only `fabric`, so HTTPS, SSH, and SNMP can stay internal. | CIS 2.4.2 *trusted hosts for all login accounts* |
| **Patch FortiOS promptly, and subscribe to Fortinet PSIRT advisories** | Listener bugs like the one above get fixed in firmware. | NIST SP 800-153: vulnerability monitoring for WLAN components at least as often as for wired systems |
### Encrypt the data channel
The CAPWAP *control* channel is always DTLS. The *data* channel, meaning every client frame, defaults to `clear-text`, which is appropriate on a LAN but not across the internet.
**Recommended:** `dtls-policy ipsec-vpn`, or `ipsec-sn-vpn` where your release supports it. The second option also checks the AP's serial number in the IKE exchange. Check the token with `set dtls-policy ?`.
IPsec can be hardware-offloaded on FortiGates with NP6 chips. `dtls-enabled` also encrypts the data channel, but it can't be offloaded, so throughput is lower. The basis is Fortinet's *Data channel security* guidance.
### Harden the AP
| Recommended practice | Why | Basis |
|---|---|---|
| **Use a current, in-support model on up-to-date firmware**, pushed from the FortiGate | It keeps receiving security fixes. A remote AP is also the hardest one to reach for an update, so plan for that. | NIST SP 800-153: vulnerability monitoring and patching |
| **Set a unique AP admin password** (`login-passwd-change yes` + `login-passwd`) | The default, `no`, leaves the factory password in place. | NIST SP 800-153: standardized security configurations |
| **Disable management access on the AP** (empty `allowaccess`) | The AP then doesn't answer HTTPS, SSH, or SNMP on the remote network. If you need SSH for staging, it's common to open it only on your LAN and close it before the AP ships. | NIST SP 800-153: standardized security configurations |
| **Disable the console port** (`console-login disable`) where the AP is physically accessible | Blocks local login through the serial port, which is on by default. Changing this reboots every AP on the profile. | Fortinet *Disabling FortiAP port access* |
| **Disable the USB port** (`usb-port disable`) if it isn't used | Removes an unused interface. It requires full PoE power. | Fortinet *Disabling FortiAP port access* |
### Secure the LAN ports
APs like the 23JK have extra Ethernet ports, which are a big part of their appeal at a remote site: a printer, a desk phone, a TV. Each port's behavior is set with `port-mode` (in `config lan`, or `port1-mode`, `port2-mode` and so on, depending on the model):
| Mode | What a plugged-in device gets |
|---|---|
| `offline` | Nothing. The port is disabled. |
| `bridge-to-ssid` | Joins an SSID's network and tunnels home with it. Fortinet's docs note that such a host "will be taken as authenticated". |
| `bridge-to-wan` | The remote site's own network. It never touches the tunnel. |
| `nat-to-wan` | Local network access, NATed behind the AP. It never touches the tunnel. |
**Recommended:**
- **Disable ports that aren't in use.** That's NIST SP 800-153's guidance on disabling unauthorized interfaces and bridging.
- **Keep wired devices that only need the internet local** with `bridge-to-wan` or `nat-to-wan`.
- **Give wired devices that need to reach home their own SSID.** Create a separate SSID for wired devices, with its own subnet and a tightly scoped policy, rather than bridging ports into the network your wireless clients use. That follows NIST's guidance to separate networks with different security profiles.
### Secure the wireless side
| Recommended practice | Why | Basis |
|---|---|---|
| **WPA3-Enterprise (802.1X)** where a RADIUS server is available | Per-user or per-device credentials are checked on your side of the tunnel, so the AP holds no shared passphrase. | Wi-Fi Alliance WPA3 |
| **Otherwise, WPA3-Personal (SAE)** with a long, unique passphrase | SAE resists offline password guessing, and WPA3 requires Protected Management Frames. Use transition mode only while devices that can't do WPA3 remain. | Wi-Fi Alliance WPA3 |
| **Client isolation** (`intra-vap-privacy`) where clients don't need to reach each other | Limits how far one compromised device can reach. It breaks casting and printing between clients. | NIST SP 800-153: limit access to what's necessary |
### Contain the remote clients
| Recommended practice | Why | Basis |
|---|---|---|
| **Give remote clients their own subnet and zone** | Treats them as semi-trusted rather than as part of the main LAN. | NIST SP 800-153: separate WLANs with different security profiles |
| **Allow only the destinations and services they need** | Limits what a compromised remote device can reach. | NIST SP 800-153: limit wired-network access to necessary hosts and protocols |
| **Scope the policy's source by an address object, not only by interface** | The policy keeps its meaning if the interface is later grouped into a zone. I learned this one in my own lab: a policy that relied only on the interface silently widened when I added it to a zone with other networks. | Least privilege |
| **Apply security profiles** (IPS, antivirus, DNS filtering, application control) | Inspects remote traffic the same way as any other segment. | NIST SP 800-153: monitor for wired-network attacks too |
| **Log all traffic, with NAT off** | The logs show the real client address. | NIST SP 800-153: continuous monitoring |
### Monitor, assess, and plan for loss
- **Monitor continuously.** Alert when the remote AP disconnects and when an unknown AP tries to join. Watch for denied local-in traffic to UDP 5246, which shows who's probing the listener. FortiOS's wireless intrusion detection (WIDS) profiles add rogue-AP detection. (NIST SP 800-153: continuous monitoring and WIDPS)
- **Assess regularly.** NIST recommends a WLAN security assessment at least annually, and more often where continuous monitoring doesn't already cover it.
- **Have a revocation plan.** `set admin disable` on a lost AP's entry cuts it off immediately. Rotating the SSID passphrase completes the job, because the AP still holds it. The serial number is what the AP is pre-authorized with, so treat it as sensitive.
- **Retire it completely.** When a remote AP is no longer needed, close the listener and its fence (see *Rollback*), don't just unplug it. I eventually removed mine: an address change had stranded it, and an AP that can't connect isn't worth an open port.
## References
Everything this guide relies on, grouped so you can find the official documentation without hunting for it. Fortinet's document library is versioned: open a link, then use the version selector to switch to your FortiOS or FortiAP release.
### Fortinet deployment guides
- [Remote APs LAN Edge Deployment Guide: overview](https://docs.fortinet.com/document/fortiap/7.0.0/remote-aps-lan-edge-deployment-guide/550823/deployment-overview-secure-wireless-connection). Start here. It's Fortinet's end-to-end guide for remote and teleworker APs.
- [Enable Security Fabric on the WAN link](https://docs.fortinet.com/document/fortiap/7.0.0/remote-aps-lan-edge-deployment-guide/580232/enable-security-fabric-on-the-wan-link) explains why WAN interfaces never auto-authorize APs.
- [Using FortiDeploy for zero-touch provisioning](https://docs.fortinet.com/document/fortiap/7.0.0/remote-aps-lan-edge-deployment-guide/753731/using-fortideploy-within-fortilan-cloud-for-zero-touch-provisioning)
- [Assign the AP profile and authorize the AP](https://docs.fortinet.com/document/fortiap/7.0.0/remote-aps-lan-edge-deployment-guide/467083/assign-the-correct-ap-profile-and-authorize-the-ap-in-the-fortigate)
- [Split-tunneling considerations](https://docs.fortinet.com/document/fortiap/7.0.0/remote-aps-lan-edge-deployment-guide/281930/split-tunneling-considerations): tunnel mode vs local mode, and when to include the local subnet
- [Configuring split-tunneling and encryption using the CLI](https://docs.fortinet.com/document/fortiap/7.0.0/remote-aps-lan-edge-deployment-guide/597446/configuring-split-tunneling-and-encryption-using-the-cli), from the same guide.
- [Configuring FortiGate before deploying remote APs](https://docs.fortinet.com/document/fortiap/6.2.0/fortiwifi-and-fortiap-cookbook/290341/configuring-fortigate-before-deploying-remote-aps). This is where the CAPWAP to Security Fabric Connection rename is documented.
- [Remote WLAN FortiAPs](https://docs.fortinet.com/document/fortiap/7.6.4/fortiwifi-and-fortiap-configuration-guide/238787/remote-wlan-fortiaps) covers Fortinet's teleworker AP models, which are preconfigured for home and travel use.
### FortiAP configuration guide topics
- [Discovery and authorization of APs](https://docs.fortinet.com/document/fortiap/7.4.0/fortiwifi-and-fortiap-configuration-guide/827468): pre-authorizing by serial, and `ap-discover`
- [Advanced WiFi controller discovery](https://docs.fortinet.com/document/fortiap/7.6.5/fortiwifi-and-fortiap-configuration-guide/570170/advanced-wifi-controller-discovery): discovery order, plus `AC_IPADDR_1` and `AC_HOSTNAME_1`
- [Data channel security: clear-text, DTLS, and IPsec VPN](https://docs.fortinet.com/document/fortiap/7.4.1/fortiwifi-and-fortiap-configuration-guide/746425/data-channel-security-clear-text-dtls-and-ipsec-vpn)
- [IPsec VPN tunnel that carries the FortiAP serial number](https://docs.fortinet.com/document/fortigate/7.4.0/new-features/78725/add-support-for-an-ipsec-vpn-tunnel-that-carries-the-fortiap-sn)
- [Disabling FortiAP port access](https://docs.fortinet.com/document/fortiap/7.4.4/fortiwifi-and-fortiap-configuration-guide/542843/disabling-console-port-access): console and USB ports
- [LAN port options](https://docs.fortinet.com/document/fortiap/6.4.0/fortiwifi-and-fortiap-configuration-guide/430146): the bridge and NAT modes for an AP's LAN ports
### FortiOS CLI reference
- [`config wireless-controller wtp-profile`](https://docs.fortinet.com/document/fortigate/7.6.5/cli-reference/596642240/config-wireless-controller-wtp-profile): AP profiles, `dtls-policy`, split tunneling, LAN ports, and AP hardening options
- [`config wireless-controller wtp`](https://docs.fortinet.com/document/fortigate/7.6.6/cli-reference/221793529/config-wireless-controller-wtp): managed APs and per-AP overrides
- [`config wireless-controller vap`](https://docs.fortinet.com/document/fortigate/7.6.2/cli-reference/304313044/config-wireless-controller-vap): SSIDs, `local-bridging`, and `split-tunneling`
### Hardware, compatibility, and lifecycle
- [Fortinet Wireless Product Matrix](https://www.fortinet.com/content/dam/fortinet/assets/data-sheets/Fortinet_Wireless_Product_Matrix.pdf): every current FortiAP model side by side, including the 23JK
- [FortiAP Series data sheets](https://www.fortinet.com/resources/data-sheets/fortiap-series): per-model ports, radios, and power
- [FortiAP and FortiOS Compatibility Matrix](https://docs.fortinet.com/document/fortiap/7.6.0/fortiap-and-fortios-compatibility-matrix/261175/fortiap): which FortiOS releases manage which AP models
- [Product life cycle information](https://community.fortinet.com/customer-service-42/customer-service-tip-product-life-cycle-information-on-fortinet-products-96482): end-of-order and end-of-support dates for hardware and firmware
### Security advisories and hardening
- [FortiGuard PSIRT advisories](https://fortiguard.com/psirt): subscribe here for FortiOS and FortiAP vulnerabilities
- [FG-IR-24-160: stack buffer overflow in CAPWAP control](https://fortiguard.com/psirt/FG-IR-24-160)
- [Virtual patching on the local-in management interface](https://docs.fortinet.com/document/fortigate/latest/administration-guide/393161/virtual-patching-on-the-local-in-management-interface)
- [Configure remote AP over IPsec and understand the traffic flow](https://community.fortinet.com/fortiap-5/technical-tip-configure-remote-ap-over-ipsec-and-understanding-traffic-flow-116650), a Fortinet Community technical tip
### Industry standards
- [CIS FortiGate Benchmark](https://www.cisecurity.org/benchmark/fortinet): items 2.4.2 (trusted hosts), 2.4.6 (local-in policies), and 2.4.8 (virtual patching)
- [NIST SP 800-153, Guidelines for Securing Wireless Local Area Networks](https://csrc.nist.gov/pubs/sp/800/153/final)
- [Wi-Fi Alliance: Wi-Fi CERTIFIED WPA3 Technology Overview](https://www.wi-fi.org/system/files/Wi-Fi_CERTIFIED_WPA3_Technology_Overview_202101.pdf): SAE and mandatory Protected Management Frames
