ldhnam
Công nghệ, kinh tế, và những suy nghĩ rời rạc.Technology, economics, and scattered thoughts.
← Kỹ sư mạng← Network Engineer
Kỹ sư mạngNetwork Engineer19 Th7, 2026Jul 19, 202623 phút đọc19 min read

VPN & TunnelingVPN & Tunneling

Thuộc bộ kiến thức Network Engineer Roadmap.

Tổng quan

Một tunnel là kỹ thuật mang một network protocol này làm payload của một protocol khác. Packet gốc — với header và data riêng của nó — được bọc lại (“encapsulation”) bên trong một packet mới, gửi qua một mạng trung gian, rồi được gỡ ra (“decapsulation”) ở đầu bên kia. Với hai đầu cuối, tunnel trông như một hop logic duy nhất dù thực tế có rất nhiều hop vật lý nằm giữa. Cách hình dung kinh điển là một lá thư (inner packet) niêm phong trong một phong bì chuyển phát (outer packet): hệ thống bưu chính chỉ đọc phong bì bên ngoài; lá thư bên trong được giao nguyên vẹn.

Một VPN (Virtual Private Network) là một tunnel có thêm bảo mật — confidentiality (encryption), integrity (phát hiện giả mạo), và authentication (chứng minh danh tính các peer) — nhờ đó một mạng public không tin cậy như Internet có thể được dùng như thể nó là một đường private. Không phải tunnel nào cũng là VPN (một GRE tunnel thuần chỉ encapsulate chứ không encrypt), và không phải VPN nào cũng dùng một encapsulation header riêng, nhưng trong thực tế hai khái niệm này thường đi cùng nhau.

Tunnel và VPN tồn tại để giải quyết ba (bốn) vấn đề lặp đi lặp lại:

  1. Privacy trên mạng public — một nhân viên làm việc từ xa qua Wi-Fi quán cà phê sẽ encrypt toàn bộ traffic để không ai trên segment cục bộ hay dọc đường truyền có thể đọc hoặc sửa đổi.
  2. Kết nối các site — hai văn phòng ở hai thành phố khác nhau hoạt động như một mạng private duy nhất qua Internet, mà không phải thuê một private circuit đắt đỏ.
  3. Remote access — một laptop hay điện thoại cá nhân truy cập vào mạng công ty hoặc cloud từ bất cứ đâu, như thể đang cắm trực tiếp vào LAN.
  4. Vận chuyển các protocol mà mạng bên dưới không mang được natively — ví dụ mang một routing protocol, multicast, hay một protocol không phải IP qua một backbone chỉ có IP, hoặc mang IPv6 qua một đường chỉ có IPv4.

Note này trình bày cơ chế của tunneling và các công nghệ VPN chính mà một network engineer sẽ gặp: IPsec, SSL/TLS VPN, GRE, MPLS L3VPN, SD-WAN, cloud VPN, và các protocol hiện đại như WireGuard và OpenVPN. Về bối cảnh bảo mật rộng hơn, xem ./11-network-security.md; về routing qua tunnel, xem ./07-routing.md; về kết nối tới các cloud provider, xem ./16-cloud-networking.md.

Kiến thức nền tảng

Encapsulation: một protocol nằm trong một protocol khác

Encapsulation là trái tim của mọi tunnel. Khi một packet đi vào tunnel, tunneling protocol thêm header vào đầu (và đôi khi vào cuối), tạo ra các lớp lồng nhau:

Packet gốc:
[ IP header | TCP/UDP | application data ]

Sau khi tunneling (ví dụ GRE over IP):
[ Outer IP | GRE | IP header | TCP/UDP | application data ]
       ^ header giao vận       ^ packet gốc, giờ là payload

Sau IPsec ESP tunnel mode:
[ Outer IP | ESP hdr | (đã encrypt){ IP header | TCP/UDP | data } | ESP trailer | ESP auth ]

Việc bọc packet trong header phụ dẫn tới hai hệ quả:

Vị trí của tunnel trong stack

Tunnel / VPNEncapsulate ởCó encrypt?Dùng điển hình
GRELayer 3 (kiểu IP-in-IP)KhôngMang routing/multicast, nối các mạng
IPsecLayer 3 (IP)CóSite-to-site, remote access an toàn
SSL/TLS VPNLayer 4+ (trên TCP/UDP)CóRemote access, xuyên firewall tốt
WireGuardLayer 3 (trên UDP)CóSite-to-site & remote access hiện đại
MPLS L3VPNLabel switching L3 của providerKhông (tin cậy provider)WAN của nhà mạng giữa các site
VXLANLayer 2 trên UDPKhông (thường vậy)Overlay trong data-center

Tunnel endpoint và khái niệm overlay

Một tunnel được xác định bởi hai endpoint (các thiết bị encapsulate và decapsulate). Mạng mà tunnel chạy trên đó gọi là underlay; mạng ảo hình thành bởi các tunnel gọi là overlay. Sự tách biệt overlay/underlay này là nền tảng của SD-WAN, data-center fabric (VXLAN), và cloud networking: overlay có thể có addressing và routing riêng, hoàn toàn độc lập với transport vật lý bên dưới.

Khái niệm chính

IPsec

IPsec là một bộ chuẩn mở (RFC 4301 là kiến trúc) bảo vệ IP traffic ở Layer 3. Vì hoạt động ở lớp IP, nó bảo vệ mọi thứ nằm trên nó (TCP, UDP, và tất cả application) một cách trong suốt — application không cần thay đổi gì. Đây là “con ngựa thồ” của các site-to-site VPN.

IPsec có hai security protocol và hai mode, cùng với một protocol trao đổi khóa (IKE) để thiết lập mọi thứ.

AH vs ESP

AH (Authentication Header)ESP (Encapsulating Security Payload)
RFC43024303
Confidentiality (encryption)KhôngCó
Integrity & authenticationCóCó
Bảo vệ outer IP headerCó (một phần)Không (chỉ phần payload nó bọc)
Hoạt động qua NATKhông (hỏng vì nó cover IP header)Có (với NAT-Traversal / UDP 4500)
Trên thực tếHiếm khi dùng ngày nayLựa chọn mặc định, dùng gần như ở mọi nơi

AH cung cấp integrity và authentication nhưng không encryption, và vì nó authenticate một phần outer IP header nên bị NAT làm hỏng. ESP cung cấp cả encryption lẫn integrity và sống sót qua NAT nhờ NAT-T. Trong triển khai hiện đại bạn gần như luôn dùng ESP; AH về cơ bản là legacy.

Transport mode vs tunnel mode

Transport mode:  [ IP gốc | ESP | (encrypt) TCP+data | ESP trl/auth ]
Tunnel mode:     [ IP MỚI | ESP | (encrypt){ IP gốc | TCP+data } | ESP trl/auth ]

IKE, IKEv2, các phase, và Security Association

Trước khi bất kỳ data nào được bảo vệ, hai peer phải thống nhất về khóa và tham số. Việc này do IKE (Internet Key Exchange) đảm nhiệm, ngày nay gần như luôn là IKEv2 (RFC 7296), vốn đơn giản hơn, nhanh hơn và bền bỉ hơn IKEv1.

Một Security Association (SA) là một thỏa thuận một chiều mô tả cách traffic được bảo vệ: protocol (ESP), cipher và hash, khóa, và một Security Parameter Index (SPI) để nhận diện nó. Vì SA là một chiều, một tunnel hai chiều bình thường có ít nhất hai IPsec SA.

Quá trình đàm phán IKE diễn ra theo hai phase:

PhaseTên IKEv1Exchange IKEv2Làm gì
Phase 1Main/Aggressive ModeIKE_SA_INIT + IKE_AUTHAuthenticate các peer, thiết lập kênh điều khiển an toàn (IKE SA) qua Diffie-Hellman
Phase 2Quick ModeCREATE_CHILD_SAĐàm phán các IPsec (ESP) SA thực sự bảo vệ data — các “child SA”

Phase 1 dựng nên một kênh an toàn, đã được authenticate (dùng pre-shared key hoặc certificate). Phase 2 dùng kênh đó để đàm phán các khóa ESP nhanh, theo từng luồng traffic. Khóa được rekey định kỳ theo lifetime (giây) hoặc theo dung lượng (byte) để một khóa bị lộ chỉ bảo vệ một khoảng nhỏ; dùng một Diffie-Hellman exchange mới khi rekey sẽ đem lại Perfect Forward Secrecy (PFS).

Một cấu hình site-to-site IPsec điển hình (Cisco IOS, IKEv2)

! Phase 1 (IKEv2 proposal + policy)
crypto ikev2 proposal PROP
 encryption aes-cbc-256
 integrity sha256
 group 14
crypto ikev2 policy POL
 proposal PROP

crypto ikev2 keyring KR
 peer BRANCH
  address 203.0.113.2
  pre-shared-key MySecretKey123

crypto ikev2 profile PROF
 match identity remote address 203.0.113.2 255.255.255.255
 authentication local pre-share
 authentication remote pre-share
 keyring local KR

! Phase 2 (ESP transform set) + policy về những gì cần bảo vệ
crypto ipsec transform-set TS esp-aes 256 esp-sha256-hmac
 mode tunnel
crypto ipsec profile IPSEC-PROF
 set transform-set TS
 set ikev2-profile PROF

! Gắn vào một tunnel interface (kiểu VTI)
interface Tunnel0
 ip address 10.255.255.1 255.255.255.252
 tunnel source GigabitEthernet0/0
 tunnel destination 203.0.113.2
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile IPSEC-PROF

Lệnh kiểm tra hữu ích: show crypto ikev2 sa (Phase 1 đã up chưa?), show crypto ipsec sa (Phase 2, có packet được encrypt/decrypt không?).

SSL/TLS VPN

Một SSL/TLS VPN bảo vệ remote access bằng chính protocol TLS vốn dùng để bảo vệ HTTPS. Vì TLS chạy trên TCP (thường là port 443) hoặc DTLS trên UDP, một SSL VPN xuyên qua firewall, proxy và NAT gần như không cần cấu hình đặc biệt — bất cứ nơi nào cho phép lướt web thì cho phép VPN. Đây là ưu thế thực tế lớn nhất của nó so với IPsec, vốn cần UDP 500/4500 và ESP được cho phép end-to-end.

Hai dạng phổ biến:

IPsec VPN vs SSL VPN

Khía cạnhIPsec VPNSSL/TLS VPN
Lớp OSINetwork (Layer 3)Transport/Session (Layer 4+)
Port/protocol điển hìnhUDP 500 & 4500, ESP (proto 50)TCP 443 / DTLS UDP 443
Thân thiện với firewall/NATCó thể bị chặn; cần NAT-TXuất sắc — trông như HTTPS
Phần mềm clientClient hoặc hỗ trợ native của OSBrowser (clientless) hoặc client nhẹ
Độ chi tiếtTruy cập toàn mạngCấp app (portal) hoặc toàn mạng
Phù hợp nhất choSite-to-site; network access luôn bậtNgười dùng remote, BYOD, mạng bị hạn chế
Hiệu năngRất hiệu quả, ở kernel-levelCó chút overhead TCP-over-TCP (mode TCP)

Quy tắc ngón tay cái: dùng IPsec cho site-to-site và các thiết bị được quản lý, kiểm soát; dùng SSL VPN cho người dùng remote, thiết bị unmanaged/BYOD, và bất cứ nơi nào firewall khắt khe khiến IPsec khó triển khai.

VPN topology

Site-to-site vs remote-access

Hub-and-spoke vs full mesh

Full tunnel vs split tunneling

Full tunnelSplit tunneling
Cái gì đi qua VPNToàn bộ traffic, kể cả duyệt InternetChỉ các subnet công ty/được định nghĩa; Internet đi thẳng
Bảo mật/khả năng quan sátTối đa — mọi traffic được kiểm soát của công ty inspectÍt hơn — traffic Internet trực tiếp bỏ qua inspection của công ty
Hiệu năng / băng thôngBackhaul mọi thứ về HQ (có thể chậm, dùng băng thông HQ)Hiệu quả; latency thấp tới Internet/SaaS
Dùng điển hìnhMôi trường bảo mật cao, tuân thủNgười dùng bị giới hạn băng thông, dùng nhiều SaaS/O365

Split tunneling giảm tải và cải thiện trải nghiệm người dùng nhưng mở rộng attack surface (một laptop bị compromise có một chân trên mạng công ty và một chân trên Internet mở). Nhiều tổ chức dùng phương án lai: tunnel các subnet công ty, cho phép SaaS tin cậy đi thẳng.

GRE và GRE-over-IPsec

GRE (Generic Routing Encapsulation), định nghĩa trong RFC 2784, là một tunneling protocol đơn giản, stateless, bọc gần như mọi payload Layer 3 trong một header GRE + IP. Điểm mạnh của nó: nó có thể mang multicast, broadcast, và routing protocol (OSPF, EIGRP) và cả các protocol không phải IP — những thứ mà IPsec tunnel mode thuần không mang được natively.

Điểm yếu chí mạng: GRE không cung cấp encryption, không confidentiality, và không authentication. Bất cứ ai trên đường truyền đều có thể đọc nội dung một GRE tunnel. GRE thuần ổn trên một mạng tin cậy nhưng tuyệt đối không được tin dùng để bảo vệ data qua Internet.

Giải pháp tiêu chuẩn là GRE over IPsec: dựng một GRE tunnel (để có thể chạy routing protocol và mang multicast), rồi bảo vệ GRE tunnel đó bằng IPsec (thường là transport mode, vì header GRE đã cung cấp phần tunnel encapsulation rồi). Bạn có được sự linh hoạt của GRE cùng với sự bảo mật của IPsec.

interface Tunnel0
 ip address 10.0.0.1 255.255.255.252
 tunnel source GigabitEthernet0/0
 tunnel destination 198.51.100.2
 tunnel protection ipsec profile IPSEC-PROF   ! bọc GRE tunnel trong IPsec
!
router ospf 1
 network 10.0.0.0 0.0.0.3 area 0             ! OSPF giờ chạy qua tunnel đã encrypt

Encapsulation kết quả: [ Outer IP | ESP | GRE | inner IP | data | ESP trl ].

MPLS VPN (L3VPN) vs Internet VPN

MPLS L3VPN là một dịch vụ do nhà mạng cung cấp: backbone MPLS của provider giữ route của mỗi khách hàng trong các VRF riêng biệt và forward traffic bằng label thay vì qua Internet public. Từ góc nhìn của khách hàng, mọi site cùng gia nhập một mạng private có định tuyến mà khách hàng không phải chạy tunnel nào.

MPLS L3VPNInternet VPN (IPsec/SSL)
Ai vận hànhNhà mạngBạn, trên bất kỳ đường Internet nào
EncryptionMặc định không có (dựa vào isolation của provider)Có (bạn kiểm soát)
Hiệu năng / SLACó thể dự đoán, QoS & SLA đảm bảoBest-effort của Internet
Chi phíCao (dịch vụ thuê)Thấp (dùng Internet phổ thông)
Tốc độ cung cấpNhiều tuần (lead time của nhà mạng)Vài phút/giờ
Phạm viGiới hạn trong vùng phủ của providerBất cứ đâu có Internet

MPLS cho hiệu năng và QoS có thể dự đoán nhưng đắt và chậm cung cấp; Internet VPN rẻ và triển khai nhanh nhưng chạy trên Internet best-effort. SD-WAN (bên dưới) phần lớn tồn tại để lấy được cái tốt nhất của cả hai. Chi tiết routing cho cả hai nằm ở ./07-routing.md.

SD-WAN

WAN truyền thống backhaul traffic của chi nhánh qua một MPLS circuit đắt đỏ duy nhất về một hub trung tâm, điều này tốn kém và kém hiệu quả trong thế giới cloud/SaaS nơi phần lớn traffic hướng tới Internet chứ không phải HQ. SD-WAN (Software-Defined WAN) giải quyết vấn đề này bằng cách tách WAN khỏi transport bên dưới.

Các ý tưởng cốt lõi:

WAN truyền thống / MPLSSD-WAN
TransportMột circuit của một providerNhiều/bất kỳ đường (MPLS + broadband + LTE)
Cấu hìnhCLI theo từng thiết bịTập trung, theo policy
Chọn đườngStatic routingĐộng, nhận biết application
Traffic cloud/SaaSBackhaul về hubBreakout tại chỗ
Chi phíCaoThấp hơn (Internet phổ thông)
FailoverChậm (routing convergence)Dưới một giây, tự động

SD-WAN không nhất thiết thay thế MPLS — nhiều nơi giữ MPLS cho các app quan trọng và thêm broadband cho phần còn lại, với SD-WAN kết hợp thông minh cả hai.

Cloud VPN

Kết nối một mạng on-premises tới VPC/VNet của một cloud provider là công việc hằng ngày. Có hai họ kết nối:

Một pattern phổ biến là dùng dedicated circuit cho phần lớn traffic với một IPsec VPN làm backup đã encrypt. Xem ./16-cloud-networking.md về thiết kế VPC, transit gateway, và cloud routing.

Các VPN protocol hiện đại: WireGuard và OpenVPN

# /etc/wireguard/wg0.conf (một peer)
[Interface]
PrivateKey = <private-key-cua-peer-nay>
Address = 10.10.0.2/24
ListenPort = 51820

[Peer]
PublicKey = <public-key-cua-peer-kia>
Endpoint = vpn.example.com:51820
AllowedIPs = 10.10.0.0/24, 192.168.1.0/24   # route nào đi qua tunnel
PersistentKeepalive = 25                     # giữ NAT mapping còn sống

Bảng so sánh tổng hợp các loại VPN

Loại VPNLớpEncryptEncapsulationDùng chínhGhi chú
IPsec (tunnel mode)L3CóESP / IP mớiSite-to-site, remote accessChuẩn, trong suốt với app, NAT qua NAT-T
SSL/TLS VPN (OpenVPN, AnyConnect)L4+CóTLS/DTLS trên TCP/UDP 443Remote access, BYODThân thiện firewall, có tùy chọn clientless
GREL3KhôngGRE / IPMang routing/multicastGhép với IPsec để bảo mật
GRE-over-IPsec / DMVPNL3CóGRE trong ESPSite-to-site mesh độngRouting + encryption cùng lúc
WireGuardL3CóUDPS2S & remote hiện đạiNhanh, đơn giản, native trong kernel
MPLS L3VPNL3 của providerKhông (isolation của provider)MPLS labelWAN của nhà mạngQoS/SLA dự đoán được, tốn kém
SD-WANOverlay (L3)CóOverlay IPsec/GREWAN nhiều siteTransport-independent, nhận biết app
Cloud VPNL3CóIPsec/IKEv2On-prem ↔ cloud VPCGhép với Direct Connect/ExpressRoute/Interconnect

Best Practices

Tài liệu tham khảo

Part of the Network Engineer Roadmap knowledge base.

Overview

A tunnel is a technique that carries one network protocol as the payload of another. The original packet — with its own headers and data — is wrapped (“encapsulated”) inside a new outer packet, shipped across an intermediate network, and unwrapped (“decapsulated”) at the far end. To the endpoints, the tunnel looks like a single logical hop even though many physical hops sit in between. The classic mental model is a letter (the inner packet) sealed inside a shipping envelope (the outer packet): the postal system only reads the outer envelope; the letter inside is delivered untouched.

A VPN (Virtual Private Network) is a tunnel that adds security — confidentiality (encryption), integrity (tamper detection), and authentication (proving who the peers are) — so that a public, untrusted network like the Internet can be used as if it were a private link. Not every tunnel is a VPN (a plain GRE tunnel encapsulates but does not encrypt), and not every VPN uses a separate encapsulation header, but in practice the two ideas travel together.

Tunnels and VPNs exist to solve three recurring problems:

  1. Privacy over a public network — a remote worker on café Wi-Fi encrypts all traffic so no one on the local segment or along the path can read or modify it.
  2. Connecting sites — two offices in different cities behave as one private network over the Internet, without leasing an expensive private circuit.
  3. Remote access — an individual laptop or phone reaches into a corporate or cloud network from anywhere, as if physically plugged into the LAN.
  4. Transporting protocols the underlying network cannot carry natively — e.g. carrying a routing protocol, multicast, or a non-IP protocol across an IP-only backbone, or carrying IPv6 across an IPv4-only path.

This note covers the mechanics of tunneling and the main VPN technologies a network engineer meets: IPsec, SSL/TLS VPNs, GRE, MPLS L3VPN, SD-WAN, cloud VPN, and modern protocols like WireGuard and OpenVPN. For the broader security context see ./11-network-security.md; for routing over tunnels see ./07-routing.md; for connecting to cloud providers see ./16-cloud-networking.md.

Fundamentals

Encapsulation: a protocol inside another protocol

Encapsulation is the heart of every tunnel. When a packet enters a tunnel, the tunneling protocol prepends (and sometimes appends) headers, producing nested layers:

Original packet:
[ IP header | TCP/UDP | application data ]

After tunneling (e.g. GRE over IP):
[ Outer IP | GRE | IP header | TCP/UDP | application data ]
       ^ delivery header       ^ the original packet, now payload

After IPsec ESP tunnel mode:
[ Outer IP | ESP hdr | (encrypted){ IP header | TCP/UDP | data } | ESP trailer | ESP auth ]

Two consequences follow from wrapping a packet in extra headers:

Where tunnels sit in the stack

Tunnel / VPNEncapsulates atEncrypts?Typical use
GRELayer 3 (IP-in-IP-ish)NoCarry routing/multicast, connect networks
IPsecLayer 3 (IP)YesSite-to-site, secure remote access
SSL/TLS VPNLayer 4+ (over TCP/UDP)YesRemote access, works through firewalls
WireGuardLayer 3 (over UDP)YesModern site-to-site & remote access
MPLS L3VPNProvider Layer 3 label switchingNo (provider-trusted)Carrier WAN between sites
VXLANLayer 2 over UDPNo (usually)Data-center overlays

Tunnel endpoints and the overlay concept

A tunnel is defined by its two endpoints (the devices that encapsulate and decapsulate). The network the tunnel rides over is the underlay; the virtual network formed by the tunnels is the overlay. This overlay/underlay separation is fundamental to SD-WAN, data-center fabrics (VXLAN), and cloud networking: the overlay can have its own addressing and routing that is completely independent of the physical transport underneath.

Key Concepts

IPsec

IPsec is a suite of open standards (RFC 4301 is the architecture) that secures IP traffic at Layer 3. Because it operates at the IP layer, it protects everything above it (TCP, UDP, and all applications) transparently — the applications need no changes. It is the workhorse of site-to-site VPNs.

IPsec has two security protocols and two modes, and it uses a key-exchange protocol (IKE) to set everything up.

AH vs ESP

AH (Authentication Header)ESP (Encapsulating Security Payload)
RFC43024303
Confidentiality (encryption)NoYes
Integrity & authenticationYesYes
Protects outer IP headerYes (parts of it)No (only the payload it encapsulates)
Works through NATNo (breaks because it covers the IP header)Yes (with NAT-Traversal / UDP 4500)
In practiceRarely used todayThe default choice, used almost everywhere

AH provides integrity and authentication but no encryption, and because it authenticates parts of the outer IP header it is broken by NAT. ESP provides encryption and integrity and survives NAT via NAT-T. In modern deployments you almost always use ESP; AH is effectively legacy.

Transport mode vs tunnel mode

Transport mode:  [ orig IP | ESP | (encrypted) TCP+data | ESP trl/auth ]
Tunnel mode:     [ NEW IP  | ESP | (encrypted){ orig IP | TCP+data } | ESP trl/auth ]

IKE, IKEv2, phases, and Security Associations

Before any data is protected, the two peers must agree on keys and parameters. This is done by IKE (Internet Key Exchange), today almost always IKEv2 (RFC 7296), which is simpler, faster, and more robust than IKEv1.

A Security Association (SA) is a one-way agreement describing how traffic is protected: the protocol (ESP), the cipher and hash, the keys, and a Security Parameter Index (SPI) that identifies it. Because SAs are unidirectional, a normal bidirectional tunnel has at least two IPsec SAs.

IKE negotiation happens in two phases:

PhaseIKEv1 nameIKEv2 exchangeWhat it does
Phase 1Main/Aggressive ModeIKE_SA_INIT + IKE_AUTHAuthenticate the peers, establish a secure control channel (the IKE SA) via Diffie-Hellman
Phase 2Quick ModeCREATE_CHILD_SANegotiate the IPsec (ESP) SAs that actually protect the data — the “child SAs”

Phase 1 builds a secure, authenticated channel (using pre-shared keys or certificates). Phase 2 uses that channel to negotiate the fast, per-traffic ESP keys. Keys are periodically rekeyed based on lifetime (seconds) or volume (bytes) so a compromised key protects only a small window; using a fresh Diffie-Hellman exchange at rekey gives Perfect Forward Secrecy (PFS).

A typical site-to-site IPsec config (Cisco IOS, IKEv2)

! Phase 1 (IKEv2 proposal + policy)
crypto ikev2 proposal PROP
 encryption aes-cbc-256
 integrity sha256
 group 14
crypto ikev2 policy POL
 proposal PROP

crypto ikev2 keyring KR
 peer BRANCH
  address 203.0.113.2
  pre-shared-key MySecretKey123

crypto ikev2 profile PROF
 match identity remote address 203.0.113.2 255.255.255.255
 authentication local pre-share
 authentication remote pre-share
 keyring local KR

! Phase 2 (ESP transform set) + policy of what to protect
crypto ipsec transform-set TS esp-aes 256 esp-sha256-hmac
 mode tunnel
crypto ipsec profile IPSEC-PROF
 set transform-set TS
 set ikev2-profile PROF

! Bind to a tunnel interface (VTI style)
interface Tunnel0
 ip address 10.255.255.1 255.255.255.252
 tunnel source GigabitEthernet0/0
 tunnel destination 203.0.113.2
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile IPSEC-PROF

Useful verification: show crypto ikev2 sa (Phase 1 up?), show crypto ipsec sa (Phase 2, packets encrypted/decrypted?).

SSL/TLS VPN

An SSL/TLS VPN secures remote access using the same TLS protocol that protects HTTPS. Because TLS runs over TCP (usually port 443) or DTLS over UDP, an SSL VPN traverses firewalls, proxies, and NAT with almost no special configuration — anything that allows web browsing allows the VPN. This is its biggest practical advantage over IPsec, which needs UDP 500/4500 and ESP to be permitted end to end.

Two common flavours:

IPsec VPN vs SSL VPN

AspectIPsec VPNSSL/TLS VPN
OSI layerNetwork (Layer 3)Transport/Session (Layer 4+)
Typical port/protocolUDP 500 & 4500, ESP (proto 50)TCP 443 / DTLS UDP 443
Firewall/NAT friendlinessCan be blocked; needs NAT-TExcellent — looks like HTTPS
Client softwareClient or native OS supportBrowser (clientless) or light client
GranularityWhole-network accessApp-level (portal) or full network
Best forSite-to-site; always-on network accessRemote users, BYOD, restrictive networks
PerformanceVery efficient, kernel-levelSlight TCP-over-TCP overhead (TCP mode)

Rule of thumb: use IPsec for site-to-site and controlled, managed devices; use SSL VPN for remote users, unmanaged/BYOD devices, and anywhere restrictive firewalls make IPsec painful.

VPN topologies

Site-to-site vs remote-access

Hub-and-spoke vs full mesh

Full tunnel vs split tunneling

Full tunnelSplit tunneling
What goes through the VPNAll traffic, including Internet browsingOnly corporate/defined subnets; Internet goes direct
Security/visibilityMaximum — all traffic inspected by corporate controlsLess — direct Internet traffic bypasses corporate inspection
Performance / bandwidthBackhauls everything to HQ (can be slow, uses HQ bandwidth)Efficient; low latency to Internet/SaaS
Typical useHigh-security environments, complianceBandwidth-constrained users, heavy SaaS/O365 use

Split tunneling reduces load and improves user experience but widens the attack surface (a compromised laptop has one foot on the corporate net and one on the open Internet). Many orgs use a hybrid: tunnel corporate subnets, allow trusted SaaS directly.

GRE and GRE-over-IPsec

GRE (Generic Routing Encapsulation), defined in RFC 2784, is a simple, stateless tunneling protocol that wraps almost any Layer 3 payload in a GRE + IP header. Its strengths: it can carry multicast, broadcast, and routing protocols (OSPF, EIGRP) and non-IP protocols — things plain IPsec tunnel mode cannot carry natively.

Its critical weakness: GRE provides no encryption, no confidentiality, and no authentication. Anyone on the path can read a GRE tunnel’s contents. GRE alone is fine on a trusted network but must never be trusted to protect data over the Internet.

The standard solution is GRE over IPsec: build a GRE tunnel (so you can run a routing protocol and carry multicast), then protect that GRE tunnel with IPsec (usually transport mode, since the GRE header already provides the tunnel encapsulation). You get GRE’s flexibility and IPsec’s security.

interface Tunnel0
 ip address 10.0.0.1 255.255.255.252
 tunnel source GigabitEthernet0/0
 tunnel destination 198.51.100.2
 tunnel protection ipsec profile IPSEC-PROF   ! wraps the GRE tunnel in IPsec
!
router ospf 1
 network 10.0.0.0 0.0.0.3 area 0             ! OSPF now runs across the encrypted tunnel

Resulting encapsulation: [ Outer IP | ESP | GRE | inner IP | data | ESP trl ].

MPLS VPN (L3VPN) vs Internet VPN

MPLS L3VPN is a service delivered by a carrier: the provider’s MPLS backbone keeps each customer’s routes in separate VRFs and forwards traffic using labels rather than the public Internet. From the customer’s view, all sites join one private routed network without the customer running any tunnels.

MPLS L3VPNInternet VPN (IPsec/SSL)
Who operates itThe carrierYou, over any Internet link
EncryptionNone by default (relies on provider isolation)Yes (you control it)
Performance / SLAPredictable, guaranteed QoS & SLABest-effort Internet
CostHigh (leased service)Low (uses commodity Internet)
Provisioning speedWeeks (carrier lead time)Minutes/hours
ReachLimited to provider footprintAnywhere with Internet

MPLS gives predictable performance and QoS but is expensive and slow to provision; Internet VPNs are cheap and fast to deploy but ride best-effort Internet. SD-WAN (below) largely exists to get the best of both. Routing details for both live in ./07-routing.md.

SD-WAN

Traditional WANs backhaul branch traffic over a single expensive MPLS circuit to a central hub, which is costly and inefficient in a cloud/SaaS world where most traffic is destined for the Internet, not HQ. SD-WAN (Software-Defined WAN) solves this by decoupling the WAN from the underlying transport.

Key ideas:

Traditional WAN / MPLSSD-WAN
TransportSingle provider circuitAny/multiple links (MPLS + broadband + LTE)
ConfigurationPer-device CLICentralized, policy-driven
Path selectionStatic routingDynamic, application-aware
Cloud/SaaS trafficBackhauled to hubLocal breakout
CostHighLower (commodity Internet)
FailoverSlow (routing convergence)Sub-second, automatic

SD-WAN doesn’t necessarily replace MPLS — many keep MPLS for critical apps and add broadband for the rest, with SD-WAN intelligently blending both.

Cloud VPN

Connecting an on-premises network to a cloud provider’s VPC/VNet is a daily task. Two families of connectivity exist:

A common pattern is a dedicated circuit for the bulk of traffic with an IPsec VPN as an encrypted backup. See ./16-cloud-networking.md for VPC design, transit gateways, and cloud routing.

Modern VPN protocols: WireGuard and OpenVPN

# /etc/wireguard/wg0.conf (a peer)
[Interface]
PrivateKey = <this-peer-private-key>
Address = 10.10.0.2/24
ListenPort = 51820

[Peer]
PublicKey = <remote-peer-public-key>
Endpoint = vpn.example.com:51820
AllowedIPs = 10.10.0.0/24, 192.168.1.0/24   # what routes through the tunnel
PersistentKeepalive = 25                     # keeps NAT mappings alive

Summary comparison of VPN types

VPN typeLayerEncryptedEncapsulationPrimary useNotes
IPsec (tunnel mode)L3YesESP / new IPSite-to-site, remote accessStandard, transparent to apps, NAT via NAT-T
SSL/TLS VPN (OpenVPN, AnyConnect)L4+YesTLS/DTLS over TCP/UDP 443Remote access, BYODFirewall-friendly, clientless option
GREL3NoGRE / IPCarry routing/multicastCombine with IPsec for security
GRE-over-IPsec / DMVPNL3YesGRE inside ESPDynamic site-to-site meshRouting + encryption together
WireGuardL3YesUDPModern S2S & remoteFast, simple, kernel-native
MPLS L3VPNProvider L3No (provider isolation)MPLS labelsCarrier WANPredictable QoS/SLA, costly
SD-WANOverlay (L3)YesIPsec/GRE overlayMulti-site WANTransport-independent, app-aware
Cloud VPNL3YesIPsec/IKEv2On-prem ↔ cloud VPCPair with Direct Connect/ExpressRoute/Interconnect

Best Practices

References