Wireless Security practice questions

A missing OSPF router ID on the access point

Why wrong: A missing OSPF router ID on the access point is irrelevant to WLAN client authentication because OSPF is a dynamic routing protocol that operates at Layer 3 and is used for exchanging routes between network devices, not for securing wireless client access. The AP's OSPF configuration, or lack thereof, has no bearing on the 802.11 association or 802.1X/WPA supplicant process; client authentication depends on the wireless security settings and RADIUS/PSK validation. OSPF router ID issues would disrupt IP routing between the AP and other routers, but would not prevent a client from authenticating to a locally broadcast SSID.

A routed-port mismatch on the switch uplink

Why wrong: A routed-port mismatch on the switch uplink is a Layer 3 interface configuration problem affecting IP traffic between the switch and upstream devices, but it does not interfere with the client's ability to authenticate to the WLAN. Client authentication to the SSID occurs at the wireless link between the laptop and AP, involving 802.11 management frames and security handshakes; the switch uplink's port mode (routed vs. switched) only becomes relevant for forwarding user traffic after successful authentication. Therefore, this mismatch would cause routing or reachability issues for post-authentication traffic, not the described symptom of the client connecting to the correct SSID but repeatedly failing to gain access.

A DHCP relay problem on the client

Why wrong: A DHCP relay problem on the client is not a valid failure point because DHCP relay functionality resides on routers or multilayer switches, not on the client itself. Even conceptually, DHCP address assignment occurs only after the client has successfully authenticated and associated at Layer 2; if authentication fails, the client never reaches the DHCP discovery phase. Thus, a DHCP relay issue would manifest as a missing IP address after successful association, not as repeated authentication failures or the inability to complete the WLAN security handshake.

Enable SSID broadcast, change security to WPA2-PSK, and assign VLAN 20 in the policy tag.

Why wrong: Enabling the broadcast solves discovery, but switching to WPA2-PSK is incompatible with the client's WPA3-Personal configuration, because WPA3-Personal mandates the SAE (Simultaneous Authentication of Equals) handshake, not the older PSK key exchange. Furthermore, assigning VLAN 20 in the policy tag places this client on the wrong Layer 2 segment; the access point would tag its traffic with VLAN 20, isolating the client from the resources on VLAN 100 even if authentication somehow succeeded.

Disable SSID broadcast, change security to WPA3-Personal, and assign VLAN 100 in the policy tag.

Why wrong: Disabling SSID broadcast would keep the wireless LAN cloaked from clients performing active scanning; the client specifically needs a broadcasted SSID to discover the network during the probe/scan phase and cannot initiate association to an SSID it never sees. Even though WPA3-Personal and VLAN 100 would otherwise be acceptable, the hidden SSID prevents the client from even attempting connectivity, so this option fails to resolve the problem. Hiding the SSID is not a valid substitute for a proper security configuration.

Enable SSID broadcast, change security to WPA3-Enterprise, and assign VLAN 100 in the policy tag.

Why wrong: WPA3-Enterprise requires an IEEE 802.1X/EAP framework with a RADIUS server, whereas the client is configured for WPA3-Personal, which uses a pre-shared key negotiated via the SAE handshake; without valid enterprise credentials and backend authentication infrastructure, the AP will not complete the 4-way handshake. Although broadcast is enabled and VLAN 100 is correct, the security mode mismatch prevents the client from associating successfully.

It is the same thing as a client SSID.

Why wrong: An SSID (Service Set Identifier) is the human-readable name of a wireless network that clients scan for and select to connect, typically broadcast in beacon frames. CAPWAP is a backend protocol that only operates on the wired network between an AP and a controller, invisible to wireless clients. Confusing them mixes the client-facing characteristic of a WLAN with the control-plane tunneling mechanism used behind the scenes, and they have no functional equivalence.

It is a replacement for WPA2 and WPA3.

Why wrong: CAPWAP is a tunneling protocol, not an encryption or authentication standard, so it cannot replace WPA2 or WPA3. WPA2 and WPA3 secure the wireless link by using AES-CCMP or AES-GCMP encryption and handshake-based authentication between the client and the AP. CAPWAP, in contrast, operates behind the AP layer, not between the client and AP, and it carries encrypted payloads rather than providing the encryption itself.

It is used only for IPv4 ACL filtering.

Why wrong: CAPWAP is a Layer 3 protocol that encapsulates AP-controller traffic using UDP/IP, which has no connection to IPv4 ACL filtering. Access control lists (ACLs) are a separate security mechanism that permits or denies packets based on source/destination addresses, ports, or protocols, and they are configured on routers, switches, or WLCs. CAPWAP does not filter traffic; it simply provides a tunnel for control and data messages, so calling it an ACL tool is incorrect.

WPA3 uses TKIP encryption for backward compatibility with legacy devices.

Why wrong: WPA3 does not use TKIP under any circumstances; TKIP is a legacy WPA/WPA2 cipher that is deprecated because of known cryptographic weaknesses. The Wi-Fi Alliance explicitly forbids TKIP in WPA3-certified devices. Backward compatibility with older clients is handled through transition mode, where the AP can simultaneously support WPA2 and WPA3, not by falling back to TKIP.

WPA3 relies solely on 802.1X/EAP authentication for both personal and enterprise modes.

Why wrong: WPA3 Personal mode does not use 802.1X/EAP at all; it authenticates users with a passphrase via SAE. The 802.1X/EAP framework is reserved for WPA3 Enterprise mode, where it supports multiple user identities and an authentication server. Thus, the statement incorrectly conflates the two modes and ignores SAE as the mandatory Personal-mode authentication method.

WPA3 mandates the use of GCMP-256 encryption for enhanced security.

Why wrong: WPA3 does not mandate GCMP-256 encryption across all deployments. The baseline WPA3 specification requires CCMP-128 (AES) as the minimum security suite. GCMP-256 is used in the optional WPA3-Enterprise 192-bit security mode, but it is not a universal mandate. Therefore, saying WPA3 mandates GCMP-256 overstates its use and ignores the baseline CCMP-128 requirement.

WPA3 makes Protected Management Frames (PMF) optional to support older clients.

Why wrong: WPA3 makes Protected Management Frames (PMF) mandatory, not optional, for all certified devices. PMF uses 802.11w mechanisms to encrypt management frames, preventing attackers from forging deauthentication and disassociation frames to disrupt clients. Older clients that cannot support PMF are simply not allowed to connect in pure WPA3 networks; transition mode handles legacy devices separately.

Change the SSID security to WPA2-PSK and disable SSID broadcast; reset the WLC to factory defaults.

Why wrong: Selecting WPA2-PSK directly violates the requirement for WPA3-Personal security, and WPA2-PSK does not support SAE (Simultaneous Authentication of Equals), leaving the network vulnerable to offline dictionary attacks. Disabling SSID broadcast is counterproductive because the reported issue is that clients cannot see the SSID, so hiding it would worsen visibility. Resetting the WLC to factory defaults is an unnecessary and destructive step that would erase all existing configuration, including the required VLAN and gateway settings, making the problem worse.

Update the WLC firmware to the latest version and change the management VLAN to VLAN 1.

Why wrong: Updating the WLC firmware is a generic troubleshooting step that does not address the specific misconfiguration: the SSID is using the wrong security type (WPA2 instead of WPA3-Personal) and the management interface may be on the wrong VLAN. Changing the management VLAN to VLAN 1 is poor practice because VLAN 1 is the default native VLAN and is commonly targeted, plus it does not align with the stated requirement that management should be on VLAN 10. This action would not restore client connectivity to the SSID nor fix the intermittent web UI access.

Reconfigure the SSID with WPA3-Enterprise and enable SSID broadcast; set the management interface to use DHCP.

Why wrong: WPA3-Enterprise requires an 802.1X/RADIUS authentication server, and the scenario explicitly specifies WPA3-Personal with a pre-shared key; enabling WPA3-Enterprise would cause authentication to fail because no RADIUS server is defined. Enabling SSID broadcast is unnecessary because the SSID is already visible, so this does not address the security mismatch. Setting the management interface to use DHCP is risky because a DHCP lease change could alter the gateway or IP address, making the web UI unreachable intermittently; a static management IP with the correct VLAN 10 gateway is required.

Guest WLANs should avoid all security to make access easier.

Why wrong: Guest WLANs should not avoid all security because an open, unencrypted network is a high-risk vector for credential theft, malware distribution, and unauthorized eavesdropping. Even guest networks require at least WPA2/WPA3 with a captive portal or preshared key for accountability, plus client isolation to prevent peer-to-peer attacks. Security is not about making access harder; it is about applying appropriate controls so that ease of use does not come at the cost of safety.

Guest WLANs should automatically use the same permissions as internal employee WLANs.

Why wrong: Guest WLANs should not automatically use the same permissions as internal employee WLANs because that would let unauthenticated visitors reach corporate assets such as file shares, printers, and management interfaces, completely negating segmentation. Employees are vetted and given role-based access, whereas guests have no such standing, so their traffic must be mapped to a restricted access profile. Uniform permissions would violate the core design principle of least privilege and expose the internal network to unacceptable risk.

Guest access means the AP no longer needs controller coordination.

Why wrong: Guest access does not mean the AP no longer needs controller coordination; the controller still provides critical functions like CRL, authentication, radio resource management, and enforcement of the guest VLAN and policy. Even with guest traffic offloaded or tunneled, the AP relies on the controller or a centralized WLC for onboarding, roaming, and applying ACLs. The guest network is simply a logical configuration under the same management architecture, not an independent network that bypasses controller oversight.

The SSID is not hidden. Use 'config wlan disable-broadcast-ssid 1 enable' to hide the SSID.

Why wrong: The client's ability to see the SSID indicates that beaconing and probe responses are functioning, so the SSID is not hidden. Hiding the SSID would merely stop the name from being broadcast in beacons; it does not affect association at Layer 2. The reported failure occurs after the client discovers the network, so this change would not resolve the actual cause—the WLAN's interface binding.

WPA3 is not enabled on the WLAN. Use 'config wlan security wpa akm 6 enable' to enable WPA3.

Why wrong: This is incorrect because the question states the client can see the SSID but fails to associate. If WPA3 were not enabled, the client would likely not see the SSID or would fail at authentication, not association. The association failure is due to interface mapping.

The WLAN is disabled. Use 'config wlan enable 1' to enable the WLAN.

Why wrong: If the WLAN were disabled, the access point would not transmit beacons or respond to probe requests, and the client would not see the SSID in its scan results. Since the client does see the SSID, the WLAN is actively enabled. Enabling it would change nothing because the problem is not WLAN availability but the interface to which the WLAN is mapped; the client associates but cannot obtain an IP on the management network.