Please enable JavaScript.
Coggle requires JavaScript to display documents.
VPN and IPsec Concepts - Coggle Diagram
VPN and IPsec Concepts
8.1. VPN Technology
Virtual Private Networks (VPNs) secure communication between sites and users by creating private, encrypted connections over public networks. Although data travels through the internet, encryption keeps it confidential. Early VPNs, such as Generic Routing Encapsulation (GRE), only created IP tunnels without encryption or authentication.
-
Modern VPNs use encryption technologies like IPsec and SSL to ensure data security. Their main benefits include:
-
-
-
-
-
-
8.2. Types of VPNs
1) Remote‑Access VPNs
- What it is: Secure, encrypted tunnel from an endpoint (laptop, phone) across an untrusted network to a VPN headend (firewall/router/VPN concentrator). The headend authenticates the user/device, applies policy, and grants access to internal resources.
- IPsec IKEv2 with tunnel mode for Layer 3 full‑tunnel access
- SSL/TLS for client‑based or clientless web portal access
- Authentication: usernames/passwords, MFA, certificates, SAML/OAuth to IdPs
- Split‑tunneling vs full‑tunneling
- Typical topologies: Many clients to one or more headends for redundancy and load balancing.
- Strengths: Strong encryption, granular authorization, scalable for mobile workforces, posture checks, always‑on options.
- Tradeoffs: Client deployment and updates, license management, potential latency with full‑tunnel, careful split‑tunnel design.
2) SSL VPNs
- What it is: VPNs built on SSL/TLS rather than native IPsec at the network layer.
- Clientless SSL VPN: Users access internal web apps via a secure portal and reverse proxy. No full network access.
- Client‑based SSL VPN: Installs a VPN client that creates a virtual adapter; traffic is encapsulated in TLS and can provide full Layer 3 access.
- Strengths: Works through most NATs and firewalls, minimal OS integration issues, good for web/SaaS and BYOD.
- Tradeoffs: Clientless is app‑limited. Client‑based SSL and IPsec overlap; choice depends on features, performance, and standardization.
-
4) GRE over IPsec
- Why: Native IPsec ESP secures unicast IP but lacks multi‑protocol and native multicast forwarding. GRE adds:
- Support for non‑IP protocols and packets needing a tunnel
- Multicast and broadcast forwarding to run dynamic routing protocols across the tunnel (EIGRP, OSPF, BGP)
- How it works: Build a GRE tunnel (logical L3 interface) between sites, then protect GRE packets with IPsec. Routing neighbors form over GRE; IPsec provides confidentiality and integrity on the wire.
- Tradeoffs: Extra encapsulation overhead and MTU tuning; more moving parts than “pure” IPsec.
-
-
-
8.3. IPsec
-
-
-
Algorithms and choices:
For confidentiality (encryption): e.g., AES, 3DES.
For integrity: e.g., SHA, MD5.
For authentication: Pre-Shared Keys (PSK), RSA certificates.
For Diffie-Hellman groups: some older groups (e.g., DH 1, 2, 5) are no longer recommended.
IPsec builds a Security Association (SA) between peers: this means an agreement on protocol (AH/ESP), keys, algorithms, and modes to secure the session
-
