NetCrosswalk: Cross-Vendor Network Task Translator

Steps

1. New stack (wifi package, wifiwave2-capable hardware): /interface wifi configuration add name=cfg-office ssid=Office security.authentication-types=wpa2-psk,wpa3-psk security.passphrase="<key>" then apply it: /interface wifi set wifi1 configuration=cfg-office disabled=no
2. Legacy stack (/interface wireless): /interface wireless security-profiles add name=office mode=dynamic-keys authentication-types=wpa2-psk wpa2-pre-shared-key="<key>" then /interface wireless set wlan1 ssid=Office security-profile=office mode=ap-bridge disabled=no
3. Add the wireless interface to your bridge (and set the bridge port PVID for the right VLAN).
4. GUI: Wireless (legacy) or WiFi (new) menu.
5. Verify: /interface wifi registration-table print or /interface wireless registration-table print

Changed across versions

• pre-7.13, wifiwave2 hardwareThe modern stack exists under the package name wifiwave2, on the same /interface wifi command tree used today.
• 7.13+wifiwave2 is split into chipset-specific packages (wifi-qcom, wifi-qcom-ac) and the GUI gains a dedicated WiFi menu. Upgrading from 7.12 or earlier must pass through 7.12 first — jumping straight to 7.13+ skips the automatic package conversion and can leave wireless config stranded.

Gotchas & notes

• There are two entirely separate wireless subsystems — legacy /interface wireless and the newer /interface wifi (wifiwave2 / wifi-qcom). Which one you have depends on the hardware and installed package, the CLI paths share nothing, and virtually every guide online targets the wrong one. Run /interface wifi print to see which exists.
• A new wireless interface is disabled by default and must be added to a bridge to pass traffic — an SSID that broadcasts but gives clients no DHCP is almost always a missing bridge port.
• For multiple SSIDs, create virtual interfaces (/interface wifi add master-interface=wifi1 or /interface wireless add master-interface=wlan1) and map each to a VLAN via the bridge VLAN table.
• MikroTik APs have no controller by default; CAPsMAN (or the newer /interface wifi capsman) is what centralises config across many APs, and it is a separate build-out.
• Country/regulatory setting affects available channels and power; leaving it unset limits performance and may be non-compliant.

Steps

1. Requires FortiAP hardware (or a FortiWiFi model's built-in radio) managed by the FortiGate.
2. WiFi & Switch Controller → SSIDs → Create New → set the *Traffic Mode* (Tunnel or Bridge), SSID name, security mode (WPA2/WPA3 Personal or Enterprise), and — in Tunnel mode — the interface IP and DHCP range.
3. WiFi & Switch Controller → FortiAP Profiles → assign the SSID to a radio on the profile used by your APs.
4. Add firewall policies from the SSID interface to your LAN/WAN (Tunnel mode makes the SSID a real interface).
5. Verify: WiFi & Switch Controller → Managed FortiAPs and *WiFi Clients*.

Gotchas & notes

• Creating the SSID is not enough — it must be assigned to a radio in the FortiAP Profile. An SSID that exists but is not broadcasting is nearly always this missing step.
• Tunnel vs Bridge mode is the key decision: Tunnel mode backhauls client traffic to the FortiGate (giving you a firewall interface, DHCP, and full inspection, but all traffic crosses the firewall); Bridge mode drops clients onto the AP's local VLAN (better for local traffic, but the FortiGate no longer sees it). Changing it later requires reworking policies.
• In Tunnel mode the SSID becomes an interface needing its own firewall policies and NAT — a new SSID with no policy has no internet.
• A plain FortiGate with no FortiAP cannot do wireless at all; FortiWiFi models have one built-in radio.
• FortiAP firmware should be compatible with the FortiOS version — mismatches cause APs to fail to join with unhelpful errors.

Steps

1. Settings → WiFi → Create New → set *Name (SSID)*, *Password*, and the Network (VLAN) it maps to.
2. Under *Advanced*, set the security protocol (WPA2/WPA3/WPA2-WPA3 mixed), band steering, and which AP Groups broadcast it.
3. Optionally set a *Schedule*, hide the SSID, or enable a captive portal via Settings → Guest Hotspot.
4. Save; APs reprovision within a minute.
5. Verify: Clients list, and the SSID appears under each AP's radios.

Gotchas & notes

• The cleanest wireless workflow of the six: one screen, pick the VLAN, done — the controller handles the AP-side config everywhere.
• WPA3 and mixed WPA2/WPA3 modes break older clients (IoT devices, printers, some 2015-era laptops). If devices fail to join a new SSID, this is the first thing to check. Keep a WPA2-only IoT SSID on 2.4 GHz.
• Every SSID is broadcast by every AP in the assigned AP Group by default. Beyond about 4–5 SSIDs the management overhead measurably reduces airtime — use VLANs and fewer SSIDs rather than one per purpose.
• The VLAN must actually be trunked to the APs' switch ports, or clients associate and get no DHCP. This is the most common 'SSID works but no internet' cause.
• Saving reprovisions APs, which briefly disconnects wireless clients — not a zero-impact change during the day.

Steps

1. A Catalyst switch or ISR router does not broadcast Wi-Fi.
2. Cisco wireless is configured on a WLC (Catalyst 9800, AireOS) or on an Embedded Wireless Controller running on a Catalyst 9k switch / Mobility Express AP.
3. On a Catalyst 9800: Configuration → Tags & Profiles → WLANs → Add, then bind the WLAN to a Policy Profile and Policy Tag applied to the APs.
4. The switch's job is to trunk the client VLANs and provide PoE to the APs.

Gotchas & notes

• Do not look for SSID configuration on the switch or router — it is a different product. The C9800 uses a tag-based model (Policy/Site/RF tags) that is substantially different from AireOS and from every other vendor here.
• On the switch side, what matters is: PoE budget on the AP ports, the AP management VLAN as the native/access VLAN, and the client VLANs trunked if the APs use FlexConnect local switching.
• Some ISR/autonomous APs run IOS with dot11 ssid commands, but autonomous mode is legacy and rarely deployed new.
• For a small site, an Embedded Wireless Controller on a Catalyst 9k avoids a separate WLC appliance.

Steps

1. PAN-OS firewalls have no wireless capability and no AP controller.
2. Terminate wireless on a dedicated AP/controller platform and trunk the client VLANs to the firewall as sub-interfaces.
3. Then treat each wireless VLAN as its own zone with its own security policies.

Gotchas & notes

• Standard design: put each SSID on its own VLAN, give it a dedicated zone on the firewall, and write policies per zone. Guest wireless in a zone with only an internet-bound allow rule is the common pattern.
• User-ID can identify wireless users via the wireless controller's syslog or RADIUS accounting, which is the main integration point worth setting up.
• Do not attempt to bridge wireless through the firewall in Layer2 mode as a workaround — put a real switch/AP infrastructure in front of it.

Steps

1. Only possible with a supported FreeBSD wireless NIC in AP mode — uncommon and generally discouraged.
2. If present: Interfaces → Assignments → Wireless → create the wireless instance, then configure it under Interfaces → <WLAN> (mode Access Point, SSID, WPA settings, channel).
3. Bridge or route it as needed and add firewall rules plus a DHCP server.
4. Better approach: use an external AP and trunk VLANs into pfSense.

Gotchas & notes

• Treat pfSense as having no wireless. FreeBSD AP-mode driver support is limited, 802.11ac/ax support is largely absent, and stability and throughput are poor compared with any real AP.
• Netgate removed wireless support from newer pfSense Plus releases and does not recommend it on CE either — do not design a network around it.
• The correct pattern is an external AP (UniFi, MikroTik, whatever) on a trunk, with each SSID's VLAN terminating on a pfSense VLAN interface with its own rules.
• If you inherit a pfSense with a wireless card configured, plan to move that function to a dedicated AP.

Steps

1. Requires either a TZ-W model with a built-in radio, or a SonicPoint/SonicWave access point cabled (PoE) to the firewall and adopted by it — there is no separate controller appliance; the firewall itself is the AP controller.
2. If you need the SSID on its own VLAN, create that first: MANAGE → Network → Interfaces → add a VLAN sub-interface, then MANAGE → Network → Zones → create (or reuse) a Zone bound to it. Doing the VLAN/Zone step after the SSID exists is the more common ordering mistake.
3. MANAGE → Connectivity → Wireless → Virtual Access Point → Add → set the *SSID* name, *Authentication Type* (WPA2/WPA3-PSK or WPA2/3-Enterprise with RADIUS), and passphrase or RADIUS server.
4. On the same VAP object, set *VAP Group*/zone binding so the SSID's traffic lands on the Zone/VLAN created above rather than falling back onto the default WLAN zone.
5. MANAGE → Connectivity → Wireless → Wireless Settings (or the AP's radio profile under Access Points) → enable the VAP on the 2.4GHz and/or 5GHz radio.
6. Verify: MANAGE → Connectivity → Wireless → Access Points shows the AP as provisioned with the new VAP active, and Station Status shows clients associating to it.

Changed across versions

• 7.0The Gen7 GUI reorganization moved wireless config from a standalone top-level 'Wireless' tab (SonicOS 6.5.x) into MANAGE → Connectivity → Wireless. Screenshots or guides written against 6.5 won't match the 7.x menu structure.

Gotchas & notes

• This is a GUI-only feature — the SonicOS CLI (E-CLI) has no commands to create, edit, or even list Virtual Access Points/SSIDs; SonicWall's own docs treat wireless config as a web-GUI task, full stop.
• An SSID (VAP) that isn't explicitly bound to the Zone/VLAN you created gets dumped onto the default WLAN zone and inherits whatever access rules that zone has — clients associate fine but land somewhere you didn't intend.
• WPA3 availability depends on the AP hardware generation, not just firmware — older SonicPoints (as opposed to SonicWave) may cap out at WPA2 even on current SonicOS.
• A VAP without matching access rules from the WLAN/VLAN zone to LAN/WAN will authenticate clients but give them no traffic — same class of gotcha as a Fortinet Tunnel-mode SSID with no firewall policy.
• TZ-W internal radios and SonicPoint/SonicWave external APs are configured from the same Wireless menu, but internal-radio VAP counts and per-radio limits are lower than what a SonicWave AP supports.

Steps

1. Requires an Insight-managed Orbi Pro AP, Insight WiFi 6/6E AP, or an Insight-managed router with a built-in radio — added to a Location in the Insight portal or mobile app. Smart Switches and M4200/M4300 switches have no radios and play no part in this step.
2. Insight portal: select the Location → Wireless Settings (or Networks → Wireless, wording varies by portal version) → Add Wireless Network / SSID.
3. Set the SSID name, security mode (WPA2-Personal, WPA3-Personal/Transition, or WPA2/WPA3-Enterprise with a configured RADIUS profile), and which band(s) it broadcasts on (2.4GHz/5GHz/6GHz depending on AP model).
4. To put it on a non-default VLAN, first define the VLAN under the Location's Wired Network / VLAN settings, then select that VLAN ID on the SSID's configuration page.
5. Choose which AP(s) or AP group broadcast the SSID, optionally toggle Guest Network (client isolation, captive portal), then Save — Insight pushes the config down to the AP over its cloud management link.
6. Mobile app path is equivalent: Location → Wireless → Add Network, same fields in a condensed layout.
7. There is no CLI path for this step on any NETGEAR device — routers and Orbi Pro APs have no CLI whatsoever.

Gotchas & notes

• Unlike UniFi, there is no self-hosted/local controller fallback — Insight is the only place this config lives, and most Orbi Pro/Insight-router models have no local web GUI to fall back on if cloud connectivity drops.
• VLAN tagging the SSID is only half the job: if the AP uplinks through a plain (non-Insight) NETGEAR Smart Switch, you must separately trunk that VLAN on the switch's own local GUI or Lite CLI — Insight does not push switch-side VLAN config to devices it isn't managing.
• WPA3 and 6GHz availability depend heavily on the specific AP model and its current firmware; older Orbi Pro units may only offer WPA2/WPA2+WPA3-transition.
• Enterprise (802.1X) SSIDs require a RADIUS server profile configured elsewhere in Insight first — you cannot enter RADIUS details inline while creating the SSID.
• Some SSID features (multiple SSIDs per radio, RADIUS/Enterprise auth, advanced scheduling) are gated behind an Insight Premium subscription — Insight Basic will grey these out per device.
• Changes are not instantaneous: the AP polls/receives the push over the cloud link, so expect anywhere from a few seconds to a couple of minutes, and some config changes trigger an AP reboot.