This chapter covers the three primary VPN types tested on the CompTIA Network+ N10-009 exam: site-to-site VPNs, remote access VPNs, and SSL/TLS VPNs. VPNs are a critical component of network security, enabling encrypted communication over untrusted networks like the internet. Approximately 10-15% of the Network Security domain (Objective 4.4) will focus on VPN technologies, protocols, and their appropriate deployment scenarios. You must understand the differences between these VPN types, the underlying protocols (IPsec, SSL/TLS, PPTP, L2TP), and when to use each.
Jump to a section
Imagine a company building a secure underground tunnel between two of its buildings, even though the public streets above are open to everyone. The tunnel has its own entrance and exit points (VPN gateways), and only authorized personnel with special badges (encryption keys) can enter. Once inside, all traffic between the buildings travels through the tunnel, invisible to anyone on the streets above. For remote employees, imagine they have a personal teleportation device that creates a temporary tunnel from their home directly into the company lobby. The teleporter authenticates their identity via a retina scan (SSL/TLS handshake), then creates a secure tube that only they can use. The tunnel encrypts everything they do—emails, file transfers, web browsing—as if they were physically inside the building. The key mechanistic detail: the tunnel doesn't replace the street; it creates a virtual path inside the street that only authorized users can see and use. Traffic still travels through the public internet, but it's encapsulated and encrypted so that the 'street traffic' (ISPs, routers) only sees encrypted packets, not the actual contents.
What is a VPN and Why Does It Exist?
A Virtual Private Network (VPN) creates an encrypted tunnel between two endpoints over a public network, typically the internet. The primary purpose is to provide confidentiality (encryption), integrity (hashing), and sometimes authentication for data in transit. VPNs allow remote users or branch offices to securely access a central network as if they were directly connected.
Site-to-Site VPNs
A site-to-site VPN connects entire networks together, such as a branch office to a corporate headquarters. It is also called a router-to-router VPN. Both sites have VPN-capable devices (routers, firewalls, or dedicated VPN concentrators) that establish a secure tunnel between them. All traffic from devices at one site destined for the other site is automatically encrypted and sent through the tunnel.
How it works: 1. Each VPN gateway is configured with the public IP address of the peer gateway. 2. The gateways authenticate each other using pre-shared keys (PSK) or digital certificates. 3. They negotiate an IPsec Security Association (SA) using Internet Key Exchange (IKE) protocol. 4. The SA defines encryption (e.g., AES-256), authentication (e.g., SHA-256), and key lifetime (default 3600 seconds for IKE SA, 28800 seconds for IPsec SA). 5. Once established, any packet from Site A destined for Site B's subnet is encapsulated with an IPsec header, encrypted, and sent to the peer gateway. 6. The receiving gateway decrypts and forwards the packet to the internal destination.
Key components: - VPN Gateway: Router or firewall that terminates the VPN tunnel. - IPsec Protocol Suite: Includes ESP (Encapsulating Security Payload) for encryption, AH (Authentication Header) for integrity (rarely used alone), and IKE for key exchange. - Tunnel Mode vs. Transport Mode: Site-to-site VPNs use tunnel mode, where the entire original IP packet is encapsulated. Transport mode only encrypts the payload and is used for end-to-end connections. - Routing: Static routes or dynamic routing protocols (OSPF, BGP) can be used over the VPN tunnel to advertise networks.
Configuration example (Cisco IOS):
crypto isakmp policy 10
authentication pre-share
encryption aes 256
hash sha256
group 14
lifetime 3600
crypto isakmp key courseiva123 address 203.0.113.5
crypto ipsec transform-set TSET esp-aes 256 esp-sha256-hmac
crypto map CMAP 10 ipsec-isakmp
set peer 203.0.113.5
set transform-set TSET
match address 101
interface GigabitEthernet0/0
crypto map CMAP
access-list 101 permit ip 10.1.0.0 0.0.255.255 10.2.0.0 0.0.255.255Remote Access VPNs
A remote access VPN connects individual users (road warriors, telecommuters) to a corporate network. The user initiates a VPN connection from their client device (laptop, smartphone) to a VPN concentrator at the edge of the corporate network.
How it works: 1. The user installs VPN client software (e.g., Cisco AnyConnect, OpenVPN client). 2. The client authenticates using credentials (username/password, certificate, or two-factor authentication). 3. The client and server negotiate encryption parameters and establish a tunnel. 4. The client receives a virtual IP address from the corporate network's DHCP server or a static pool. 5. All traffic (or split-tunnel traffic) is encrypted and sent to the VPN concentrator, which decrypts and forwards it to internal resources.
Protocols: - IPsec with IKEv2: Common in native VPN clients (Windows, macOS). IKEv2 is more robust, supports mobility (MOBIKE), and is faster to re-establish after connection loss. - L2TP/IPsec: Layer 2 Tunneling Protocol combined with IPsec for encryption. Less common today due to overhead and firewall issues. - PPTP: Point-to-Point Tunneling Protocol, obsolete due to known vulnerabilities (MS-CHAPv2 can be cracked). Not recommended. - SSL/TLS VPNs: Covered next.
Split Tunneling: The client can be configured to send only corporate-bound traffic through the VPN (split tunnel) or all traffic (full tunnel). Split tunneling reduces bandwidth usage on the VPN but can expose corporate data if the non-VPN interface is compromised.
SSL/TLS VPNs
An SSL/TLS VPN uses the same SSL/TLS protocol that secures HTTPS websites. It typically operates at Layer 5 (session layer) of the OSI model, though it can tunnel Layer 3 traffic. There are two main types: SSL Portal VPN and SSL Tunnel VPN.
SSL Portal VPN: The user connects to a web portal via HTTPS, where they access internal applications through a web interface. No client software is required; only a web browser. The portal acts as a proxy for internal web applications.
SSL Tunnel VPN: The user downloads a small client (often Java or ActiveX-based) that creates a full Layer 3 tunnel, similar to an IPsec remote access VPN but using SSL/TLS for encryption. This allows any application to be accessed, not just web apps.
How it works (SSL Tunnel VPN): 1. User opens a web browser and connects to the VPN server's public URL (e.g., https://vpn.company.com). 2. The server presents its SSL certificate; the client verifies it against a trusted CA. 3. The user authenticates (e.g., username/password + token). 4. The server pushes a small client (e.g., Java applet) that establishes a tunnel using SSL/TLS. 5. The client creates a virtual network interface and obtains an IP address from the corporate pool. 6. Traffic is encrypted using TLS (typically AES-128 or AES-256) and sent over TCP port 443.
Advantages: - No pre-installed client needed (for portal VPN). - Traverses firewalls easily since it uses standard HTTPS port 443. - Granular access control per user/group.
Disadvantages: - Overhead of TLS over TCP (TCP-over-TCP can cause performance issues). - Not all applications are compatible with portal VPN.
Common implementations: - Cisco AnyConnect (SSL VPN mode). - OpenVPN (uses TLS for key exchange, can run over TCP or UDP). - Pulse Secure, F5 BIG-IP APM.
Comparing VPN Types
| Feature | Site-to-Site | Remote Access IPsec | SSL/TLS VPN | |---------|--------------|---------------------|-------------| | Connection | Network to network | Host to network | Host to network | | Client software | Gateway only | Client installed | Browser or lightweight client | | Encryption | IPsec (ESP) | IPsec (ESP) | TLS | | Port | UDP 500 (IKE), IP 50 (ESP) | UDP 500, UDP 4500 (NAT-T) | TCP 443 | | Authentication | PSK or certificates | User credentials + machine cert | User credentials, certs, tokens | | Scalability | Low (fixed peers) | Medium (hundreds of users) | High (thousands of users) |
Interaction with Related Technologies
NAT Traversal (NAT-T): IPsec uses UDP 4500 when both peers are behind NAT. ESP packets (IP protocol 50) cannot traverse NAT without encapsulation.
Firewalls: Must allow the appropriate protocols (UDP 500, UDP 4500, IP 50 for IPsec; TCP 443 for SSL VPN). Stateful firewalls need to track VPN sessions.
Authentication Servers: RADIUS or LDAP for user authentication in remote access VPNs.
PKI: Digital certificates for gateway and client authentication, especially in large deployments.
Site-to-Site VPN Establishment
1. The initiating gateway (e.g., branch router) sends an IKEv1 or IKEv2 packet to the peer gateway's public IP on UDP 500. This starts Phase 1 negotiation. 2. The gateways authenticate using pre-shared keys or certificates and negotiate encryption algorithms (e.g., AES-256, SHA-256, Diffie-Hellman group 14). Phase 1 creates an IKE SA (Security Association) with a default lifetime of 3600 seconds. 3. Phase 2 negotiates the IPsec SA: the gateways exchange proposals for encryption (ESP) and authentication (HMAC), and agree on a shared secret derived from the Phase 1 key. The IPsec SA lifetime defaults to 28800 seconds. 4. Once the IPsec SA is established, traffic matching the crypto ACL is encrypted. The original IP packet is encapsulated with an ESP header, encrypted, and sent to the peer. 5. The receiving gateway uses the SA to decrypt the packet and forward it to the internal network. If the SA expires, the gateway automatically renegotiates (rekey) before expiration to avoid traffic interruption.
Remote Access VPN Connection
1. The user opens the VPN client software (e.g., built-in Windows VPN client) and enters the server address (public IP or FQDN) and credentials. 2. The client initiates an IKEv2 or L2TP/IPsec connection to the VPN concentrator on UDP 500. 3. The concentrator authenticates the user against a RADIUS server or Active Directory. Optionally, machine certificates are validated. 4. After authentication, the concentrator assigns an IP address to the client from a defined pool (e.g., 10.10.10.100-200). 5. The client installs a virtual network interface with that IP and adds routes for the corporate network (e.g., 10.0.0.0/8) via the virtual interface. 6. The client encrypts all traffic destined for corporate resources and sends it through the tunnel. The concentrator decrypts and forwards. When the user disconnects, the virtual interface is removed.
SSL VPN Portal Access
1. The user opens a web browser and navigates to the SSL VPN portal URL (e.g., https://vpn.company.com/portal). 2. The browser verifies the server's SSL certificate against a trusted root CA. If the certificate is self-signed or expired, the user sees a warning. 3. The user enters credentials (username/password) and possibly a one-time password (OTP) from a token. 4. The server authenticates the user and presents a web page listing available internal applications (e.g., webmail, intranet, file shares). 5. When the user clicks an application, the portal server proxies the request: it establishes a separate HTTPS connection to the internal server and relays the data. 6. The user never directly connects to the internal server; all traffic is proxied through the portal, which enforces access control policies.
SSL Tunnel VPN (Full Tunnel)
1. User connects to the SSL VPN server via HTTPS as in portal mode. 2. After authentication, the server pushes a small client (e.g., a Java applet or native executable) to the user's browser. 3. The client installs a virtual network adapter and establishes a TLS tunnel to the server on TCP 443. 4. The server assigns an IP address to the client from an internal pool. 5. The client adds routes to send all (or selected) traffic through the tunnel. 6. All traffic is encapsulated in TLS records and sent over the single TCP connection. The server decapsulates and routes packets. 7. When the user closes the browser or logs out, the tunnel is torn down and the virtual adapter removed.
Troubleshooting VPN Issues
1. Check connectivity: ping the VPN gateway's public IP from the client. If unreachable, check firewall rules (allow UDP 500, UDP 4500, IP 50 for IPsec; TCP 443 for SSL). 2. Verify authentication: test credentials against the authentication server (RADIUS, LDAP). For certificates, check expiry and revocation status. 3. Examine logs: on the VPN concentrator, view logs for IKE/SSL negotiation failures. Common errors: 'no proposal chosen' (mismatched encryption parameters), 'authentication failure' (wrong PSK or credentials). 4. Check routing: ensure the client has a route to the corporate network via the VPN interface. Use 'route print' on Windows or 'netstat -rn' on Linux. 5. Test with a simplified topology: temporarily disable NAT or firewall to isolate the issue.
Enterprise Scenario 1: Branch Office Connectivity
A retail chain with 50 branch offices uses site-to-site IPsec VPNs to connect each store to the corporate headquarters. Each store has a Cisco ISR router with a public IP. The HQ has a pair of ASA firewalls in active/standby mode. The challenge is managing 50 individual tunnel configurations. To simplify, the company uses a DMVPN (Dynamic Multipoint VPN) design, which allows spokes (stores) to dynamically establish tunnels to the hub (HQ) and optionally to other spokes. DMVPN uses mGRE (multipoint GRE) and NHRP (Next Hop Resolution Protocol) to automate tunnel creation. Performance consideration: each tunnel can handle up to 100 Mbps, but the HQ firewall's throughput is limited to 1 Gbps total. When a new store opens, the configuration is templated using Cisco's CLI scripting. Common misconfiguration: mismatched PSK or encryption parameters cause Phase 1 failures. Troubleshooting involves checking 'show crypto isakmp sa' and 'show crypto ipsec sa' on both ends.
Enterprise Scenario 2: Remote Workforce
A software company with 500 employees uses SSL VPN (Pulse Secure) for remote access. Employees connect from home using laptops and smartphones. The VPN server is deployed in a DMZ, with RADIUS authentication against Active Directory and Duo two-factor authentication. Split tunneling is enabled to reduce bandwidth: only traffic to the corporate IP range (10.0.0.0/8) goes through the VPN; internet traffic goes directly. This prevents the VPN server from becoming a bottleneck. However, split tunneling introduces a security risk: if the employee's home network is compromised, an attacker could access corporate resources via the VPN tunnel. To mitigate, the company enforces host checks (antivirus, firewall enabled) before allowing VPN access. Performance: the Pulse Secure appliance handles 2000 concurrent sessions with a throughput of 500 Mbps. Common issues: users forget to install the required client certificate, or the browser blocks the Java applet for portal mode.
Enterprise Scenario 3: Cloud Connectivity
A financial services firm uses AWS VPN to connect its on-premises data center to its VPC (Virtual Private Cloud). They set up a site-to-site VPN using AWS's managed VPN service. The on-premises firewall (Fortinet) initiates the IPsec tunnel to two AWS endpoints for redundancy. The tunnel uses IKEv2 with AES-256 and SHA-256. BGP is configured over the tunnel to exchange routes. The challenge is ensuring the tunnel stays up during failover; the firewall monitors the tunnel using dead peer detection (DPD) and re-establishes if needed. The company also uses AWS Client VPN for individual developers to access the VPC. This is an OpenVPN-based service that integrates with Active Directory. Cost: AWS charges per VPN connection hour and per GB of data transfer. Common misconfiguration: the on-premises firewall's NAT rule interferes with IPsec traffic, requiring NAT exemption.
What N10-009 Tests
Objective 4.4 (Network Security) expects you to compare and contrast VPN types and protocols. Specific exam topics include:
Differences between site-to-site and remote access VPNs.
Protocols: IPsec (ESP, AH, IKE), SSL/TLS, L2TP, PPTP.
Ports and protocols: UDP 500 (IKE), UDP 4500 (NAT-T), IP 50 (ESP), TCP 443 (SSL VPN).
Authentication methods: pre-shared keys, certificates, RADIUS.
When to use tunnel mode vs. transport mode.
Common Wrong Answers
'SSL VPNs use IPsec' – Wrong. SSL VPNs use TLS, not IPsec. Candidates confuse 'secure' with 'IPsec'.
'PPTP is the most secure' – Wrong. PPTP is deprecated due to weak encryption (RC4) and authentication (MS-CHAPv2). The exam expects you to know it's insecure.
'Site-to-site VPNs require client software' – Wrong. Site-to-site VPNs are gateway-to-gateway; no client software on individual hosts.
'L2TP provides encryption' – Wrong. L2TP itself does not encrypt; it relies on IPsec for encryption. L2TP/IPsec is the secure combination.
Specific Numbers and Terms
IKE Phase 1 lifetime: 3600 seconds (default).
IPsec SA lifetime: 28800 seconds (default).
NAT-T uses UDP 4500.
ESP protocol number: 50.
IKE uses UDP 500.
SSL VPN uses TCP 443.
Diffie-Hellman groups: group 14 (2048-bit) is common.
Edge Cases
NAT-T: If both VPN peers are behind NAT, IPsec must use UDP encapsulation (4500). The exam may test that NAT-T is automatically negotiated when a NAT device is detected.
Dead Peer Detection (DPD): Used to detect if the remote peer is still reachable; sends keepalives (default 10 seconds).
Perfect Forward Secrecy (PFS): Ensures that if one key is compromised, past keys are not. The exam may ask about PFS in the context of IPsec.
How to Eliminate Wrong Answers
If the question mentions 'web browser', 'no client', or 'port 443', the answer is SSL VPN.
If the question mentions 'branch office' or 'network to network', the answer is site-to-site.
If the question mentions 'client software installed on user device', it's remote access VPN (IPsec or SSL).
If the question asks for the most secure protocol, choose IPsec with AES and SHA, not PPTP or L2TP alone.
Site-to-site VPNs connect networks; remote access VPNs connect individual hosts.
IPsec uses ESP (protocol 50) with IKE (UDP 500) for key exchange.
NAT-T uses UDP 4500 to encapsulate IPsec when behind NAT.
SSL VPNs use TCP 443 and can operate in portal or tunnel mode.
PPTP is insecure and should not be used; L2TP requires IPsec for encryption.
IKEv2 is preferred over IKEv1 for remote access VPNs due to mobility support.
Default IKE SA lifetime is 3600 seconds; IPsec SA lifetime is 28800 seconds.
Split tunneling reduces VPN bandwidth but may reduce security.
Digital certificates provide stronger authentication than pre-shared keys.
DMVPN allows dynamic site-to-site tunnels with a hub-and-spoke topology.
These come up on the exam all the time. Here's how to tell them apart.
Site-to-Site VPN
Connects entire networks (e.g., branch to HQ).
No client software needed on user devices.
Uses IPsec tunnel mode typically.
Always on, no user initiation.
Static peer configuration (gateway IPs).
Remote Access VPN
Connects individual users to a network.
Requires VPN client software on user device.
Can use IPsec or SSL/TLS.
User initiates connection on demand.
User may have dynamic IP; concentrator handles authentication.
IPsec VPN
Operates at Layer 3 (Network layer).
Requires client software (or built-in OS client).
Uses UDP 500, UDP 4500, IP 50.
Supports all IP traffic (any protocol).
More complex firewall configuration.
SSL VPN
Operates at Layer 5 (Session layer) or Layer 3 (tunnel mode).
Can use only a web browser (portal mode) or lightweight client.
Uses TCP 443 (HTTPS).
May only support TCP traffic in portal mode; tunnel mode supports any traffic.
Easily traverses firewalls (port 443 usually open).
Mistake
SSL VPNs are less secure than IPsec VPNs.
Correct
Both can be equally secure if properly configured. SSL VPNs use TLS, which is a mature, well-audited protocol. IPsec is also secure but can be complex to configure. The exam does not claim one is universally more secure; it depends on implementation.
Mistake
L2TP provides encryption by itself.
Correct
L2TP is a tunneling protocol that does not include encryption. It is typically used with IPsec (L2TP/IPsec) to provide encryption. Without IPsec, L2TP is not secure.
Mistake
Site-to-site VPNs require a dedicated leased line.
Correct
Site-to-site VPNs use the public internet, not leased lines. They create a virtual tunnel over an existing internet connection. Leased lines are used for private WAN connections like MPLS, not VPNs.
Mistake
PPTP is still acceptable for remote access.
Correct
PPTP is obsolete and insecure. Microsoft recommends against its use. The N10-009 exam expects you to know that PPTP should not be used due to vulnerabilities in MS-CHAPv2 and RC4 encryption.
Mistake
Remote access VPNs always require split tunneling.
Correct
Split tunneling is optional. Full tunneling routes all client traffic through the VPN, which is more secure but uses more bandwidth. The exam tests that split tunneling is a configuration choice, not a requirement.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
In tunnel mode, the entire original IP packet is encapsulated with a new IP header and ESP header. This is used for site-to-site VPNs. In transport mode, only the payload of the IP packet is encrypted; the original IP header remains intact. Transport mode is used for end-to-end connections, such as between a client and a server. The exam tests that tunnel mode is for VPN gateways, transport mode for host-to-host.
IPsec uses multiple ports: IKE (key exchange) uses UDP 500. If NAT-T is needed, IKE uses UDP 4500. Encapsulating Security Payload (ESP) is IP protocol 50 (not a UDP/TCP port). Authentication Header (AH) is IP protocol 51. For the exam, remember UDP 500 and UDP 4500 for IKE, and that ESP is protocol 50.
Yes, in SSL portal VPN mode, no client is required; the user accesses internal applications through a web browser. However, for full tunnel VPN (SSL tunnel VPN), a small client is typically downloaded. The exam distinguishes between portal and tunnel modes.
The default IPsec SA lifetime is 28800 seconds (8 hours). The IKE SA lifetime defaults to 3600 seconds (1 hour). These values are configurable. The exam may test that shorter lifetimes increase security but increase overhead due to rekeying.
PPTP uses weak encryption (RC4) and weak authentication (MS-CHAPv2), which can be cracked with modern hardware. It also does not provide strong integrity checks. Microsoft recommends using IKEv2 or L2TP/IPsec instead. The exam expects you to know that PPTP is deprecated.
NAT-T (NAT Traversal) allows IPsec packets to traverse NAT devices. IPsec's ESP protocol (IP 50) cannot pass through NAT because it lacks port numbers. NAT-T encapsulates ESP in UDP packets (port 4500), allowing the NAT device to translate the source IP/port. The exam tests that NAT-T uses UDP 4500.
IKEv2 is simpler and more robust than IKEv1. It uses fewer messages (4 vs. 6 for IKEv1), supports mobility (MOBIKE), and has built-in NAT-T and DPD. IKEv2 is the preferred version for remote access VPNs. The exam may test that IKEv2 is more efficient.
You've just covered VPN Types: Site-to-Site, Remote Access, SSL/TLS — now see how well it sticks with free N10-009 practice questions. Full explanations included, no account needed.
Done with this chapter?