This chapter covers Virtual Private Networks (VPNs) and remote access technologies, a core topic in CompTIA Network+ N10-009 Objective 4.4. VPNs enable secure communication over public networks by creating encrypted tunnels, and remote access VPNs allow individual users to connect to corporate networks from anywhere. Expect 5–10% of exam questions to touch on VPN types, protocols, encryption, and authentication. Mastery of this topic is critical for network security and troubleshooting scenarios on the exam.
Jump to a section
Imagine a company with two offices connected by a public highway (the Internet). Without a VPN, any data sent between them is like sending a postcard through the mail—anyone handling it can read the message. A VPN creates a secure, encrypted tunnel through the highway, like a private armored car with a sealed container. The armored car (VPN gateway) picks up the cargo (data packets) from the sending office, locks it in a container (encryption), and drives through the highway. Even if the car is stopped or observed, the cargo is unreadable. At the receiving office, the container is unlocked (decryption) and the cargo is delivered. The tunnel is established using cryptographic keys exchanged beforehand (IKE handshake) and uses protocols like IPsec or SSL to ensure confidentiality, integrity, and authentication. The armored car's route is hidden—intermediate routers only see the car's outer address (encapsulated IP), not the actual cargo. If the car is tampered with, the seal breaks (integrity check fails) and the cargo is discarded. This is how a VPN provides a logical point-to-point link over an untrusted network, making remote sites appear as if they are directly connected.
What is a VPN and Why Does It Exist?
A Virtual Private Network (VPN) extends a private network across a public network, such as the Internet. It enables users to send and receive data as if their devices were directly connected to the private network, despite being physically remote. VPNs are essential for secure remote access, site-to-site connectivity, and protecting data in transit from eavesdropping, tampering, and impersonation.
The need for VPNs arises from the inherent insecurity of the Internet. Data traversing the Internet passes through multiple routers and links, any of which could be compromised. VPNs address this by providing: - Confidentiality: Encryption ensures data cannot be read by unauthorized parties. - Integrity: Hashing ensures data has not been modified in transit. - Authentication: Verifies the identity of communicating parties. - Anti-replay: Prevents attackers from capturing and retransmitting valid packets.
How VPNs Work: The Tunnel Mechanism
A VPN creates a tunnel—a logical connection between two endpoints that encapsulates the original packet within a new packet. The original packet is encrypted and wrapped with a new header that routes it through the tunnel. The process involves: 1. Encapsulation: The original IP packet (including payload and headers) is encapsulated inside a VPN protocol packet (e.g., IPsec ESP or SSL record). 2. Encryption: The original packet is encrypted using symmetric encryption (e.g., AES-256). The encryption key is derived from a key exchange (e.g., Diffie-Hellman). 3. Authentication: A hash (e.g., HMAC-SHA256) is computed over the encrypted data to ensure integrity. 4. Transmission: The new packet is sent over the public network. Intermediate routers see only the outer headers (the tunnel endpoints), not the original source/destination or payload. 5. Decapsulation: At the receiving VPN endpoint, the outer header is stripped, integrity is verified, the packet is decrypted, and the original packet is forwarded to the destination.
Key VPN Components and Protocols
VPN Types: - Site-to-Site VPN: Connects entire networks (e.g., branch office to headquarters). Typically uses IPsec or GRE over IPsec. Both endpoints are VPN gateways (routers/firewalls). - Remote Access VPN: Connects individual users to a corporate network. Uses IPsec, SSL/TLS (SSL VPN), or PPTP (obsolete). The client is software on the user's device. - Client-to-Site VPN: A subset of remote access, often used interchangeably.
Protocols and Standards: - IPsec (Internet Protocol Security): A suite of protocols defined in RFC 4301. Operates in two modes: - Transport Mode: Encrypts only the payload (used for end-to-end communication). - Tunnel Mode: Encrypts the entire IP packet (used for VPN gateways). IPsec uses two sub-protocols: - AH (Authentication Header, RFC 4302): Provides integrity and authentication but no encryption. Rarely used alone. - ESP (Encapsulating Security Payload, RFC 4303): Provides encryption, integrity, and authentication. Most common. - IKE (Internet Key Exchange, RFC 7296): Handles key exchange and negotiation of security associations (SAs). Uses UDP port 500 and 4500 (for NAT traversal). - SSL/TLS VPN: Uses the same encryption as HTTPS (TLS 1.2/1.3). Client typically uses a web browser or a lightweight client. No need for pre-installed client software; often used for remote access. Port 443 (TCP). - PPTP (Point-to-Point Tunneling Protocol): Obsolete due to weak encryption (MPPE, 128-bit RC4). Not recommended. - L2TP/IPsec (Layer 2 Tunneling Protocol over IPsec): Combines L2TP (for tunneling) with IPsec (for encryption). Common in Windows and legacy systems. Uses UDP 1701 for L2TP and UDP 500/4500 for IPsec. - GRE (Generic Routing Encapsulation, RFC 2784): A simple tunneling protocol that can encapsulate a wide variety of protocols. Often used with IPsec for encryption (GRE over IPsec). No encryption by itself. - OpenVPN: Open-source SSL VPN. Highly configurable, uses TLS for key exchange and can run over UDP or TCP (default port 1194). - WireGuard: Modern VPN protocol using state-of-the-art cryptography (ChaCha20, Poly1305, Curve25519). Simpler, faster, and more secure than IPsec. Uses UDP port 51820. Not yet widely tested on N10-009 but gaining traction.
Encryption and Authentication Algorithms: - Symmetric Encryption: AES (128, 192, 256-bit), 3DES (obsolete), ChaCha20 (WireGuard). - Hashing/Integrity: HMAC-SHA256, HMAC-SHA1 (deprecated), Poly1305 (WireGuard). - Key Exchange: Diffie-Hellman (DH) groups (e.g., DH14, DH21), Elliptic Curve Diffie-Hellman (ECDH). - Authentication: Pre-shared keys (PSK), digital certificates (X.509), EAP (for remote access).
Configuration and Verification Commands
Cisco IOS (Site-to-Site IPsec VPN):
crypto isakmp policy 10
authentication pre-share
encryption aes 256
hash sha256
group 14
lifetime 86400
crypto isakmp key mykey address 203.0.113.1
crypto ipsec transform-set MYTRANSFORM esp-aes 256 esp-sha256-hmac
crypto map MYMAP 10 ipsec-isakmp
set peer 203.0.113.1
set transform-set MYTRANSFORM
match address 100
interface GigabitEthernet0/0
crypto map MYMAP
access-list 100 permit ip 10.0.1.0 0.0.0.255 10.0.2.0 0.0.0.255Verification Commands:
- show crypto isakmp sa – Displays IKE phase 1 security associations.
- show crypto ipsec sa – Displays IPsec phase 2 security associations, including packet encryption/decryption stats.
- show crypto map – Displays crypto map configuration.
- ping from behind the VPN to test connectivity.
- debug crypto ipsec – For troubleshooting (use with caution in production).
Windows Remote Access Client:
Built-in VPN client supports PPTP, L2TP/IPsec, SSTP (SSL), and IKEv2.
Configure via Settings > Network & Internet > VPN > Add a VPN connection.
Use netsh for scripting: netsh wlan show profiles for wireless, but for VPN: netsh ras show config.
How VPNs Interact with Related Technologies
NAT Traversal (NAT-T): IPsec packets are incompatible with NAT because the integrity check (hash) covers the source IP address. NAT-T adds a UDP encapsulation (UDP 4500) to allow IPsec through NAT devices. Detected automatically by IKE.
Firewalls: VPN traffic must be permitted through firewalls. IPsec uses ports 500 (IKE), 4500 (NAT-T), and IP protocols 50 (ESP) and 51 (AH). SSL VPN uses TCP 443.
Routing: VPNs create virtual interfaces (e.g., tun0 in Linux). Routes must be added to direct traffic through the tunnel. Split tunneling allows only corporate traffic to go through the VPN, while Internet traffic goes directly. Full tunneling sends all traffic through the VPN.
DNS: VPN clients often receive DNS server addresses from the VPN server to resolve internal resources. Split DNS can be configured to forward only internal domains to the VPN DNS.
AAA (Authentication, Authorization, Accounting): Remote access VPNs integrate with RADIUS or LDAP for user authentication. Accounting logs are used for auditing.
Default Values and Timers
IKE Phase 1 Lifetime: Default 86,400 seconds (24 hours). Shorter lifetimes increase security but require more frequent rekeying.
IKE Phase 2 Lifetime: Default 28,800 seconds (8 hours) or 4,608 MB of traffic, whichever comes first.
DH Group: Group 2 (1024-bit) is common but weak; Group 14 (2048-bit) or higher recommended.
IPsec SA Idle Timeout: Varies; often 5-30 minutes of no traffic before teardown.
SSL VPN Idle Timeout: Typically 10-30 minutes.
Advanced Concepts
Split Tunneling: Only routes specific subnets through the VPN. Reduces bandwidth usage but can expose traffic if the client is compromised. Exam may ask about security implications.
Full Tunneling: All traffic goes through the VPN. More secure but higher latency and bandwidth consumption.
VPN Concentrator: A dedicated device that handles multiple remote access VPN connections. Scales to thousands of users.
DMVPN (Dynamic Multipoint VPN): Cisco proprietary technology that allows dynamic spoke-to-spoke tunnels without a full mesh. Uses mGRE (multipoint GRE) and NHRP (Next Hop Resolution Protocol).
GETVPN (Group Encrypted Transport VPN): Cisco solution for IP multicast over MPLS. Uses a single SA for all group members.
Common Exam Traps
PPTP vs. L2TP/IPsec: PPTP uses MPPE (RC4), which is weak. L2TP/IPsec is more secure. Exam may ask which is more secure.
IPsec Modes: Transport mode encrypts only payload; tunnel mode encrypts entire packet. Site-to-site VPNs use tunnel mode; host-to-host may use transport.
GRE: Encapsulates but does not encrypt. Often paired with IPsec. Exam may ask about its lack of encryption.
SSL VPN: Does not require a pre-installed client; uses a web browser. Ideal for remote access from untrusted devices.
IKE Ports: UDP 500 for main, UDP 4500 for NAT-T. ESP is IP protocol 50, AH is IP protocol 51.
Authentication Methods: Pre-shared keys are simple but less secure than certificates. Certificates require a PKI.
Performance Considerations
Encryption Overhead: AES-256 is computationally intensive but hardware-accelerated in modern CPUs. Older devices may struggle.
MTU Issues: Encapsulation adds headers (e.g., IPsec adds ~50-100 bytes). Can cause fragmentation. Set MTU to 1400 or enable MSS clamping.
Latency: Encryption/decryption adds microseconds; tunneling adds round-trip time. Satellite links exacerbate.
Concurrent Connections: VPN concentrators have limits (e.g., 500-10,000 sessions). Exceeding causes dropped connections.
Troubleshooting
No Traffic Passes: Check firewall rules, IKE/ESP ports, and crypto maps. Verify IPsec SAs with show crypto ipsec sa.
Intermittent Drops: Check lifetime timers; rekeying may cause brief outages. Check for NAT-T issues if behind NAT.
Authentication Failures: Verify pre-shared keys or certificate trust chains. Check time synchronization (NTP) for certificates.
MTU Issues: Symptoms include large packets failing. Use ping -f -l 1472 to test. Reduce MTU on tunnel interface.
Trigger VPN Connection Initiation
The VPN connection begins when a client or gateway decides to establish a tunnel. For remote access, the user launches VPN client software or the OS initiates a connection. For site-to-site, traffic matching an interesting traffic ACL triggers the VPN. The initiator (IKE peer) starts by sending an IKE SA (Security Association) proposal to the responder. This proposal includes encryption algorithms, hash algorithms, authentication methods, and Diffie-Hellman groups. The responder checks its policy and if a match is found, it replies with an accepted proposal. This phase is IKE Phase 1 (Main Mode or Aggressive Mode). The initiator uses UDP port 500. At the packet level, the first packet contains the proposal in an ISAKMP header. A network engineer would see UDP 500 traffic and, using Wireshark, could filter `isakmp` to observe the negotiation.
IKE Phase 1: Key Exchange and Authentication
After agreeing on parameters, the two peers perform a Diffie-Hellman key exchange to generate a shared secret. This secret is used to derive encryption and authentication keys for the IKE SA. The peers then authenticate each other using pre-shared keys or certificates. In Main Mode, six messages are exchanged: (1) proposal, (2) acceptance, (3) DH public key, (4) DH public key, (5,6) authentication. Aggressive Mode uses three messages but is less secure (no identity protection). The result is an IKE SA (ISAKMP SA) that protects further negotiations. The default lifetime is 86,400 seconds. A network engineer can verify with `show crypto isakmp sa`; a state of `MM_ACTIVE` indicates Phase 1 is complete.
IKE Phase 2: IPsec SA Negotiation
With the secure IKE SA established, Phase 2 (Quick Mode) negotiates the IPsec SAs that will encrypt the actual data. The initiator sends proposals for the IPsec transform set (e.g., ESP with AES-256 and SHA256) and the traffic selector (e.g., source/destination subnets). The responder replies with matching parameters. A new DH exchange may occur (PFS) to ensure that compromise of the IKE SA does not compromise IPsec keys. Two IPsec SAs are created: one inbound, one outbound. Each SA has a unique Security Parameter Index (SPI) and a lifetime (default 28,800 seconds or 4,608 MB). The network engineer sees `show crypto ipsec sa` with `encaps` and `decaps` counters increasing when traffic flows.
Data Encryption and Transmission
Once IPsec SAs are established, data packets are encrypted and transmitted through the tunnel. For each outgoing packet matching the traffic selector, the VPN gateway: (1) encrypts the original IP packet using ESP (tunnel mode encapsulates the entire packet; transport mode encrypts only the payload), (2) computes an integrity hash (HMAC) over the encrypted data, (3) adds an ESP header and trailer, (4) adds a new IP header with source and destination of the VPN endpoints, and (5) sends the packet. The receiving gateway verifies the hash, decrypts the packet, and forwards the original packet to the internal network. At the packet level, the outer IP header shows the VPN gateways' IPs, and the protocol field is 50 (ESP). A network engineer can capture packets and filter `esp` to see encrypted payloads.
Tunnel Maintenance and Rekeying
IPsec SAs have finite lifetimes. Before expiration, the peers automatically rekey: they perform a new Phase 2 Quick Mode exchange to create fresh keys. The old SAs are deleted after a brief overlap to avoid packet loss. If no traffic passes for a period (idle timeout), the SAs may be torn down to save resources. The IKE SA itself may also be rekeyed if its lifetime expires. During rekeying, a brief interruption may occur if not configured for dead-peer detection (DPD). DPD uses periodic hello messages (e.g., every 10 seconds) to verify peer liveness. If a peer fails to respond, the SAs are cleared. A network engineer can monitor rekeying with `debug crypto ipsec` or by observing SA counters resetting.
Tunnel Termination
A VPN tunnel can be terminated administratively (e.g., user disconnects, interface goes down) or due to a failure (e.g., peer unreachable). When a client disconnects, it sends a delete notification to the VPN gateway, which then clears the SAs. For site-to-site, if the interesting traffic stops, the SAs may remain until their lifetime expires or idle timeout triggers. In case of a peer failure, DPD detects the absence and removes SAs. The network engineer sees `show crypto isakmp sa` and `show crypto ipsec sa` with entries disappearing. Proper termination ensures that resources are freed and no stale SAs remain.
Enterprise Scenario 1: Site-to-Site VPN for Branch Office Connectivity
A multinational corporation with headquarters in New York and a branch office in London needs to connect their internal networks securely over the Internet. The solution is a site-to-site IPsec VPN between two Cisco ASR routers. The internal subnets are 10.1.0.0/16 (NY) and 10.2.0.0/16 (London). The engineer configures IKE with pre-shared keys, AES-256 encryption, SHA-256 hash, and DH Group 14. The crypto map is applied to the Internet-facing GigabitEthernet interfaces. An ACL defines interesting traffic as any IP between the two subnets. In production, the VPN handles 200 Mbps of traffic. Performance considerations include MTU: the engineer sets the tunnel interface MTU to 1400 bytes and enables TCP MSS clamping to 1360 bytes to avoid fragmentation. Common issues include rekeying failures if the pre-shared key mismatches or if NAT is present (solved by enabling NAT-T). Misconfiguration often leads to Phase 1 or Phase 2 failures; the engineer uses debug crypto isakmp and debug crypto ipsec to diagnose. Scaling: as the company grows to 50 branches, a full-mesh IPsec becomes unmanageable; they migrate to DMVPN with a hub-and-spoke topology.
Enterprise Scenario 2: Remote Access VPN for Teleworkers
A healthcare organization with 5,000 employees needs secure remote access to electronic health records (EHR) systems. They deploy an SSL VPN appliance (e.g., Cisco ASA with AnyConnect) because it works from any device without pre-installed client software. Users connect via a web browser or the AnyConnect client, which uses TLS 1.2 on TCP 443. The VPN is integrated with RADIUS for two-factor authentication (smart card + PIN). Split tunneling is configured to send only traffic destined for the corporate subnet (10.0.0.0/8) through the VPN; Internet traffic goes directly to reduce load on the VPN concentrator. The VPN concentrator is sized for 5,000 concurrent sessions with AES-256-GCM encryption. Common problems: users forget to log off, leaving idle sessions; the idle timeout is set to 30 minutes. Misconfiguration of split DNS causes internal hostnames to resolve to public IPs, breaking access; the engineer configures DNS suffix and internal DNS servers via the VPN profile. Performance: each user consumes about 5 Mbps during video conferencing; the total bandwidth must be provisioned accordingly.
Scenario 3: Cloud VPN to AWS
A startup uses AWS for its production environment and needs a secure connection from its on-premises office. They set up a site-to-site VPN using AWS Virtual Private Gateway and a Cisco router on-premises. AWS supports IPsec VPN with IKEv1 or IKEv2, using pre-shared keys or certificates. The engineer configures the on-premises router with the AWS public IP and the two tunnels (for redundancy). Each tunnel uses a different pre-shared key. The BGP over the VPN is configured for dynamic routing (e.g., using BGP with AWS). Common pitfalls: MTU issues cause packet drops; the engineer sets the tunnel MTU to 1436 (AWS recommendation). Another issue: if the on-premises router does not support NAT-T, the VPN fails if behind a NAT device. The engineer ensures NAT-T is enabled. Scaling: for multiple VPCs, a transit gateway is used to centralize the VPN connections.
Exactly What N10-009 Tests on VPNs and Remote Access
Objective 4.4 (Network Security) specifically includes: "Given a scenario, configure and deploy common network security features." VPNs are a key feature. The exam tests your ability to:
Differentiate between VPN types: site-to-site vs. remote access.
Identify protocols: IPsec (ESP, AH), SSL/TLS, PPTP, L2TP/IPsec, GRE.
Understand encryption and authentication: AES, 3DES (obsolete), SHA, MD5, pre-shared keys, certificates.
Know ports and protocols: UDP 500 (IKE), UDP 4500 (NAT-T), IP 50 (ESP), IP 51 (AH), TCP 443 (SSL VPN), UDP 1194 (OpenVPN).
Recognize split tunneling vs. full tunneling.
Troubleshoot common VPN issues: mismatched parameters, NAT traversal, MTU.
Most Common Wrong Answers and Why Candidates Choose Them
"PPTP is more secure than L2TP/IPsec": Candidates confuse the fact that PPTP is easier to configure with security. Reality: PPTP uses MPPE (RC4) which is weak; L2TP/IPsec uses AES and is far more secure.
"GRE provides encryption": GRE is a tunneling protocol that encapsulates but does not encrypt. Candidates see "tunnel" and assume encryption. Reality: GRE must be combined with IPsec for encryption.
"SSL VPN requires a client": While some SSL VPNs use a lightweight client, many are clientless (browser-based). Candidates may think all VPNs need a client. Reality: SSL VPN can be clientless, using a web browser.
"IPsec uses TCP ports": IPsec uses UDP and IP protocols, not TCP. Candidates see "IKE" and assume TCP. Reality: IKE uses UDP 500; ESP is IP protocol 50.
"Split tunneling is more secure than full tunneling": Split tunneling reduces security because traffic to the Internet bypasses the VPN and may not be inspected. Candidates think splitting traffic reduces attack surface. Reality: Full tunneling is more secure.
Specific Numbers and Terms That Appear Verbatim
Default IKE lifetime: 86,400 seconds (24 hours).
Default IPsec SA lifetime: 28,800 seconds (8 hours) or 4,608 MB.
IKE uses UDP port 500; NAT-T uses UDP 4500.
ESP is IP protocol 50; AH is IP protocol 51.
SSL VPN uses TCP port 443.
Common encryption: AES-256.
Common hash: SHA-256.
DH Group 14 (2048-bit) is recommended.
Edge Cases and Exceptions
NAT-T: If a VPN client is behind a NAT device, IPsec fails because the integrity check covers the source IP. NAT-T encapsulates IPsec in UDP 4500 and recalculates the hash. The exam may ask why a VPN works from a coffee shop but not from home (NAT issue).
IPsec Modes: Transport mode is rarely used in site-to-site VPNs; tunnel mode is the default. The exam may show a scenario where transport mode is used for host-to-host.
IKEv2 vs. IKEv1: IKEv2 is simpler and more robust (fewer messages, built-in NAT-T and DPD). The exam may ask which version is newer.
Split Tunneling Security: A compromised VPN client can be used to attack internal resources if the client is also connected to the Internet. The exam may test that full tunneling is more secure.
How to Eliminate Wrong Answers Using the Underlying Mechanism
When faced with a VPN question, ask: - Does the scenario require encryption? If yes, eliminate GRE and PPTP (unless combined with IPsec). - Is it remote access? Look for SSL VPN or IPsec with client. Site-to-site typically uses IPsec. - What ports are mentioned? If the question lists TCP ports, IPsec is unlikely (IPsec uses UDP and IP protocols). - Is NAT present? If so, NAT-T must be used (UDP 4500). Answers without NAT-T are wrong. - What is the authentication method? Pre-shared keys are simple but less secure than certificates. If the question emphasizes high security, certificates are preferred. - What is the tunneling mode? For site-to-site, tunnel mode is used; transport mode is for end-to-end. If the question says "encrypts the entire packet," it's tunnel mode.
By focusing on the mechanism, you can eliminate answers that don't match the protocol behavior.
VPNs create encrypted tunnels over public networks; two main types: site-to-site and remote access.
IPsec is the most common protocol for site-to-site VPNs; it uses IKE (UDP 500/4500) and ESP (IP 50) or AH (IP 51).
SSL VPNs use TLS on TCP 443 and can be clientless; ideal for remote access.
GRE tunnels provide encapsulation only, no encryption; must be paired with IPsec.
PPTP is obsolete and insecure; L2TP/IPsec is more secure but legacy.
Split tunneling routes only corporate traffic through the VPN; full tunneling routes all traffic.
Default IKE lifetime is 86,400 seconds; default IPsec SA lifetime is 28,800 seconds.
NAT-T (UDP 4500) is required when IPsec passes through NAT devices.
Authentication can be via pre-shared keys or digital certificates; certificates are more secure.
Common troubleshooting: check crypto maps, ACLs, firewall rules, MTU, and IKE/IPsec SAs.
WireGuard is a modern, faster alternative to IPsec, using ChaCha20 and Curve25519.
The exam tests your ability to choose the correct VPN type and protocol for a given scenario.
These come up on the exam all the time. Here's how to tell them apart.
IPsec VPN
Uses IPsec suite (ESP/AH) with IKE for key exchange.
Operates at Layer 3 (network layer); can encrypt all IP traffic.
Requires client software or built-in OS client (e.g., Windows).
Uses UDP ports 500 and 4500, IP protocols 50/51.
Best for site-to-site VPNs and persistent connections.
SSL VPN
Uses TLS (SSL) for encryption, similar to HTTPS.
Operates at Layer 4-7; can provide application-level access.
Can be clientless (web browser) or use a lightweight client.
Uses TCP port 443 (HTTPS); easy through firewalls.
Best for remote access, especially from untrusted devices.
Mistake
All VPNs use the same encryption and are equally secure.
Correct
VPNs vary widely in security. PPTP uses weak MPPE (RC4) and is considered obsolete. IPsec with AES-256 and SHA-256 is strong. SSL VPNs use TLS, which is also strong. WireGuard uses modern ChaCha20. Always check the protocol and cipher.
Mistake
GRE tunnels provide encryption.
Correct
GRE (Generic Routing Encapsulation) only encapsulates packets; it does not encrypt them. GRE is often used with IPsec to add encryption. Without IPsec, GRE traffic is sent in clear text.
Mistake
IPsec uses TCP ports for key exchange.
Correct
IKE (Internet Key Exchange) uses UDP port 500. For NAT traversal, it uses UDP port 4500. IPsec does not use TCP for its control plane. ESP and AH are IP protocols (50 and 51), not TCP or UDP.
Mistake
Split tunneling is always more secure than full tunneling.
Correct
Split tunneling allows traffic to the Internet to bypass the VPN, meaning it is not subject to corporate security policies. This can expose the client to attacks and potentially compromise the internal network. Full tunneling forces all traffic through the VPN, which is more secure.
Mistake
SSL VPNs always require a client to be installed.
Correct
Many SSL VPNs are clientless and only require a web browser. Some SSL VPNs offer a client for additional features (e.g., network-level access), but the core protocol (TLS) is built into browsers. The exam distinguishes between clientless and client-based SSL VPNs.
Mistake
L2TP/IPsec is the same as PPTP.
Correct
L2TP/IPsec combines L2TP for tunneling with IPsec for encryption, providing strong security. PPTP is a different protocol that uses MPPE for encryption and is much weaker. They are not interchangeable.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A site-to-site VPN connects entire networks, such as a branch office to headquarters, using VPN gateways (routers/firewalls). It is always on and transparent to users. A remote access VPN connects individual users to a corporate network, typically using client software or a web browser. Remote access VPNs are on-demand and require user authentication. Site-to-site VPNs usually use IPsec; remote access VPNs often use SSL/TLS or IPsec with a client.
IPsec with strong encryption (AES-256) and authentication (SHA-256) is the most secure. L2TP/IPsec is also secure but adds overhead from L2TP. PPTP is the least secure due to its use of MPPE (RC4) and known vulnerabilities. For modern deployments, IPsec or SSL VPN are recommended. WireGuard is also highly secure but newer.
IPsec uses UDP port 500 for IKE (Internet Key Exchange), UDP port 4500 for NAT-T (NAT traversal), and IP protocol 50 for ESP (Encapsulating Security Payload) or IP protocol 51 for AH (Authentication Header). IKEv2 also uses UDP 500 and 4500. Some implementations may use TCP 10000 for IKE behind firewalls, but this is rare.
Split tunneling is a VPN configuration where only traffic destined for the corporate network goes through the VPN; all other traffic (e.g., Internet) goes directly to the ISP. It reduces bandwidth on the VPN and improves performance for non-corporate traffic. However, it is less secure because the client is exposed to the Internet and can be compromised, potentially allowing attacks on the corporate network. Use split tunneling when security requirements are lower and bandwidth is limited.
IPsec packets contain integrity checks that include the source IP address. NAT changes the source IP, causing the integrity check to fail at the receiver. NAT-T (NAT Traversal) solves this by encapsulating IPsec packets inside UDP (port 4500), which does not require the original source IP for integrity. Ensure both endpoints support NAT-T and that it is enabled.
In transport mode, only the payload of the IP packet is encrypted; the original IP header remains intact. This is used for end-to-end communication between hosts. In tunnel mode, the entire IP packet (header and payload) is encrypted and encapsulated within a new IP packet. This is used for VPN gateways (site-to-site). Tunnel mode hides the original source and destination IPs.
Yes, GRE can be used without IPsec for simple tunneling, but it provides no encryption or authentication. All traffic is sent in clear text. GRE is often used to tunnel non-IP protocols over IP (e.g., IPX, AppleTalk), but for security, it must be combined with IPsec (GRE over IPsec).
You've just covered VPNs and Remote Access — now see how well it sticks with free N10-009 practice questions. Full explanations included, no account needed.
Done with this chapter?