Security is not something that stops at the wireless edge. It should be considered at every layer of the network—including physical security. This chapter summarizes a number of non-802.11-specific security measures that are still very relevant in the WLAN landscape.
VPN Basics
When you think of security, chances are high that a Virtual Private Network (VPN) also comes to mind. VPNs are used across many different networking scenarios, including Wi-Fi. Since they’re IP-based, they mostly operate at the Network Layer (Layer 3) of the OSI model. That said, VPN is actually more of a collective term. It can include several protocols, some of which operate at other OSI layers as well. Examples include PPTP, IPsec, L2TP/IPsec, TLS, SSL, SSH, and DTLS.
The general VPN concept includes two main components: a tunneling mechanism and an encryption mechanism. It’s important to know that the tunnel itself doesn’t necessarily provide encryption. You can think of it like this: the tunnel is the vehicle, and encryption is like tinted windows—you can’t see who or what is inside. Without the encryption layer, the tunnel still gets your traffic from A to B, but anyone looking in could read the data.
VPN Protocols
Circling back to the VPN protocols, I’ll start with PPTP. This protocol existed even before Wi-Fi, so it’s very old. PPTP uses Microsoft Point-to-Point Encryption (MPPE-128) for encryption and MS-CHAP for authentication. It operates on Layer 2 and is based on Generic Routing Encapsulation (GRE) tunneling to encapsulate PPP packets. It is advised to not use this legacy protocol as it has been cracked. The user credentials can be discovered through packet capture analysis.
Next up we have L2TP, a combination of Cisco’s Layer 2 Forwarding (L2F) and Microsoft’s PPTP. L2TP defines the tunneling process but doesn’t offer encryption by itself—it simply creates a secure path over an insecure network. That’s why it’s typically paired with IPSec, which handles the encryption. IPSec is a much more secure alternative to legacy PPTP, which has known vulnerabilities and weak encryption methods that can be exploited with minimal effort. By contrast, IPSec provides robust protection by authenticating and encrypting each individual IP packet in the data stream, making it a highly recommended replacement.
IPSec can be implemented in two ways: using the Authentication Header (AH) protocol, which provides only authentication and integrity, or using the Encapsulation Security Payload (ESP), which adds confidentiality through encryption in addition to authentication. ESP is the go-to choice in most deployments and comes with two operation modes: transport mode and tunnel mode. In transport mode, the encryption is applied only to the payload of the IP packet, and the original IP headers are left intact. It’s typically used when another tunneling protocol like GRE or L2TP is handling the encapsulation. In tunnel mode, the entire IP packet (header and payload) is encrypted and encapsulated within a new IP packet by the IPSec peers themselves.
For example, in a site-to-site VPN setup between two gateways, tunnel mode is used so that the entire original packet is hidden and protected across the public internet.
VPN Use Cases in Wireless Environments
When it comes to securing Wi-Fi environments, CWSP candidates should be familiar with three main VPN use cases: Remote APs, Wireless Bridging, and Remote Client Connectivity.
1) Remote APs
Remote APs are often used in home offices or small branch offices where just a handful of users need to connect to the corporate network. In this setup, the remote AP sets up a VPN tunnel back to the headquarters’ WLAN controller—typically over the public internet. This ensures that all traffic between the AP and the controller is encrypted.
The most common protocol used for this is IPSec, offering a good balance between performance and security. Sure, there’s some overhead involved, but when you’re transmitting sensitive corporate data over the internet, the added security is usually worth the tradeoff.
2) Wireless Bridging
The second use case—wireless bridging—is a bit more specialized. Think of this as a site-to-site connection over RF instead of a traditional wired link. A bridge connects two wired networks over a wireless link, and since RF travels through open air, this connection must be encrypted to prevent unauthorized interception.
This kind of deployment often relies on proprietary VPN or encryption technologies, which are usually enabled by default when setting up this type of wireless link. Even if it’s a short-range point-to-point bridge, remember: RF has no boundaries, and that makes encryption a must.
3) Remote Client Connectivity (Teleworkers)
This is probably the most familiar use case—remote client VPNs, like the ones your company laptop (or even your spouse’s device) uses to connect securely when you’re working from home or a coffee shop. This VPN tunnel protects client traffic on untrusted or public networks.
A trusted endpoint VPN client ensures that your data is encapsulated, encrypted, and secure from prying eyes—even on open Wi-Fi. It’s an essential security measure in today’s remote-first world.
Remote VPN clients are usually configured in one of two modes:
- Full Tunnel Mode: All client traffic, including internet-bound traffic, is routed through the VPN tunnel to the corporate network. This is the most secure option, especially on untrusted networks.
- Split Tunnel Mode: Only traffic destined for internal corporate resources goes through the tunnel. Internet-bound traffic is sent directly to the internet. This approach lightens the load on the VPN infrastructure but does come with a slight tradeoff in security.
Public Access Risks
Using public Wi-Fi networks—like those at your local coffee shop—comes with more risks than just having your traffic sniffed by someone nearby. One major concern is that you’re likely on the same VLAN as every other guest, which means a malicious user could potentially reach your device directly at Layer 2.
Enterprise-grade gear typically allows you to block client-to-client communication, and you should absolutely enable that option when available. This traffic still passes through the AP, so it’s not as harmless as some might think. Unfortunately, in public or small business setups, the network is often running on an ISP-provided router or a cheap consumer-grade access point, which may not support this feature at all.
Since you can’t control how these public networks are configured, there are steps you can (and should) take to protect yourself:
- Install and regularly update antivirus software.
- Enable and configure your firewall properly (e.g., Windows Defender).
- Keep your operating system up to date.
- Avoid using open or unsecured file shares.
- Use strong, unique login credentials.
- Only install apps from trusted sources.
- Use a VPN to encrypt your data over the air.
Following these practices can significantly reduce your exposure to threats on public networks. It’s also on us to help educate our colleagues, friends, and clients—because sometimes, just a little awareness can go a long way in staying safe out there.
Captive Portals
One common misconception is that captive portals provide security just because you have to “log in.” I assume most readers here already have some background in Wi-Fi and networking, but if you happen to be that one curious person just casually reading this: Captive portals (also known as Wi-Fi login portals or splash pages) do not equal security.
All the risks we discussed in the previous section about public access networks still apply here. Captive portals do not offer wireless encryption. They might control initial access to the network by requiring authentication, but once you’re past that step—you’re in. No encryption is added during that process.
Captive portals are mostly used for legal disclaimers, to present terms and conditions, or to place Wi-Fi access behind a paywall. They can also be layered on top of WPA2-Personal SSIDs, but if the password is shared with everyone and printed on the wall, the real security benefit is minimal.
That said, there is a solid use case where captive portals do play a role in improving security: onboarding. Think of an open SSID with a registration portal that collects some user data and then issues a unique login or credential for a secure SSID. That second SSID—secured with WPA2-Enterprise or PPSK—does provide proper encryption. The open captive portal is just the first step to getting there.
Network Segmentation
One of the most effective and recommended practices in WLAN security is network segmentation. This typically means assigning different VLANs to different SSIDs—for example, separating guest traffic from corporate devices. But with today’s more advanced network infrastructure, we’re not limited to static VLAN assignments anymore.
Modern systems allow for dynamic VLAN assignment, where users can be placed into different VLANs even within the same SSID, based on criteria such as location, device type, user identity, or 802.1X access policies. This way, a BYOD device from an unknown user might end up in VLAN Z, while an authenticated domain-joined laptop ends up in VLAN A—all without broadcasting separate SSIDs. This kind of segmentation helps prevent Layer 2 client-to-client threats, like an unauthorized device snooping or launching attacks on the same subnet.
If client-to-client communication is needed—for example, file sharing or printing between employees—this traffic is forced to go through a Layer 3 device, like a router or firewall. That’s where access control policies can be enforced more tightly, rather than letting it slide through unchecked over Layer 2.
A classic example of why this matters is when you have legacy devices—think of those old handheld barcode scanners that only support WEP. If those devices are dumped into the same VLAN as your iPads or laptops, someone who cracks the WEP SSID could potentially access your high-value assets directly on Layer 2. That’s why it’s a best practice to isolate these kinds of devices in their own segmented VLAN with heavily restricted access. Just because something still technically “works” doesn’t mean it should live in the same neighborhood as your production systems.
Security design isn’t just a checkbox item — it’s a layered process, and this chapter made that pretty clear. From VPNs to network segmentation, public Wi-Fi risks to client isolation, we’re moving beyond just 802.11 and into the broader landscape of securing a WLAN environment properly. Not everything is new or complex, but it’s all about knowing what tools to use, where to use them, and why.
There’s always going to be a tradeoff between convenience and control — our job is to make sure that balance doesn’t come at the expense of exposure.
Thanks for reading, and see you in Chapter 8 where things start to get a little more RF-flavored again.
Source(s):
Carpenter, T., et al. (2023). CWSP-207: Certified Wireless Security Professional Study Guide (1st ed.). Durham NC, USA: Certitrek Publishing