IPsec, VPN Protocols, and Remote Access Security
Compare IPsec tunnel and transport modes, SSL-VPN, and WireGuard for secure remote access, and understand split tunneling risks.
IPsec, VPN Protocols, and Remote Access Security is a free Cloud & IT Cert Prep lesson on CoddyKit — lesson 4 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Cloud & IT Cert Prep learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.
Why VPNs Matter
A Virtual Private Network (VPN) creates an encrypted tunnel over a public or untrusted network, allowing remote users and sites to communicate as if they were on the same private network. VPNs protect against eavesdropping on untrusted networks (hotel Wi-Fi, public hotspots), allow remote employees to access internal resources, and connect branch offices securely over the internet. The Security+ exam tests multiple VPN technologies — IPsec, SSL-VPN, and emerging protocols like WireGuard — along with the security considerations that apply to each.
IPsec Overview
IPsec (Internet Protocol Security) is a suite of protocols that secures IP traffic at Layer 3. IPsec operates in two modes: Transport mode encrypts only the payload of each IP packet (the original IP header is preserved — used for end-to-end host communication) and Tunnel mode encrypts the entire original packet and wraps it in a new IP header — used for site-to-site VPNs where gateways act as tunnel endpoints. IPsec uses two main protocols: AH (Authentication Header) for integrity and authentication only (no encryption), and ESP (Encapsulating Security Payload) for both encryption and authentication.
# IPsec protocol comparison
AH (Protocol 51):
- Authentication + Integrity (HMAC)
- NO encryption (plaintext payload)
- Rarely used alone in modern deployments
ESP (Protocol 50):
- Encryption (AES, 3DES)
- Authentication + Integrity (HMAC)
- Provides confidentiality
- Almost always used instead of AH alone
# IPsec modes
Transport : Original-IP | AH/ESP | Payload
Tunnel : New-IP | ESP | Original-IP | PayloadIKE and the IPsec Handshake
IKE (Internet Key Exchange) negotiates the security parameters (algorithms, keys) for an IPsec session. IKEv1 used two phases: Phase 1 (establish a secure channel to protect Phase 2 negotiation) and Phase 2 (negotiate the actual IPsec Security Associations). IKEv2 (current standard) is simpler, faster, more reliable, and adds built-in support for EAP authentication and MOBIKE (handling IP address changes mid-session — important for mobile devices). IPsec Security Associations (SAs) are unidirectional; each direction has its own SA with its own encryption key.
# IKEv2 negotiation overview
Initiator Responder
|---IKE_SA_INIT request-->| (propose algorithms)
|<--IKE_SA_INIT response--| (accept + key exchange)
|---IKE_AUTH request----->| (authenticate identity)
|<--IKE_AUTH response-----| (create Child SA = IPsec SA)
|====Encrypted IPsec=====>| (data flows)
# Result: two Security Associations (SAs)
# SA1: Initiator -> Responder (encrypt + auth)
# SA2: Responder -> Initiator (encrypt + auth)
# Each SA has its own SPI (Security Parameter Index)SSL-VPN vs IPsec VPN
IPsec VPN operates at Layer 3, requiring client software and often needing specific firewall port openings (UDP 500, UDP 4500 for NAT traversal, ESP Protocol 50). It is harder to deploy but provides full network-layer access. SSL-VPN tunnels traffic over HTTPS (TCP 443), which passes through almost every firewall and can work from browsers (clientless mode) or thin clients. SSL-VPN uses TLS for the outer tunnel, so it benefits from TLS security improvements and is easier for users to connect with. Enterprise SSL-VPN products (Cisco AnyConnect, Palo Alto GlobalProtect) also support split tunneling and endpoint posture assessment.
# Comparison table
Feature IPsec VPN SSL-VPN
Layer Network (L3) Application (L7)
Ports needed UDP 500,4500 TCP 443
Firewall traversal Difficult Easy
Client software Required Optional (browser)
Split tunneling Supported Supported
Mobile support Good (IKEv2) Excellent
Performance Generally faster Slight TLS overhead
Use case Site-to-site Remote user accessSplit Tunneling
Split tunneling allows VPN clients to route only corporate-bound traffic through the VPN tunnel while sending internet-bound traffic directly to the internet without passing through corporate security controls. The security risk: a compromised endpoint can simultaneously access the corporate network (via VPN) and communicate with malware C2 servers (direct internet) — effectively bridging the corporate network to the attacker. Full tunneling routes all traffic through the VPN gateway, where corporate security controls (web filtering, DLP, IPS) inspect it. Most security-conscious organizations enforce full tunneling, accepting the bandwidth overhead.
# Split tunneling vs full tunneling
# Split tunneling (risky):
# - Traffic to 10.0.0.0/8 -> VPN tunnel
# - All other traffic -> direct internet
# Risk: malware on endpoint can reach C2 + internal network
# Full tunneling (secure):
# - ALL traffic -> VPN gateway
# - Gateway applies web filtering, IPS, DLP
# - Increased gateway bandwidth cost
# Cisco AnyConnect enforce full tunnel:
# vpn-tunnel-protocol ssl-client
# split-tunnel-policy tunnelallWireGuard
WireGuard is a modern VPN protocol designed to be simpler, faster, and more secure than IPsec and OpenVPN. WireGuard uses a fixed, minimal cryptographic stack: ChaCha20 for symmetric encryption, Poly1305 for authentication, Curve25519 for ECDH key exchange, BLAKE2s for hashing, and SipHash24 for hash table keys. Its code base is under 4,000 lines (versus 100,000+ for OpenVPN), making it auditable and reducing the attack surface. WireGuard is now built into the Linux kernel (5.6+) and is supported on all major platforms.
# WireGuard configuration example
# /etc/wireguard/wg0.conf (server)
[Interface]
PrivateKey = <server_private_key>
Address = 10.100.0.1/24
ListenPort = 51820
[Peer] # Client peer
PublicKey = <client_public_key>
AllowedIPs = 10.100.0.2/32
# /etc/wireguard/wg0.conf (client)
[Interface]
PrivateKey = <client_private_key>
Address = 10.100.0.2/24
DNS = 10.100.0.1
[Peer] # Server peer
PublicKey = <server_public_key>
Endpoint = vpn.company.com:51820
AllowedIPs = 0.0.0.0/0 # Full tunnelSite-to-Site VPNs
Site-to-site VPNs connect entire networks (branch offices, data centers, cloud VPCs) through persistent encrypted tunnels between gateway devices. Unlike remote-access VPNs where individual users connect, site-to-site tunnels are always-on between fixed endpoints. IPsec in tunnel mode is the most common technology. Configuration requires matching IKE proposals (encryption, integrity, DH group, lifetime) on both ends — mismatches are the most common site-to-site troubleshooting issue. Redundant tunnels with dead peer detection (DPD) provide failover when the primary path fails.
# IPsec site-to-site check (strongSwan)
ipsec status
ipsec statusall | grep ESTABLISHED
# Verify SA negotiated correctly
ip xfrm state list
# Shows: SPI, encryption algo, auth algo, mode
# Debug IKE negotiation
ipsec stroke loglevel all 4
tail -f /var/log/syslog | grep -i ike
# Common mismatch errors:
# 'no proposal chosen' = IKE algorithms don't match
# 'TS_UNACCEPTABLE' = Traffic selectors mismatchVPN Authentication Methods
VPNs support multiple authentication mechanisms. Pre-shared keys (PSK): a shared secret configured on both endpoints — simple but creates a single point of compromise if the key is leaked; suitable for site-to-site. Certificate-based authentication: each client or gateway presents an X.509 certificate — stronger, scales to many users, certificates can be revoked. EAP (Extensible Authentication Protocol): supports RADIUS integration, enabling username/password, MFA (EAP-TTLS, EAP-TLS), and integration with Active Directory. Most enterprise deployments combine certificate authentication (device identity) with MFA (user identity).
VPN Endpoint Posture Assessment
Modern VPN gateways perform endpoint posture checks before granting access, ensuring that connecting devices meet security requirements. Checks include: OS version and patch level (reject end-of-life OS), antivirus installation and signature currency, disk encryption enabled, no unauthorized software installed, and firewall active. Devices that fail posture checks are placed in a quarantine VLAN with limited access — typically only remediation resources — until they meet policy. This prevents a compromised personal device from directly accessing the production corporate network, even with valid credentials.
Always-On VPN
Always-on VPN ensures that corporate endpoints maintain a persistent VPN connection whenever they are off the corporate network. Unlike traditional VPNs where users manually connect, always-on VPN connects before login (sometimes using machine certificate authentication) and remains connected throughout the session. This ensures all endpoint traffic is inspected by corporate security controls even for remote employees. Microsoft DirectAccess (predecessor) and solutions like Cisco AnyConnect Always-On and GlobalProtect implement this model. The tradeoff is increased gateway load — every remote endpoint maintains a permanent session.
VPN Concentrators and High Availability
A VPN concentrator is a dedicated appliance or virtual device that terminates large numbers of VPN sessions, handling the cryptographic processing load that would overwhelm a general-purpose router or firewall. Enterprise VPN concentrators support thousands of simultaneous sessions and integrate with RADIUS for authentication, LDAP/AD for user lookups, and certificate authorities for client certificate validation. High availability (HA) configurations use active/standby or active/active clusters with session synchronization so that users are not disconnected if one concentrator fails. Proper HA planning is essential for organizations that depend on VPN for critical operations.
Quick Check
Test your understanding of CompTIA Security+ (SY0-701) concepts from this lesson.
Lesson Recap
In this lesson you learned: IPsec secures IP traffic at Layer 3 using AH (integrity only) or ESP (encryption + integrity) in transport or tunnel mode with IKEv2 for key negotiation, SSL-VPN tunnels over HTTPS making it easier to deploy through firewalls compared to IPsec, and split tunneling creates a security risk by allowing malware on endpoints to reach the internet directly while the VPN provides corporate network access simultaneously. This completes the Secure Protocols course — next up we explore Zero Trust Architecture.
Frequently asked questions
Is the “IPsec, VPN Protocols, and Remote Access Security” lesson free?
Yes — the full text of “IPsec, VPN Protocols, and Remote Access Security” is free to read here on the web, and the Cloud & IT Cert Prep course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Cloud & IT Cert Prep course, upgrade to CoddyKit PRO.
What will I learn in “IPsec, VPN Protocols, and Remote Access Security”?
Compare IPsec tunnel and transport modes, SSL-VPN, and WireGuard for secure remote access, and understand split tunneling risks. You practise Cloud & IT Cert Prep with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.
Do I need any experience to start Cloud & IT Cert Prep?
No prior experience is required. Cloud & IT Cert Prep on CoddyKit is structured for beginners through advanced learners; this is — lesson 4 of 4, so you can start here or from the beginning and move at your own pace.
How long does the “IPsec, VPN Protocols, and Remote Access Security” lesson take?
Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.
Can I write and run code in this Cloud & IT Cert Prep lesson?
Yes. Every Cloud & IT Cert Prep lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.
All lessons in this course
- Replacing Insecure Protocols: Telnet vs SSH, FTP vs SFTP
- TLS Versions, Cipher Suites, and Perfect Forward Secrecy
- Secure DNS: DNSSEC and DNS over HTTPS (DoH)
- IPsec, VPN Protocols, and Remote Access Security