Exam Objective 4.5: Describe IPsec remote access and site-to-site VPNs (protocols and transport modes).
VPNs let organizations extend a private, secure network connection across an inherently untrusted public network like the internet. IPsec is the dominant framework used to secure that connection at the network layer, and it shows up in two very different deployment shapes: site-to-site VPNs (connecting two entire networks together, transparently to the end users on each side) and remote access VPNs (connecting an individual user's device into a corporate network). This objective is descriptive rather than configuration-heavy — you're expected to know the protocols that make up IPsec, the difference between transport and tunnel mode, and how the two VPN deployment types differ.
IPsec (IP Security) is not a single protocol but a framework — a suite of protocols and standards working together to provide confidentiality (encryption), integrity (assurance the data wasn't altered), authentication (confirming the identity of the communicating parties), and anti-replay protection for IP traffic. IPsec operates at the network layer (Layer 3), which is what allows it to transparently secure any traffic riding on top of IP, regardless of the specific application generating that traffic.
The four core security services IPsec provides:
Confidentiality — encrypting the data so it cannot be read by anyone intercepting it in transit
Integrity — ensuring the data was not modified/tampered with while in transit
Authentication — verifying that the two endpoints communicating are actually who they claim to be
Anti-replay protection — preventing a captured, legitimate packet from being maliciously re-sent later to trick a system into re-processing it
Before IPsec can actually encrypt and protect any traffic, the two VPN endpoints need to securely agree on shared encryption keys and security parameters — this negotiation process is handled by IKE (Internet Key Exchange), which itself operates in two phases.
IKE Phase 1: Establishes a secure, authenticated management channel (called an ISAKMP SA, or Security Association) between the two VPN peers, used to protect the subsequent Phase 2 negotiation itself. Phase 1 can operate in one of two modes:
Main mode — a more secure, six-message exchange that fully protects the identity of the negotiating peers during setup
Aggressive mode — a faster, three-message exchange that sacrifices some identity protection for reduced setup time/overhead
IKE Phase 2: Negotiates the actual IPsec Security Associations (SAs) that will be used to protect the real data traffic — the specific encryption/hashing algorithms, keys, and parameters that will actually secure the VPN's payload traffic going forward. Phase 2 uses a single mode, called Quick Mode.
IKE versions: IKEv1 is the original version, built around the two-phase process described above. IKEv2 is a more modern, streamlined replacement, simplifying the negotiation process, adding built-in support for NAT traversal and dead peer detection, and generally converging faster than IKEv1.
Exam Alert: Know that IKE handles the key exchange/negotiation, not the actual data encryption itself — that's the job of the protocols covered next (AH and ESP). Also know the two-phase structure (Phase 1 establishes a secure management channel, Phase 2 negotiates the actual data-protection parameters).
Authentication Header (AH), IP protocol number 51, provides authentication and integrity for IP packets — but critically, does not provide any encryption/confidentiality at all. AH ensures the packet genuinely came from the claimed source and wasn't altered in transit, but the actual data payload remains fully readable to anyone who intercepts it.
Why AH is rarely used alone in modern deployments: Since AH provides no confidentiality whatsoever, and since its integrity check covers the entire packet including the outer IP header, it is also fundamentally incompatible with NAT (any device performing NAT along the path must modify the IP header, which breaks AH's integrity check) — making AH a poor fit for the vast majority of modern real-world VPN deployments, where NAT traversal is frequently a practical requirement.
Exam Alert: AH provides authentication and integrity only — no encryption. This is the single most commonly tested distinguishing fact about AH versus ESP, and AH's incompatibility with NAT is a frequently tested follow-up detail.
Encapsulating Security Payload (ESP), IP protocol number 50, is the far more commonly used IPsec protocol in real-world deployments, since it provides confidentiality (encryption) in addition to authentication and integrity — essentially delivering everything AH does, plus the encryption that AH lacks.
Why ESP is the dominant real-world choice: Because ESP's integrity check (in its standard configuration) does not need to cover the outermost IP header the way AH's does, ESP is compatible with NAT traversal (commonly implemented via NAT-T, which further wraps ESP packets in UDP specifically to survive NAT devices along the path), making it the practical, default choice for the overwhelming majority of modern IPsec VPN deployments.
Exam Alert: ESP provides confidentiality, integrity, and authentication — the "full package" — and is why ESP is used in the vast majority of real-world IPsec deployments instead of AH. Know the protocol numbers: AH = IP protocol 51, ESP = IP protocol 50 — a frequently tested, easy-to-mix-up pair of numbers.
Both AH and ESP can operate in one of two distinct modes, and this transport-versus-tunnel distinction is one of the most heavily tested parts of this entire objective.
Transport mode:
Only the payload (the actual data) of the original IP packet is encrypted/protected; the original IP header itself remains intact and unencrypted
Used specifically for host-to-host communication, where both communicating endpoints are themselves the actual VPN/IPsec endpoints (rather than a gateway/router protecting traffic on behalf of other devices behind it)
Lower overhead than tunnel mode, since no additional outer IP header needs to be added
Commonly associated with remote access-style, host-to-host protection scenarios, though it can technically be used in various contexts
Tunnel mode:
The entire original IP packet (including its original header) is encrypted and encapsulated inside a brand new outer IP packet, with a new outer IP header addressed to the remote VPN gateway/endpoint
Used specifically for gateway-to-gateway communication, where two routers/firewalls are protecting traffic on behalf of the actual end hosts behind them, which themselves have no awareness that IPsec is even being used
Higher overhead than transport mode, due to the additional outer IP header, but provides an important additional benefit: the original (inside) source and destination IP addresses are themselves hidden from anyone observing the outer, public-facing traffic
This is the mode used in essentially all site-to-site VPN deployments, since the whole point is to protect traffic between two entire networks via their respective gateway devices, without requiring any special configuration on the individual end hosts behind each gateway
Exam Alert: Tunnel mode = the standard, expected mode for site-to-site VPNs (gateway-to-gateway, entire original packet encapsulated with a new outer header). Transport mode = used for host-to-host protection where the communicating endpoints are themselves the IPsec peers, with only the payload protected and the original header exposed. This mode-to-deployment-type mapping is a directly and frequently tested fact.
A site-to-site VPN connects two entire networks (typically at two different physical locations) together over an otherwise untrusted network like the internet, using two gateway devices (routers or firewalls) as the actual VPN endpoints, entirely transparent to the individual end hosts on either side.
Key characteristics:
The VPN is established and maintained between two gateway/edge devices, not by individual end-user devices
End hosts behind each gateway have no awareness that their traffic is being encrypted/tunneled at all — from their perspective, they're simply communicating with a host on a remote subnet, exactly as if that subnet were directly, privately connected
Always uses IPsec tunnel mode, since the entire point is to protect traffic on behalf of many hosts behind each gateway, requiring the original packets (including their original headers) to be fully encapsulated
Typically a permanent or semi-permanent connection, always active between the two sites, rather than something individually initiated per-user or per-session
Typical use case: Connecting a branch office network to a headquarters network (or connecting to a cloud provider's private network) so that devices at either location can communicate as if they were on the same private network, with all inter-site traffic automatically encrypted by the two gateway devices without any special end-host configuration.
A remote access VPN connects an individual user's device (a laptop, phone, or similar single endpoint) directly into a corporate network, typically over the public internet, most commonly used by an individual employee working remotely who needs secure access to internal corporate resources.
Key characteristics:
The VPN is established between the individual end-user's device itself and a VPN gateway/concentrator at the corporate network's edge — unlike site-to-site, where the connection is between two gateways, here one side of the connection genuinely is the actual end host
Typically initiated on-demand by the user (launching VPN client software) rather than being a permanent, always-on connection like a site-to-site VPN
Client software (a VPN client application) is generally required on the end-user's device to establish and manage the connection, handle authentication, and apply the negotiated IPsec (or alternative protocol) settings
Can use either IPsec or SSL/TLS-based VPN technology (SSL VPN is a distinct, non-IPsec alternative not covered under this specific IPsec-focused exam objective, but worth knowing exists as the other major remote-access VPN category)
Typical use case: An employee working from home or traveling connects their laptop's VPN client to the corporate VPN gateway, authenticates, and is granted secure access to internal file servers, applications, and other resources exactly as if they were physically present on the corporate network.
Site-to-site VPN:
Connects two entire networks/sites together
VPN endpoints are gateway devices (routers/firewalls) on each side
End hosts are unaware the VPN even exists
Always uses tunnel mode
Typically permanent/always-on
Remote access VPN:
Connects a single individual device into a network
One VPN endpoint is the actual end-user device itself
Requires client software on the end-user device
Commonly on-demand/user-initiated per session
Can use IPsec or SSL/TLS-based technology
Exam Alert: The core distinguishing question the exam likes to test: are both ends of this VPN entire networks represented by gateway devices (site-to-site, tunnel mode), or is one end an individual user's own device (remote access)? Getting this classification right is the foundation for correctly answering nearly every other question in this topic.
Two potential VPN peers first use IKE (Phase 1) to establish a secure, authenticated management channel between themselves.
Still within IKE, but now Phase 2 (Quick Mode), the peers negotiate the actual parameters — which encryption algorithm, which hashing algorithm, and which specific IPsec protocol (AH or, far more commonly, ESP) — that will protect the real data traffic going forward.
Once negotiated, the actual data traffic is protected using ESP (in the vast majority of real deployments) operating in either transport mode (host-to-host) or tunnel mode (gateway-to-gateway, used for site-to-site VPNs).
For a site-to-site VPN specifically, this entire process happens between the two sites' gateway devices, with tunnel mode encapsulating the original, full IP packets (headers included) inside new outer IP packets addressed between the two gateways.
For a remote access VPN, the process happens between the individual user's own device (running VPN client software) and the corporate VPN gateway, potentially using either transport mode or tunnel mode depending on the specific implementation, though tunnel mode is still very commonly used even in this scenario to fully protect the original packet structure.
Q1. Which IPsec protocol provides authentication and integrity but does NOT provide encryption/confidentiality?
A. ESP
B. AH
C. IKE Phase 1
D. IKE Phase 2
Answer: B. AH (Authentication Header) provides authentication and integrity for IP packets but provides no encryption at all, meaning the actual data payload remains readable to anyone intercepting it. This is the key distinguishing fact separating AH from ESP, which provides confidentiality in addition to authentication and integrity.
Q2. Which IPsec mode encrypts the entire original IP packet, including its original header, and encapsulates it within a new outer IP packet addressed between two gateway devices?
A. Transport mode
B. Tunnel mode
C. Aggressive mode
D. Quick Mode
Answer: B. Tunnel mode encapsulates the entire original IP packet — including its original header — inside a new outer IP packet with a new header addressed to the remote gateway. This is the mode used in essentially all site-to-site VPN deployments, since it fully protects and hides the original packet's addressing from anyone observing the outer, public-facing traffic.
Q3. A company needs to connect its branch office network to its headquarters network so that devices at either location can communicate securely and transparently, without any special configuration required on individual end-user devices. Which VPN type and mode best fits this requirement?
A. Remote access VPN using transport mode
B. Site-to-site VPN using tunnel mode
C. Remote access VPN using AH only
D. Site-to-site VPN using transport mode
Answer: B. This scenario describes exactly the site-to-site VPN use case — connecting two entire networks together via gateway devices, transparently to the individual end hosts behind each gateway. Site-to-site VPNs always use tunnel mode, since the whole original packet (from each end host) needs to be encapsulated and protected on their behalf by the gateway devices.
Q4. What is the primary function of IKE within an IPsec VPN deployment?
A. Encrypting the actual data payload of every packet
B. Negotiating and establishing the secure keys and security parameters used to protect the VPN, before any actual data traffic is protected
C. Performing NAT translation for VPN traffic
D. Providing reverse DNS lookups for VPN endpoints
Answer: B. IKE (Internet Key Exchange) handles the negotiation and secure exchange of keys and security parameters between the two VPN peers, operating in two phases (establishing a secure management channel in Phase 1, then negotiating the actual data-protection parameters in Phase 2). The actual encryption of data traffic itself is then handled separately by ESP (or, far less commonly, AH).
Q5. Which IP protocol number is associated with ESP, and which is associated with AH?
A. ESP = 50, AH = 51
B. ESP = 51, AH = 50
C. ESP = 6, AH = 17
D. ESP and AH share the same protocol number
Answer: A. ESP uses IP protocol number 50, and AH uses IP protocol number 51. These specific protocol numbers are a commonly tested, easy-to-transpose pair of facts distinguishing the two core IPsec data-protection protocols.
Q6. An individual employee working from home launches VPN client software on their laptop to securely connect to their company's internal network. What type of VPN deployment does this describe?
A. Site-to-site VPN
B. Remote access VPN
C. AH-only VPN
D. IKE Phase 1 VPN
Answer: B. This scenario — an individual end-user device connecting into a corporate network, using client software, typically initiated on-demand by the user — is the defining characteristic of a remote access VPN, as opposed to a site-to-site VPN, which connects two entire networks together via gateway devices rather than an individual end-user device.