6.1Secure protocols and VPN

Securing communication between locations or with remote workers over the internet requires countermeasures against eavesdropping, tampering, and impersonation. A network specialist must accurately select and design IPsec modes and SSL-VPN approaches according to requirements (always-on inter-site connectivity vs. occasional access from the field) and security needs (is confidentiality required, or do integrity and origin authentication suffice). This section builds a decision-making pattern grounded in how the protocols actually work.

6.1.1IPsec (ESP, AH, IKE)

• IPsec is a protocol suite providing per-packet authentication, integrity, and confidentiality at the IP layer. AH (Authentication Header) provides only origin authentication and integrity verification—it does not encrypt the payload. ESP (Encapsulating Security Payload) can provide encryption in addition to authentication and integrity, so ESP is chosen whenever confidentiality is required.
• Transport mode protects only the payload (upper-layer data) while leaving the original IP header intact; it is used for end-to-end communication (direct host-to-host). Tunnel mode encapsulates the entire original IP packet inside a new IP header; it is used for site-to-site VPN (gateway-to-gateway) and hides the internal network's addressing scheme from the outside.
• IKE (Internet Key Exchange) establishes mutual authentication and a SA (Security Association) (agreed cipher algorithms, keys, etc.) before IPsec communication begins. It is a two-phase process: IKE phase 1 establishes the IKE SA (protecting the control channel), and phase 2 establishes the IPsec SA (protecting the actual data).

6.1.2TLS and SSL-VPN

• TLS encrypts and authenticates application communication on top of the transport layer. It combines server authentication via a server certificate, sharing a session key through key exchange, and encrypting data with symmetric-key cryptography. HTTPS is HTTP protected by TLS.
• SSL-VPN implements remote-access VPN using TLS (historically called SSL). The clientless (reverse-proxy) mode, which needs no dedicated client software, has the advantage of browser-only access but supports a more limited set of applications. The L3 mode, which uses a dedicated client, offers flexibility closer to IPsec.

6.1.3Site-to-site VPN, remote-access VPN, and NAT traversal

• Site-to-site VPN provides an always-on connection between locations such as headquarters and branch offices via an IPsec tunnel between gateways (routers/firewalls). Remote-access VPN lets individual devices used by teleworkers or traveling staff connect to the internal network on an as-needed basis, using SSL-VPN or an IPsec client.
• NAT-T (NAT Traversal) exists because IPsec's AH/ESP conflict with the address/port rewriting NAT devices perform (AH's tamper detection flags the NAT rewrite as tampering, and ESP cannot preserve port numbers, so NAPT cannot distinguish multiple sessions). NAT-T encapsulates IPsec packets in UDP to allow them to traverse NAT.

Suppose a company wants to keep core-system traffic between headquarters and three branch offices always encrypted, while letting sales staff temporarily access the internal portal from a laptop while traveling. As the network designer, for headquarters-to-branch traffic you want to protect all inter-site traffic at all times and hide the internal private addressing scheme from outside, so you choose site-to-site VPN via an IPsec tunnel-mode (ESP) connection between gateways. AH would be unsuitable, since it does not encrypt and would leave the core-system traffic content readable to an eavesdropper. For the traveling sales staff, considering the operational cost of installing and maintaining an IPsec client on issued devices, and the possibility of connecting from a shared NAT environment such as hotel or cafe Wi-Fi, you choose SSL-VPN (clientless mode)—it works entirely through a browser, and since TLS runs over TCP it is inherently NAT-friendly, avoiding any need to think about extra traversal technology like NAT-T. If instead there were many mobile devices spread across sites and you needed to keep an IPsec-based configuration, you would need the design decision to enable NAT-T in anticipation of connections originating from behind NAT. Choosing along the axes of "always-on inter-site vs. on-demand individual devices" and "clientless simplicity vs. IPsec flexibility" is the essence of this design work.

6.1.4Section summary

• AH = no encryption (authentication/integrity only), ESP = encryption plus authentication/integrity. Choose ESP when confidentiality is required
• Transport mode = end-to-end, tunnel mode = between site gateways, hiding internal addressing
• Always-on inter-site connectivity uses site-to-site VPN, on-demand individual-device access uses SSL-VPN, and IPsec behind NAT needs NAT-T