5.4 AAA, IPsec VPN Concepts, and WLAN Security

LESSON PURPOSE

Develop a practical security foundation for controlling administrative and user access, protecting traffic across untrusted networks with IPsec VPNs, and securing enterprise WLAN access with modern authentication and encryption.

Lesson Overview

This lesson brings together three security areas commonly encountered in enterprise networks. AAA provides a structured method for authenticating identities, authorizing permitted actions, and accounting for activity. Centralized AAA commonly uses TACACS+ for device administration and RADIUS for network-access authentication.

The lesson also introduces IPsec VPN concepts used to protect IP traffic across untrusted networks, including confidentiality, integrity, peer authentication, anti-replay protection, IKE negotiation, and ESP-protected data. The WLAN section explains modern wireless security using WPA2/WPA3, PSK versus Enterprise authentication, 802.1X/EAP, RADIUS, and strong AES-based encryption.

Learning Objectives

• Explain the three AAA functions—authentication, authorization, and accounting—and why centralized AAA improves security and operational control.

• Differentiate local authentication from centralized AAA and describe the practical roles of TACACS+ and RADIUS.

• Explain how a network device acts as an AAA client and how an AAA server validates identities, applies policy, and records activity.

• Describe the purpose of VPNs and distinguish common site-to-site and remote-access VPN use cases.

• Explain the security services provided by IPsec: confidentiality, integrity, peer authentication, and anti-replay protection.

• Describe the conceptual relationship between IKE negotiation, IPsec security associations, and ESP-protected user traffic.

• Explain WLAN security risks and why legacy mechanisms such as WEP and TKIP should not be used for modern enterprise protection.

• Compare WPA2 and WPA3 security at a CCNA level and distinguish Personal/PSK authentication from Enterprise/802.1X authentication.

• Describe the roles of the wireless client, AP/WLC, RADIUS server, and EAP/802.1X process in enterprise WLAN authentication.

• Verify and troubleshoot security behavior by checking AAA reachability/policy, VPN peer and security-association status, and WLAN authentication/encryption settings.

CCNA MEMORY RULE — AAA controls WHO and WHAT; IPsec protects TRAFFIC across untrusted networks; WLAN security controls and encrypts WIRELESS access.

Pasted content image

AAA, IPsec, and WLAN security protect identity, traffic, and access at different points in the enterprise network.

1. AAA Foundations

AAA is a security framework used to control who can connect, what an authenticated identity is allowed to do, and what activity is recorded. Cisco devices can use a local username database, a centralized TACACS+ or RADIUS server, or an ordered method list that tries more than one source.

Pasted content image

Figure 1. The network device acts as an AAA client (NAS), while the centralized server returns authentication and authorization decisions and receives accounting records.

AAA Function	Question Answered	Examples
Authentication	Who are you?	Username/password, certificate, token, EAP identity
Authorization	What are you allowed to do?	Privilege, CLI command set, VLAN, downloadable policy
Accounting	What did you do?	Login start/stop, commands, session duration, byte counts

Important: Authentication must succeed before authorization makes sense. Accounting does not grant access; it records events for audit, operations, and troubleshooting.

2. TACACS+ and RADIUS

TACACS+ and RADIUS are centralized AAA protocols used to authenticate users or administrators, apply authorization policy, and record accounting information.

Both can work with an AAA platform such as Cisco ISE, but they are normally used for different operational purposes:

TACACS+ — commonly used for network-device administration
RADIUS — commonly used for network access, including 802.1X, WLAN, VPN, and NAC

Pasted content image

Figure 2. TACACS+ is commonly associated with network-device administration, while RADIUS is common for WLAN, VPN, and 802.1X network access.

Characteristic	TACACS+	RADIUS
Transport	TCP 49	UDP 1812 authentication/authorization; UDP 1813 accounting
Typical use	Router/switch/firewall administration	WLAN, VPN, 802.1X, subscriber/network access
AAA separation	Authentication, authorization, and accounting are independently controlled	Authentication and authorization are tightly coupled; accounting is separate
Protection	Encrypts the packet body; header remains visible	Classic RADIUS protects the user password attribute but not the entire packet body
Command authorization	Strong fit for granular per-command control	Less commonly used for CLI command authorization

Legacy RADIUS ports 1645/1646 can still appear in older environments. Modern deployments normally use 1812/1813. In production, protect the management path, use strong shared secrets, and prefer secure server-to-device connectivity.

2.1 TACACS+ Transaction Flow and Device-Administration Model

TACACS+ is optimized for administrator access to infrastructure devices. The router, switch, firewall, or controller acts as the TACACS+ client (AAA client/NAS), while the centralized server makes identity and policy decisions. TACACS+ uses TCP port 49, so session establishment, retransmission, and ordered delivery are handled by TCP.

The administrator starts an SSH session to the network device. The device accepts the transport connection but does not yet grant CLI access.
The device sends an authentication request to the TACACS+ server. The server can accept, reject, or continue the exchange to collect more information.
After successful authentication, the device can request EXEC authorization. The server may return the permitted shell/privilege context.
If command authorization is configured, the device can ask the TACACS+ server whether each privileged command is permitted before executing it.
Accounting records can be generated for EXEC start/stop events and for individual commands, giving an audit trail of who connected, when, and what they executed.

Important: In a method list such as "group tacacs+ local", the local method is normally tried when the TACACS+ method is unavailable or returns an error. A deliberate server rejection is not treated as permission to bypass policy with the local database.

2.2 TACACS+ Authentication, Authorization, and Accounting Detail

TACACS+ Stage	What the Device Sends / Requests	Typical Server Decision
Authentication	Username plus authentication exchange; device identifies the AAA service requested.	PASS / FAIL / continue the exchange.
EXEC authorization	Request to start an EXEC shell after login.	Permit shell access and optionally return privilege or service attributes.
Command authorization	Requested command and arguments when per-command authorization is enabled.	Permit or deny the command according to the user/group command set.
EXEC accounting	Start/stop records for the administrator session.	Server stores timestamp, device, username, source and session details.
Command accounting	Record of executed commands at the configured privilege level.	Server stores command audit information for operations/compliance.

TACACS+ protects the TACACS+ packet body using the configured shared secret while the protocol header remains visible. This provides stronger protection of AAA attributes than classic RADIUS, but it is not the same as a TLS-protected transport. Protect the management path itself and use strong secrets, device certificates where supported, and restricted source addresses.

2.3 TACACS+ Server Groups, Source Interface, Command Authorization, and Accounting

A production-oriented configuration normally creates explicit server objects, places them into a named server group, pins the source interface when the design requires a stable AAA source address, and uses named method lists for the VTY lines. The exact source-interface command can vary by software train; verify it on the target IOS/IOS XE release.

Illustrative TACACS+ device-administration configuration

aaa new-model

username breakglass privilege 15 secret <LOCAL-SECRET>

tacacs server ISE-TAC1

address ipv4 10.10.99.50

key <SHARED-SECRET>

aaa group server tacacs+ DEVICE-ADMIN

server name ISE-TAC1

! Optional when a stable AAA source address is required

ip tacacs source-interface Loopback0

aaa authentication login VTY-AUTH group DEVICE-ADMIN local

aaa authorization exec VTY-EXEC group DEVICE-ADMIN local if-authenticated

aaa authorization commands 15 VTY-CMDS group DEVICE-ADMIN local

aaa accounting exec VTY-ACCT start-stop group DEVICE-ADMIN

aaa accounting commands 15 VTY-CMD-ACCT start-stop group DEVICE-ADMIN

line vty 0 4

authorization exec VTY-EXEC

authorization commands 15 VTY-CMDS

accounting exec VTY-ACCT

accounting commands 15 VTY-CMD-ACCT

transport input ssh

Operational note: Per-command authorization is powerful but can lock out administrators if the server policy and device method lists do not match. Test with console access available, maintain a documented break-glass procedure, and validate both normal centralized access and failure-mode fallback.

2.4 RADIUS Message Flow, Attributes, and Policy Return

RADIUS is widely used when the user or endpoint is requesting network access rather than direct CLI administration. Common examples are 802.1X wired access, enterprise WLANs, remote-access VPNs, and other subscriber-style services. Modern RADIUS normally uses UDP 1812 for authentication/authorization and UDP 1813 for accounting.

RADIUS Message	Direction	Purpose
Access-Request	NAS / authenticator → RADIUS server	Carries identity, NAS information, EAP or password-related attributes, and context for the requested service.
Access-Challenge	RADIUS server → NAS / authenticator	Requests another authentication step; common during multi-step EAP exchanges.
Access-Accept	RADIUS server → NAS / authenticator	Authentication succeeds; can include authorization attributes such as VLAN, ACL/filter, role, timers, or vendor-specific policy.
Access-Reject	RADIUS server → NAS / authenticator	Authentication or policy fails; access is denied.
Accounting-Request	NAS → RADIUS server	Start, interim-update, or stop record describing the session.
Accounting-Response	RADIUS server → NAS	Acknowledges the accounting record.

RADIUS policy is carried in attributes (often called AVPs/attributes in operational discussion). Examples include User-Name, NAS-IP-Address, Service-Type, Filter-Id, session timeout values, tunnel/VLAN attributes, Class, and vendor-specific attributes such as Cisco AVPairs. A successful Access-Accept can therefore both authenticate the identity and tell the access device what policy to apply.

Classic RADIUS does not encrypt the complete packet body. The User-Password field is protected using the RADIUS shared-secret mechanism, but many other attributes remain visible. For enterprise WLANs, the EAP method itself can protect credentials end to end; EAP-TLS uses certificates and provides strong mutual authentication when certificate validation is correctly implemented.

2.5 RADIUS Configuration Patterns

Illustrative RADIUS device-login method

radius server ISE-RAD1

address ipv4 10.10.99.60 auth-port 1812 acct-port 1813

key <SHARED-SECRET>

aaa group server radius ACCESS-RADIUS

server name ISE-RAD1

ip radius source-interface Loopback0

! Example: RADIUS used for a named remote-login method

aaa authentication login REMOTE-LOGIN group ACCESS-RADIUS local

line vty 0 4

transport input ssh

Illustrative 802.1X AAA method references on a Catalyst switch

aaa new-model

aaa authentication dot1x default group ACCESS-RADIUS

aaa authorization network default group ACCESS-RADIUS

dot1x system-auth-control

The 802.1X lines above define the switch-side AAA methods; a complete 802.1X deployment also needs interface authentication settings, supplicant/EAP configuration, RADIUS policy, certificates for certificate-based EAP, and appropriate VLAN/authorization handling.

2.6 TACACS+ vs RADIUS - Detailed Decision Guide

Design Question	TACACS+	RADIUS
Primary design fit	Administrator control of routers, switches, firewalls, controllers and similar devices.	User/endpoint network access such as WLAN, 802.1X, VPN and subscriber access.
Transport	TCP 49.	UDP 1812 authentication/authorization; UDP 1813 accounting.
AAA separation	Authentication, authorization and accounting can be handled as distinct services/methods.	Authentication and authorization are closely coupled; accounting is separate.
Command authorization	Strong fit for per-command authorization and command sets.	Possible platform-specific device administration, but not the normal choice for granular CLI command control.
Policy return	Shell/privilege and command decisions are common.	Network access policy attributes such as VLAN, ACL/filter, role and session timers are common.
Transport behavior	Connection-oriented TCP session.	Connectionless UDP with application retries/timeouts.
Packet protection	Protects the TACACS+ body using the shared secret; header remains visible.	Classic RADIUS protects the password attribute rather than the complete packet body.
Typical troubleshooting clue	Authentication works but EXEC/command authorization fails → inspect command sets/method lists.	Access-Reject or timeout → inspect RADIUS reachability, secret, EAP method, certificate/policy, and returned attributes.

2.7 TACACS+ and RADIUS Troubleshooting Checklist

Symptom	Likely Cause	What to Check
AAA server shows no requests	Routing/source-interface/firewall problem.	Route to server, source IP, TCP 49 or UDP 1812/1813, ACL/firewall, VRF.
Timeouts	Server unreachable, wrong address/VRF, blocked transport, server overloaded.	show aaa servers; ping with correct source; transport reachability; server health.
Authentication reject	Credentials, identity store, policy or EAP/certificate failure.	Server live logs, username/certificate, policy rule, time/NTP.
TACACS login succeeds but shell is denied	EXEC authorization policy or method list mismatch.	EXEC authorization result, returned privilege/service, line configuration.
A single CLI command is denied	Per-command authorization/command-set policy.	Command set and arguments on TACACS+ server; privilege level; accounting log.
RADIUS Access-Accept but wrong VLAN/policy	Missing or incorrect returned authorization attributes.	Tunnel/VLAN attributes, Filter-Id/role, switch/WLC policy mapping.
Accounting records missing	Accounting method not configured or UDP 1813 blocked.	AAA accounting method, transport, server accounting service, session start/stop.

3. Configure AAA for Device Administration

A resilient design uses centralized AAA first and a local break-glass account only when the AAA server is unreachable. The local fallback is not intended to bypass a valid server rejection; it is a recovery mechanism for server or path failure.

TACACS+ example with local fallback

username breakglass privilege 15 secret <LOCAL-SECRET>

aaa new-model

tacacs server ISE-TACACS

address ipv4 10.10.99.50

key <SHARED-SECRET>

aaa authentication login default group tacacs+ local

aaa authorization exec default group tacacs+ local if-authenticated

aaa accounting exec default start-stop group tacacs+

line vty 0 4

authorization exec default

transport input ssh

The keyword default creates a default AAA method list. A named method list can instead be created and applied only to selected console or VTY lines.

Named RADIUS login method example

aaa authentication login REMOTE-LOGIN group radius local

radius server ISE-RADIUS

address ipv4 10.10.99.60 auth-port 1812 acct-port 1813

key <SHARED-SECRET>

line vty 0 4

4. AAA Verification and Troubleshooting

Command	What to Verify
show aaa servers	Server state, dead/alive status, counters
show tacacs	TACACS+ statistics and server communication
show radius statistics	RADIUS requests, responses, timeouts, failures
show users	Current EXEC/VTY sessions
show login	Login settings and failures
debug aaa authentication	Authentication method selection and result - use carefully
debug tacacs / debug radius	Protocol-level troubleshooting - use carefully in production

Troubleshoot from the transport layer upward: verify route and source interface → verify TCP/UDP reachability and shared secret → verify username or certificate identity → verify server policy → verify returned authorization attributes → verify accounting records.

Important: Before enabling aaa new-model remotely, confirm the local recovery account and console access path. A bad AAA policy can lock administrators out of the device.

5. IPsec VPN Fundamentals

IPsec is a suite of protocols used to protect IP traffic across an untrusted network such as the Internet. In a site-to-site VPN, the edge routers build a secure tunnel between two private networks. The original LAN traffic is protected before it crosses the WAN and is restored at the remote VPN gateway.

5.1. Why IPsec VPN?

Organizations often need to connect users, branches, data centers, and cloud networks across an untrusted network such as the Internet. Normal IP traffic does not automatically provide confidentiality, integrity, or peer authentication.

IPsec VPN solves this problem by creating a secure encrypted path between VPN peers.

Security property	What it means	How IPsec provides it
Confidentiality	Prevents unauthorized reading of user data.	ESP encryption, commonly using AES.
Integrity	Detects modification while the packet is in transit.	ESP integrity/authentication function.
Peer authentication	Confirms that the VPN gateway is the expected peer.	IKE/ISAKMP using a pre-shared key or certificates.
Anti-replay	Rejects old or duplicated protected packets.	Sequence numbers and the IPsec anti-replay window.

Figure 5. Site-to-site IPsec protects private LAN-to-LAN traffic while the public network sees only the outer tunnel packet.

6. IPsec Components and Parameters

A simple classic Cisco IOS site-to-site IPsec configuration has two negotiation stages. Phase 1 builds the secure IKE/ISAKMP control channel. Phase 2 builds the IPsec security associations that protect the actual data. The two peers must use compatible parameters.

Parameter	Example / command	Purpose	Peer relationship
ISAKMP policy priority	crypto isakmp policy 10	Selects the Phase 1 policy. Lower policy numbers are checked first on the local router.	Does not have to use the same policy number.
Encryption	encryption aes 256	Encrypts the Phase 1 control exchange.	Must be compatible on both peers.
Hash / integrity	hash sha	Provides integrity for the Phase 1 negotiation.	Must be compatible on both peers.
Authentication	authentication pre-share	Defines how the peers authenticate each other.	Must be compatible on both peers.
Diffie-Hellman group	group 14	Creates shared keying material without sending the secret itself across the network.	Must be compatible on both peers.
Phase 1 lifetime	lifetime 86400	How long the IKE/ISAKMP SA is valid before renegotiation.	Peers negotiate an acceptable lifetime.
Pre-shared key	crypto isakmp key CCNAKEY address <peer>	Shared secret used to authenticate the peer.	The secret must match; peer address is the opposite router.
Interesting traffic ACL	permit ip 10.10.10.0 ... 10.20.20.0 ...	Defines which private traffic should be protected by IPsec.	ACLs are mirror images on the two peers.
Transform set	crypto ipsec transform-set CCNA-SET esp-aes 256 esp-sha-hmac	Defines Phase 2 ESP encryption/integrity algorithms.	Must be compatible on both peers.
Tunnel mode	mode tunnel	Protects the entire original IP packet and adds a new outer IP header.	Typical for site-to-site VPN gateways.
Crypto map sequence	crypto map CCNA-MAP 10 ipsec-isakmp	Creates one crypto-map entry and ties peer, transform set, and ACL together.	Sequence numbers are local.
Peer address	set peer 198.51.100.2	Identifies the public IP of the remote VPN gateway.	Each router points to the other router.
Match address	match address VPN-TRAFFIC	Links the interesting-traffic ACL to the crypto map.	ACLs must describe opposite local/remote directions.
Apply crypto map	crypto map CCNA-MAP	Activates IPsec processing on the WAN-facing interface.	Applied on each VPN gateway WAN interface.
Security Association (SA)	show crypto ipsec sa	One-way set of keys, algorithms, counters, and protection state.	Bidirectional traffic uses inbound and outbound SAs.
SPI	Shown in show crypto ipsec sa	Identifier used by the receiver to select the correct inbound SA.	Different for each SA/direction.
IKE / ISAKMP transport	UDP 500	Carries Phase 1 peer negotiation.	Must be permitted through intermediate devices.
NAT Traversal	UDP 4500	Carries IPsec when NAT is detected between the peers.	Used only when NAT-T is required.
ESP	IP protocol 50	Carries the protected user traffic when NAT-T is not encapsulating ESP in UDP 4500.	Must be permitted end to end.

6.1 Phase 1 - IKE/ISAKMP

R1 and R2 first reach each other using their public WAN addresses.

The peers compare the ISAKMP policy: encryption, hash, authentication method, Diffie-Hellman group, and lifetime.

The pre-shared key authenticates the peer.

If the parameters are compatible, the routers create the IKE/ISAKMP security association. This secure control channel is then used to negotiate IPsec protection.

6.2 Phase 2 - IPsec SA Negotiation

The VPN ACL identifies the interesting traffic that should be encrypted.

The peers compare the transform set, which defines the ESP encryption and integrity algorithms.

The routers create inbound and outbound IPsec SAs. Each direction has its own SA and SPI.

After Phase 2 is complete, matching traffic is protected with ESP and sent through the tunnel.

7. Site-to-Site IPsec Packet Flow

1. A host on LAN-A sends a packet to a host on LAN-B.

2. R1 routes the packet toward the WAN and checks the VPN ACL. If the packet matches, it is considered interesting traffic.

3. If no IKE/ISAKMP SA exists, R1 and R2 perform Phase 1 and authenticate each other.

4. Phase 2 negotiates the transform set and creates the IPsec SAs for the protected traffic.

5. R1 encapsulates the original packet with ESP in tunnel mode, encrypts/authenticates it, and adds the new outer IP header.

6. R2 receives the protected packet, uses the SPI to identify the inbound SA, validates/decrypts it, and removes the IPsec/outer headers.

7. R2 routes the restored original packet to LAN-B. Return traffic follows the reverse process and uses the reverse-direction SA.

8. Site-to-Site IPsec Configuration - Side by Side

Pasted content image

Example addressing: LAN-A 10.10.10.0/24 behind R1, LAN-B 10.20.20.0/24 behind R2, R1 public 203.0.113.1/30, and R2 public 203.0.113.1/30. The configuration below is intentionally simple and uses the classic crypto-map model so each IPsec parameter is easy to identify.

R1 - HQ / LAN-A

R2 - Branch / LAN-B

! R1 - LAN-A side

interface GigabitEthernet0/0

ip address 10.10.10.1 255.255.255.0

no shutdown

interface GigabitEthernet0/1

ip address 203.0.113.1 255.255.255.252

no shutdown

crypto isakmp policy 10

encryption aes 256

hash sha

authentication pre-share

group 14

lifetime 86400

crypto isakmp key CCNAKEY address 198.51.100.2

ip access-list extended VPN-TRAFFIC

permit ip 10.10.10.0 0.0.0.255 10.20.20.0 0.0.0.255

crypto ipsec transform-set CCNA-SET esp-aes 256 esp-sha-hmac

mode tunnel

crypto map CCNA-MAP 10 ipsec-isakmp

set peer 198.51.100.2

set transform-set CCNA-SET

match address VPN-TRAFFIC

interface GigabitEthernet0/1

crypto map CCNA-MAP

ip route 10.20.20.0 255.255.255.0 198.51.100.2

! R2 - LAN-B side

interface GigabitEthernet0/0

ip address 10.20.20.1 255.255.255.0

no shutdown

interface GigabitEthernet0/1

ip address 203.0.113.2 255.255.255.252

no shutdown

crypto isakmp policy 10

encryption aes 256

hash sha

authentication pre-share

group 14

lifetime 86400

crypto isakmp key CCNAKEY address 198.51.100.1

ip access-list extended VPN-TRAFFIC

permit ip 10.20.20.0 0.0.0.255 10.10.10.0 0.0.0.255

crypto ipsec transform-set CCNA-SET esp-aes 256 esp-sha-hmac

mode tunnel

crypto map CCNA-MAP 10 ipsec-isakmp

set peer 198.51.100.1

set transform-set CCNA-SET

match address VPN-TRAFFIC

interface GigabitEthernet0/1

crypto map CCNA-MAP

ip route 10.10.10.0 255.255.255.0 198.51.100.1

8.1 How the Configuration Pieces Fit Together

Configuration section	What it controls
crypto isakmp policy 10	Phase 1 security proposal: AES-256, SHA, pre-shared key authentication, DH group 14, lifetime.
crypto isakmp key ... address ...	Authenticates the opposite VPN peer using the shared secret.
VPN-TRAFFIC ACL	Defines which private LAN-to-LAN traffic should be encrypted.
crypto ipsec transform-set	Defines the Phase 2 ESP protection used for user traffic.
crypto map	Binds the remote peer, transform set, and interesting-traffic ACL into one VPN policy.
crypto map applied to WAN interface	Activates the policy on the interface where protected traffic leaves/enters the router.
Static route to remote LAN	Ensures the router knows how to reach the remote protected network through the peer path.

9. IPsec Verification and Troubleshooting

Command	What to verify
show crypto isakmp sa	Phase 1/IKE peer SA. In a working classic IKEv1 tunnel, QM_IDLE is a common healthy state after Phase 2 completes.
show crypto ipsec sa	Local/remote protected subnets, peer, SPIs, transforms, and encaps/decaps counters.
show crypto map	Peer, transform set, crypto ACL, sequence number, and interface association.
show access-lists VPN-TRAFFIC	Whether the interesting-traffic ACL has matches.
show ip route <remote-LAN>	Whether the remote protected network is routed toward the correct peer path.
ping <remote-host> source <inside-interface>	Generates matching traffic and tests the tunnel end to end.

Symptom	Likely cause / first checks
No ISAKMP SA	Check public peer reachability, UDP 500, peer IP, pre-shared key, and Phase 1 parameter mismatch.
ISAKMP SA forms but no IPsec SA	Check VPN ACL mirror logic, transform set compatibility, crypto map, and whether interesting traffic is being generated.
Encaps increase; decaps stay zero	Check remote peer return route, reverse crypto ACL, remote crypto map, NAT, and firewall/ESP handling.
Decaps increase; traffic still fails	Check inside routing, host firewall, gateway settings, and application policy on the destination LAN.
Tunnel works for small packets only	Check MTU/fragmentation and whether the WAN path handles the added IPsec overhead correctly.
Tunnel fails through NAT	Check NAT-T/UDP 4500 and confirm intermediate devices do not block the negotiation.

Important: Routing, NAT, ACLs/firewalls, and the return path are outside the cryptographic negotiation but can still prevent traffic from using a tunnel that otherwise appears healthy.

10. WLAN Security Fundamentals

Wireless networks require additional security because traffic is transmitted over radio frequencies and can be received by any compatible device within range. WLAN security therefore focuses on controlling who can connect, authenticating users or devices, encrypting wireless traffic, protecting management frames, and separating users according to security policy.

A secure WLAN normally combines:

Authentication — verifies the identity of a user or device.
Encryption — protects wireless traffic from being read by unauthorized users.
Integrity protection — detects modification of wireless frames.
Access control — determines what authenticated users are permitted to access.
Segmentation — separates corporate, guest, IoT, and other user groups.
Management-frame protection — helps protect important 802.11 management traffic.

Pasted content image

Figure 6. Wireless security evolved from weak legacy mechanisms to WPA2/WPA3 with modern encryption, stronger authentication, and management-frame protection.

Security Mode	Authentication	Encryption / Protection	Operational Note
Open	None	None	No confidentiality; use only with intentionally open access and external controls
WEP	Static/shared key	RC4	Cryptographically broken; obsolete
WPA	PSK or Enterprise	TKIP	Legacy transition technology; obsolete
WPA2-Personal	PSK	AES-CCMP	Shared passphrase; simple but not per-user
WPA2-Enterprise	802.1X/EAP	AES-CCMP	Centralized identity with RADIUS
WPA3-Personal	SAE	Modern WPA3 protection	Resists offline dictionary attacks better than PSK
WPA3-Enterprise	802.1X/EAP	Stronger enterprise security modes	Designed for centrally managed enterprise identity; PMF required

11. 802.1X, EAP, and RADIUS for Enterprise WLANs

Enterprise WLANs normally require individual user or device authentication rather than a shared wireless password. 802.1X, EAP, and RADIUS work together to provide centralized authentication, authorization, and policy control before a wireless client receives normal network access.

The three technologies perform different roles:

Technology	Purpose
802.1X	Controls whether a client is allowed to use the network
EAP	Carries the authentication method and credentials between the client and authentication system
RADIUS	Provides centralized AAA services and returns access policy to the AP/WLC

Pasted content image

Figure 11. The client is the supplicant, the AP/WLC is the authenticator, and the RADIUS server is the authentication server.

Role	Function
Supplicant	Wireless client software that presents credentials and participates in EAP.
Authenticator	AP/WLC controls the port/session and relays EAP between the client and authentication server.
Authentication server	RADIUS validates the identity and returns an accept/reject decision and optional policy attributes.
EAP	Framework that carries the authentication exchange. EAP-TLS, PEAP, and other methods define how credentials are protected and validated.

EAP-TLS uses certificates for strong mutual authentication. Other EAP methods can use tunneled usernames/passwords. Certificate validation is critical because users should not trust an unverified authentication server presented by an evil-twin network.

12. WPA2/WPA3 Key Establishment and the 4-Way Handshake

After the client has a Pairwise Master Key (PMK), the 4-way handshake proves both sides possess the PMK and derives fresh per-session keys without transmitting the PMK itself. In WPA2-Personal the PMK comes from the PSK; in Enterprise WLANs the PMK is derived from the successful 802.1X/EAP authentication.

Term	Meaning
PMK	Master key material derived from the PSK/SAE process or 802.1X/EAP result.
PTK	Pairwise Transient Key derived per client/AP association; protects unicast data.
GTK	Group Temporal Key used for broadcast/multicast traffic in the WLAN.
Nonce	Random value used during key derivation so each session produces fresh keys.
PMF / 802.11w	Protects selected management frames from forgery; required with WPA3.

13. WLAN Threats and Mitigations

Wireless networks are exposed to threats that do not exist in the same way on a purely wired network because 802.11 traffic travels through the air. An attacker within radio range may attempt to observe traffic, impersonate a legitimate WLAN, disrupt client connectivity, steal credentials, or gain unauthorized access.

WLAN security therefore combines strong authentication, encryption, management-frame protection, monitoring, segmentation, and centralized policy enforcement.

Threat	Description	Mitigation
Rogue AP	Unauthorized AP connected to the enterprise network	WIDS/WIPS, switch port controls, asset monitoring
Evil twin	Attacker imitates a legitimate SSID to steal credentials or traffic	Validate server certificates, WPA2/WPA3 Enterprise, user awareness
Weak PSK	Shared password is guessed or widely distributed	Long random passphrases, WPA3-SAE, Enterprise 802.1X
De-authentication/disassociation abuse	Forged management frames disrupt clients	Protected Management Frames (PMF)
Credential theft	Users submit credentials to an untrusted authentication service	Certificate-based EAP or strict RADIUS certificate validation
Lateral movement	Authenticated client reaches systems it should not access	VLAN/VRF segmentation, ACL/firewall policy, identity-based access controls

14. Secure WLAN Implementation Workflow

Create the WLAN/SSID and map it to the intended client VLAN or policy profile.
Select WPA2/WPA3 security. For enterprise authentication, enable 802.1X/EAP and configure the RADIUS server.
Configure strong RADIUS shared secrets and ensure routing, DNS, NTP, and certificate trust are correct.
Enable PMF according to the WPA mode and client capabilities; WPA3 requires PMF.
Validate the client authentication exchange, assigned policy/VLAN, DHCP address, DNS resolution, and application reachability.
Monitor authentication failures, rogue/evil-twin events, and repeated deauthentication behavior.
Common Catalyst 9800 verification commands

show wlan summary

show wireless client summary

show aaa servers

show logging

Important: WLAN configuration syntax varies by controller platform and software release. For CCNA study, focus on the security roles, packet flow, authentication method, and verification logic rather than memorizing one controller GUI or CLI sequence.

Quick knowledge check

1. What security feature protects selected 802.11 management frames?

Answer: Protected Management Frames (PMF / 802.11w).

2. What does the ESP SPI identify?

Answer: The inbound IPsec Security Association used to process the packet.

3. If IPsec encapsulation counters increase but decapsulation counters remain zero, what should you suspect first?

Answer: The remote side is not returning protected traffic; check remote routing/policy/selectors, upstream filtering/NAT, and return path.

4. Which WLAN security mode uses SAE?

Answer: WPA3-Personal.