VPN & IPsec Interview Questions & Answers

A VPN (Virtual Private Network) creates a secure, encrypted tunnel over an untrusted network like the public Internet, so that two endpoints can communicate as if they were on the same private network. Think of it like a sealed, armoured courier van driving on a public highway: the road is public, but no one can see or tamper with what's inside.

Organizations use VPNs to:

• Protect data in transit against eavesdropping and tampering.
• Connect branch offices securely (site-to-site).
• Let remote staff reach internal apps from home or while travelling.
• Save cost versus expensive private leased lines.

It does NOT make you anonymous or replace endpoint security — it secures the link, not the device.

Interview tip: Define a VPN as an encrypted tunnel over an untrusted network, then give one site-to-site and one remote-access use case.

IPsec (Internet Protocol Security) is a framework of protocols that secures IP traffic by providing encryption, integrity, and authentication for IP packets. It is the most common technology behind site-to-site VPNs.

IPsec operates at the Network layer — Layer 3 of the OSI model. This is important: because it works at the IP layer, it protects all traffic from upper layers (TCP, UDP, and the applications above them) transparently. The applications don't need to know IPsec exists.

Compare this to TLS/SSL, which sits higher up (operating over TCP, around Layer 4–5) and usually secures one application at a time, such as HTTPS.

An analogy: IPsec armours the whole postal truck (every parcel inside is protected), while TLS wraps individual parcels.

Interview tip: Say "Layer 3, the Network layer" confidently, and add that this is why IPsec can protect all upper-layer protocols transparently.

An IPsec VPN keeps traffic safe by encrypting each IP packet so eavesdroppers can't read it, integrity-protecting it so tampering is detected, and authenticating both endpoints so traffic only flows between trusted peers — all inside a tunnel negotiated with keys that no third party knows.

In plain terms: even though the data rides over the open Internet, anyone intercepting it sees only scrambled, signed bytes that they can neither read nor alter without detection.

Analogy: it's like sending a letter in a tamper-evident, locked box where only sender and receiver hold the key, and any attempt to open it shows.

Interview tip: The three magic words are confidentiality, integrity, and authentication — name all three even in a one-sentence answer.

Both create encrypted tunnels, but they connect different things:

• Site-to-site VPN: Connects two networks together — typically two office locations — gateway-to-gateway (firewall/router to firewall/router). It's always-on and transparent: users at either site reach the other site without running any VPN software. Example: a branch office tunnelled to head office.
• Remote-access VPN: Connects a single user's device (laptop, phone) to the corporate network. The user runs a VPN client (like Cisco AnyConnect, GlobalProtect, or FortiClient) and the tunnel is set up on demand. Example: an employee working from home or a café.

Analogy: site-to-site is a permanent bridge between two towns; remote-access is a single person showing an ID badge to enter the building.

Interview tip: Key phrase — site-to-site is network-to-network (gateway-to-gateway), remote-access is device-to-network (client-based).

IPsec has three core protocol components:

• AH (Authentication Header): Provides integrity and origin authentication for packets, but no encryption. It proves the packet wasn't altered and came from the right peer. Rarely used today because it offers no confidentiality and breaks when traffic passes through NAT (it authenticates parts of the outer IP header that NAT rewrites).
• ESP (Encapsulating Security Payload): The workhorse. Provides encryption (confidentiality) plus integrity and authentication of the payload. Almost all modern VPNs use ESP.
• IKE (Internet Key Exchange): The negotiation/handshake protocol (over UDP 500, switching to UDP 4500 when NAT-T is in play). It authenticates the peers and establishes the shared secret keys and the Security Associations (SAs) that AH/ESP then use.

Analogy: IKE is the secure phone call where two parties agree on a secret codebook; ESP is the actual sealed envelope that codebook locks.

Interview tip: Stress that ESP is what's actually used in production and IKE sets up the keys; AH is mostly legacy.

The CIA triad is the foundation of security: Confidentiality (only authorized parties can read data), Integrity (data isn't altered undetected), and Availability (systems and data are accessible when needed).

IPsec directly provides:

• Confidentiality — via encryption (ESP, e.g. AES-GCM).
• Integrity — via authentication/hashing so tampering is detected.
• It also adds origin authentication and anti-replay protection, which are closely tied to integrity.

IPsec does NOT directly guarantee Availability — that depends on the broader network: redundant tunnels, failover gateways, DDoS protection, bandwidth, and routing. In fact, a misconfigured or attacked VPN gateway can become a single point of failure that harms availability.

Interview tip: Say IPsec covers C and I; Availability is the network's job (HA, redundancy, DDoS mitigation).

That's a big oversimplification. A pre-shared key ("password") is just one way to authenticate peers — and certificates are usually preferred. IPsec does far more than "use a password." During the IKE handshake it negotiates and establishes:

• Authentication of both peers — via PSK or digital certificates (RSA/ECDSA).
• A cipher suite — encryption algorithm (e.g. AES-256-GCM), integrity/hash, and Diffie-Hellman group.
• Fresh symmetric session keys via Diffie-Hellman key exchange — these keys are derived dynamically and never travel across the wire; the PSK itself is not used as the encryption key.
• Security Associations (SAs) and lifetimes, optionally with Perfect Forward Secrecy so compromising one key doesn't expose past or future sessions.

It then protects each packet with encryption, integrity, origin authentication, and anti-replay.

Interview tip: Emphasize that the PSK only authenticates peers; the actual encryption keys come from Diffie-Hellman, and certificates beat PSKs at scale.

This is the classic IKEv2 tunnel-bringup flow:

1. Interesting traffic triggers it: A packet matches a crypto policy/ACL that says "this must be protected," so the gateway starts IKE.
2. IKE_SA_INIT (Phase 1): Peers exchange supported algorithms, do a Diffie-Hellman exchange, and trade nonces. This creates a secure, encrypted control channel — the IKE SA.
3. IKE_AUTH: Inside that protected channel, each peer authenticates the other using certificates or a PSK, proving identity. This same exchange also establishes the first CHILD_SA.
4. CHILD_SA (Phase 2): The data-protection SAs are negotiated — the ESP cipher (e.g. AES-GCM), traffic selectors, and lifetimes. The first pair is set up during IKE_AUTH; additional or rekeyed CHILD_SAs use the CREATE_CHILD_SA exchange, optionally with a fresh DH for Perfect Forward Secrecy.
5. Data flows: User packets are now encrypted/authenticated with ESP (IP protocol 50). If a NAT device is in the path, NAT-T wraps ESP inside UDP 4500.
6. Rekey/teardown: SAs rekey before their lifetime expires; idle tunnels eventually tear down.

Interview tip: Name the two phases — IKE_SA_INIT + IKE_AUTH (Phase 1: secure the channel + authenticate) then the CHILD_SA for the data (Phase 2).

IPsec deliberately uses both, each for what it's good at:

• Asymmetric crypto (RSA/ECDSA signatures, and Diffie-Hellman) is used during the IKE handshake — to authenticate peers (certificate/signature checks) and to securely agree on a shared secret over an open channel (Diffie-Hellman). It solves the hard problem: establishing trust and a key with someone you've never shared a secret with.
• Symmetric crypto (e.g. AES-GCM) is used for the bulk data in the ESP tunnel, using the session keys derived from the handshake.

Why not encrypt all data asymmetrically? Because asymmetric operations are orders of magnitude slower and CPU-heavy — fine for a one-time handshake, catastrophic for gigabits of traffic. Symmetric ciphers are extremely fast (often hardware-accelerated).

Analogy: you use a slow, secure courier once to agree a shared key, then use that fast key for all future conversations.

Interview tip: The phrase to use is "asymmetric to authenticate and establish the key, symmetric to encrypt the data" — speed is the reason.

I'd frame it as "right tool per use case," not "replace everything." IPsec and ZTNA/SASE solve different problems.

• Keep IPsec where it fits: data-center-to-data-center, branch-to-branch, cloud interconnect, and partner links. For stable network-to-network connectivity, IPsec is mature, performant, and standards-based.
• Pivot remote-access to ZTNA: The real risk is the legacy model where a VPN drops a user onto a flat, trusted network with broad lateral movement — a major breach vector. ZTNA grants per-application, identity- and posture-based access with no implicit network trust.
• SASE converges SD-WAN + security (ZTNA/CASB/SWG/FWaaS) at the cloud edge, reducing appliance sprawl and patch burden.

My roadmap: Year 1 inventory flows + retire weak crypto + pilot ZTNA for high-risk apps; Year 2 migrate remote access off VPN, segment east-west; Year 3 consolidate into SASE, keep IPsec only for infrastructure links. Decision drivers: attack surface, lateral-movement risk, appliance CVE exposure, cost, and user experience.

Interview tip: Show maturity by saying it's hybrid and phased — IPsec for network plumbing, ZTNA/SASE for user access — never a religious "rip and replace."

ESP (Encapsulating Security Payload) is the IPsec protocol that protects your data as it crosses an untrusted network. It provides three things: confidentiality (encryption, so eavesdroppers see only ciphertext), integrity (a check that the packet wasn't altered), and authentication (proof it came from the real peer). It can also offer anti-replay protection.

ESP runs directly over IP as IP protocol number 50 (this is the value in the IP header's protocol field, not a TCP/UDP port).

Think of ESP like a sealed, tamper-proof courier envelope: nobody can read what's inside, and you'd immediately know if someone opened it.

👉 Interview tip: Don't confuse "protocol number" with "port." ESP is IP protocol 50 at the IP layer; it has no port of its own (until NAT-T wraps it in UDP).

Those notes are incorrect. AH (Authentication Header) does not encrypt anything at all — it provides no confidentiality. What AH actually gives you is data integrity, data-origin authentication, and anti-replay protection.

AH works by computing a keyed hash (an HMAC) over the packet — including the immutable parts of the IP header — and placing that digest in the header. It doesn't "encrypt the digest"; it simply attaches it so the receiver can recompute and compare. AH is IP protocol number 51.

Analogy: AH is a tamper-evident seal on a postcard. Anyone can read the message (no encryption), but you can prove it wasn't changed and who sent it.

👉 Interview tip: The headline answer is "AH = integrity + authentication, NO encryption." If you say AH encrypts, you'll lose the point.

The difference is how much of the original packet gets protected and wrapped.

• Transport mode: only the payload (the data) is protected; the original IP header is kept and reused. It's lighter, but the real source/destination IPs stay visible. Typically used host-to-host (e.g., endpoint-to-server).
• Tunnel mode: the entire original IP packet (header + data) is encrypted and wrapped inside a brand-new outer IP header using the gateways' addresses. This hides the internal topology.

A site-to-site VPN uses tunnel mode, because two firewalls/routers are protecting traffic on behalf of whole networks behind them, so the original packets must be fully encapsulated.

Analogy: transport mode locks the letter; tunnel mode puts the whole addressed letter inside a new sealed envelope.

👉 Interview tip: Site-to-site = tunnel mode; remote-access and host-to-host often use transport mode.

That note is wrong — there is no port 1500. The correct list is:

• IKE (key exchange, Phase 1/2 negotiation): UDP 500
• NAT-T (IKE + ESP when a NAT is detected): UDP 4500
• ESP (the encrypted data): IP protocol 50 (not a port)
• AH: IP protocol 51 (not a port)

IKEv2 negotiates on UDP 500 and switches to UDP 4500 if a NAT device is in the path. Both IKEv1 and IKEv2 use the same ports. The confusion likely came from misremembering 4500 as "1500."

👉 Interview tip: Remember the pair 500 / 4500 for UDP, and 50 / 51 as IP protocol numbers (ESP / AH). If a firewall blocks UDP 4500, tunnels behind NAT silently fail.

Almost every production VPN uses ESP and you'll rarely see AH. The two concrete reasons:

1. ESP provides encryption (confidentiality); AH does not. A VPN's whole job is to keep data private over the internet. AH only authenticates and integrity-checks — it leaves the payload readable. ESP gives you confidentiality plus integrity and authentication, so it covers everything AH does and more.
2. AH is incompatible with NAT; ESP can traverse it. AH's integrity hash covers the outer IP header (its immutable fields), so any NAT device that rewrites the source IP/port invalidates the check and the packet is dropped. ESP's integrity check does not cover the outer IP header, and with NAT-T it can be wrapped in UDP 4500 to cross NAT cleanly.

In short: ESP = privacy + NAT-friendly; AH = neither private nor NAT-survivable.

👉 Interview tip: Say "encryption" and "NAT-incompatibility of AH" — those are the two answers interviewers want.

A Security Association (SA) is the agreed "contract" between two peers for protecting traffic: which protocol (ESP/AH), which encryption and hash algorithms, the keys, and the lifetime. It's the agreed ruleset both sides use on a given flow.

The SPI (Security Parameter Index) is a number carried in each ESP/AH header that acts as an index so the receiver can look up the correct SA — i.e., "which contract/keys do I decrypt this packet with?" Combined with the destination IP and the protocol (ESP or AH), it uniquely identifies the SA.

SAs are unidirectional: each one protects traffic in one direction only. So a working tunnel needs at least two SAs (inbound + outbound), each with its own SPI and keys. This lets each direction use independent keying and rekey separately.

Analogy: an SA is a one-way toll lane; the SPI is the lane number on your ticket.

👉 Interview tip: "One tunnel = a pair of SAs" is the line to remember.

Transport mode protects only the payload and reuses the original IP header.

• Overhead: lower — no extra outer IP header, so fewer added bytes.
• Privacy: weaker — the real source/destination IPs are visible, revealing who's talking to whom (no topology hiding).
• NAT-friendliness: poor on its own, since the original header is exposed; it relies on NAT-T to survive.

Tunnel mode wraps the whole original packet in a new outer IP header.

• Overhead: higher — an extra IP header (20 bytes for an IPv4 outer header) per packet, which can also trigger fragmentation.
• Privacy: stronger — internal IPs and topology are hidden behind the gateway addresses.
• NAT-friendliness: better — only the outer (gateway) header is exposed, and it pairs cleanly with NAT-T.

Trade-off in one line: transport = lighter but more exposed; tunnel = heavier but private and gateway-friendly.

👉 Interview tip: Tie each mode to its use case — transport for host-to-host, tunnel for site-to-site.

NAT-T (NAT Traversal) is a technique that lets IPsec work when one or both peers sit behind a NAT/PAT device.

Why raw ESP breaks: ESP is IP protocol 50 — it has no TCP/UDP port numbers. A PAT (Port Address Translation) device multiplexes many internal hosts onto one public IP using ports. With no ports to track, PAT can't build a translation entry, so it either drops ESP or can't demultiplex return traffic to the right host. Tunnels behind PAT silently fail.

How NAT-T fixes it: it encapsulates ESP inside UDP, adding a real UDP header with ports the PAT device can translate. The peers move off UDP 500 and switch the whole exchange to UDP 4500, then wrap ESP in UDP 4500 too.

Analogy: ESP is a parcel with no return address slot; NAT-T staples on a UDP "shipping label" with ports.

👉 Interview tip: The crisp answer is "ESP has no ports → PAT can't track it → NAT-T puts ESP inside UDP 4500."

NAT detection happens during IKE Phase 1 on UDP 500, using NAT-D (NAT-Discovery) payloads. Each peer computes a hash of the IP addresses and ports it thinks it's using (its own and the peer's) and sends those hashes to the other side.

The receiver recomputes the same hash from what it actually sees in the packet. If the hashes match, no address/port was rewritten — no NAT. If they don't match, a NAT device altered the header somewhere on the path, so a NAT is present (and the peer can even tell whether it's local or remote).

Trigger to switch ports: once a NAT is detected — and both peers support NAT-T (in IKEv1 this is advertised via a NAT-T vendor-ID in the first messages; in IKEv2 NAT-T is built into the protocol) — they float from UDP 500 to UDP 4500 for the rest of IKE, and all ESP is then UDP-encapsulated in 4500.

👉 Interview tip: Two ingredients — NAT-T capability confirmed first (vendor-ID in IKEv1, built-in for IKEv2), then a NAT-D hash mismatch triggers the float to UDP 4500.

Every IPsec SA has a lifetime, and when it expires the peers negotiate a fresh SA (with new keys) — this is rekeying. Lifetimes are enforced two ways, and whichever hits first wins:

• Time-based: expire after N seconds (e.g., Phase 1 ~24h, Phase 2 ~1h).
• Volume-based (lifebytes/lifetime KB): expire after N bytes/packets — important for high-throughput links so keys don't protect too much data.

Rekey collisions at scale: if both peers initiate a rekey near-simultaneously, you get duplicate/overlapping SAs. Symptoms: brief packet loss, orphaned SAs eating memory, anti-replay drops, and on hub gateways with hundreds of tunnels, synchronized rekey "storms" that spike CPU.

Tuning: set matching lifetimes on both peers; let one side be the consistent initiator; ensure rekey starts before expiry (soft vs hard lifetime margin); jitter/stagger lifetimes across many tunnels to avoid simultaneous expiry; and prefer IKEv2, which handles rekey collisions far more gracefully than IKEv1.

👉 Interview tip: Mention soft-vs-hard lifetimes and staggering to avoid hub CPU storms — that signals real production experience.

IKE (Internet Key Exchange) is the protocol that sets up an IPsec VPN before any real data flows. Think of IKE as the negotiation and handshake desk, while IPsec (ESP or AH) is the armored truck that actually carries your traffic.

IKE's main jobs are:

• Authenticate the two peers (pre-shared key, digital certificates, or EAP) so each side proves it is the genuine gateway.
• Negotiate which encryption, hashing, and Diffie-Hellman parameters both sides will use.
• Generate and refresh keys securely using Diffie-Hellman, so a fresh secret protects the tunnel.
• Establish Security Associations (SAs) — the agreed rule-sets that ESP then uses to protect packets.

IKE runs over UDP 500, and switches to UDP 4500 when NAT-Traversal is in play. Without IKE you would have to manually configure keys on both ends, which does not scale and is far less secure.

Interview tip: say it plainly — "IKE negotiates keys and SAs; ESP/AH carry the protected data."

IPsec negotiation happens in two phases, and each builds a different Security Association (SA).

• Phase 1 establishes the IKE SA (in IKEv1, also called the ISAKMP SA) — a secure, authenticated, encrypted control channel between the two peers. Here the peers authenticate each other and run Diffie-Hellman to create a shared secret. Think of this as two embassies first verifying each other's identity and setting up a private diplomatic line.
• Phase 2 uses that protected channel to negotiate the IPsec SAs (the ESP or AH SAs) that actually protect your user data. In IKEv1 this exchange is called Quick Mode; in IKEv2 it creates a CHILD_SA.

So Phase 1 builds the trusted tunnel used for negotiation, and Phase 2 builds the SAs that carry real traffic. IPsec SAs are unidirectional, so a working tunnel has at least one inbound and one outbound SA per peer.

Interview tip: Phase 1 secures the negotiation; Phase 2 secures the data.

That answer mixes up two different concepts. IKE, ESP, and AH are protocols, not phases.

• IKE is the negotiation and key-exchange protocol.
• ESP (Encapsulating Security Payload) provides encryption plus integrity/authentication of the payload.
• AH (Authentication Header) provides integrity and authentication only — it does not encrypt — and is rarely used today because it authenticates the outer IP header and therefore breaks when traffic passes through NAT.

The correct framing is that IPsec negotiation has two phases:

1. Phase 1 — builds the secure, authenticated IKE SA (the control channel).
2. Phase 2 — uses that channel to build the IPsec SAs (ESP or AH) that carry real traffic.

So the candidate confused the data-plane protocols with the negotiation phases. A cleaner answer: "Two phases — Phase 1 sets up the IKE SA, Phase 2 sets up the ESP SAs."

Interview tip: never list ESP/AH as "phases" — they are the cargo, IKE is the handshake.

In IKE Phase 1, the two peers build a secure, authenticated control channel — the IKE SA. Three things happen:

• Negotiate policy: agree on the encryption algorithm, the hash/integrity algorithm, the Diffie-Hellman group, the authentication method, and the SA lifetime.
• Run Diffie-Hellman: each side exchanges DH public values and independently computes a shared secret over an untrusted network, without ever sending the secret itself. From it, both derive the keys (SKEYID and friends in IKEv1; the SK_* keys in IKEv2) that encrypt the rest of the conversation.
• Authenticate the peers: using pre-shared keys (PSK), RSA or ECDSA digital certificates, or EAP (IKEv2 only) — proving each side is who it claims to be.

Key point: Diffie-Hellman establishes the shared secret; the PSK or certificate establishes identity. DH alone gives confidentiality but is vulnerable to a man-in-the-middle without an authentication step bound to it.

Interview tip: DH = key agreement; PSK/cert/EAP = who you are. Don't conflate them.

They solve two different problems in the handshake.

• Diffie-Hellman is a key-agreement algorithm. Both peers exchange public values and independently compute the same shared secret without ever transmitting it. This secret seeds the session keys that protect the tunnel. DH does not prove identity by itself.
• RSA (or ECDSA) is used for peer authentication — proving "I really am this gateway." Each side presents a certificate and signs handshake data with its private key; the peer verifies the signature with the public key. RSA can also encrypt, but in a modern IPsec handshake its role is authentication/signing.

Analogy: DH is two people mixing the same secret paint color from public ingredients; RSA is each one signing the recipe so you know exactly who you mixed it with.

So: DH gives the shared session secret, and RSA/ECDSA gives identity/authentication. Together they produce an authenticated, confidential channel that resists man-in-the-middle.

Interview tip: "DH agrees the key; RSA proves the peer."

Both are IKEv1 Phase-1 modes, but they trade security for speed.

• Main Mode uses 6 messages (3 round-trips). The Diffie-Hellman exchange completes and an encrypted channel is established before the identities and the PSK-based authentication payload are sent, so identities are protected. This is the secure default.
• Aggressive Mode uses only 3 messages — faster, but it sends the initiator's identity and a PSK-derived hash without identity protection in the early packets, before an encrypted channel is fully established.

The big risk: an attacker who sniffs an Aggressive Mode exchange (or simply queries an exposed responder) can capture that hash and run an offline brute-force or dictionary attack against the pre-shared key — no need to stay connected or interact further. With a weak PSK, the tunnel is effectively crackable.

When is Aggressive Mode used? Mostly legacy scenarios — remote access from dynamic or unknown peer IPs where Main Mode with PSK cannot bind the PSK to a known peer IP. Modern guidance: prefer IKEv2, or Main Mode with certificate authentication. Avoid Aggressive Mode with PSK.

Interview tip: Aggressive Mode = 3 messages, no identity protection, offline PSK crack — a red flag in audits.

IKEv2 is a cleaner, more robust redesign of IKEv1.

• Message counts: IKEv1 needs 6 (Main Mode) or 3 (Aggressive Mode) messages for Phase 1, plus 3 for Phase 2 (Quick Mode). IKEv2 sets up the IKE SA and the first CHILD_SA in just 4 messages — the IKE_SA_INIT exchange followed by the IKE_AUTH exchange — so it is faster with fewer round-trips.
• NAT-Traversal: IKEv1 added NAT-T as a bolt-on extension; IKEv2 has it built in, auto-detecting NAT and switching to UDP 4500.
• EAP: IKEv2 natively supports EAP (for example EAP-MSCHAPv2 or EAP-TLS) for user authentication against RADIUS or AD — ideal for remote access.
• MOBIKE: IKEv2's mobility extension keeps the tunnel alive when a client's IP changes (Wi-Fi to mobile) without renegotiating the whole SA.
• Reliability and anti-replay: IKEv2 uses a strict request/response model with message IDs, retransmission, and built-in liveness checks (dead-peer detection); IKEv1 was less reliable and DPD was an add-on.

For 2026, IKEv2 is the default because it is faster, NAT- and mobile-friendly, supports modern authentication, and (via RFC 9370) can carry post-quantum hybrid key exchange — all with a smaller, cleaner attack surface.

Interview tip: IKEv2 = 4 messages (IKE_SA_INIT + IKE_AUTH), native NAT-T + EAP + MOBIKE, reliable retransmits.

Perfect Forward Secrecy (PFS) ensures that each IPsec session key is independent, so compromising one key — or even the long-term authentication key — does not expose past or future sessions.

How it is implemented: by default, Phase 2 (Quick Mode in IKEv1, a CHILD_SA in IKEv2) derives its keys from the existing Phase 1 shared secret. With PFS enabled, each Phase 2 negotiation runs a fresh, independent Diffie-Hellman exchange using a DH group you specify, generating brand-new key material that is not mathematically tied to the Phase 1 secret. The same applies at every rekey, and the ephemeral DH private values are discarded afterward.

The real attack it defends against: the key-compromise / harvest-now-decrypt-later scenario. If an attacker records encrypted traffic today and later steals the long-term key or a session key, without PFS they may be able to derive other session keys from the same Phase 1 secret and decrypt the captured traffic. With PFS, each session's ephemeral DH secret is gone, so old captures stay protected and a single key compromise does not unlock the rest.

Cost: extra CPU per rekey for the additional DH operation — usually well worth it.

Interview tip: PFS = fresh DH per session/rekey; one stolen key can't unlock the rest.

Diffie-Hellman groups are predefined sets of cryptographic parameters (numbered in RFCs) that define the math and key size used for the DH key exchange. Both peers must agree on the same group.

Two families:

• MODP (modular exponentiation over a finite prime field) — classic DH. Strength scales with modulus length: Group 1 (768-bit), Group 2 (1024-bit), and Group 5 (1536-bit) are deprecated and broken; Group 14 (2048-bit) is the practical minimum, with Group 15/16 (3072/4096-bit) stronger.
• ECDH (Elliptic Curve Diffie-Hellman) — the same key agreement over elliptic curves, giving equivalent security with much smaller keys and less CPU. Common choices: Group 19 (P-256), Group 20 (P-384), Group 21 (P-521), plus Curve25519 (Group 31).

A note on Groups 22, 23, 24 (from RFC 5114): these are MODP groups with small subgroups — Group 22 is 1024-bit, while Groups 23 and 24 are 2048-bit. They are discouraged regardless of modulus size because their primes come from a questionable source and may be subtly weak; current guidance (RFC 8247) is MUST NOT for Group 22 and SHOULD NOT for 23/24.

2026 guidance: avoid Groups 1, 2, 5, and 22–24. Use MODP Group 14 or higher, or — preferably — ECDH Group 19/20/21/31, which are faster and stronger per bit.

Interview tip: never accept DH Group 1/2/5 (or the RFC 5114 groups 22–24); ECDH 19/20 is the modern sweet spot.

Harvest-now, decrypt-later (HNDL) is the threat where an adversary records your encrypted IPsec traffic today and stores it, betting that a future cryptographically relevant quantum computer will break classical Diffie-Hellman and RSA and let them decrypt the captures later. Long-lived secrets (health, financial, government data) are most at risk.

Hybrid key exchange defends against this by combining a classical exchange (such as ECDH) and a post-quantum KEM such as ML-KEM (standardized in FIPS 203, the algorithm formerly known as Kyber). The two shared secrets are fed together into the key derivation, so the session stays secure if either algorithm holds — you gain quantum resistance without abandoning well-trusted classical crypto.

Enabling mechanisms:

• RFC 9370 — "Multiple Key Exchanges in IKEv2": lets IKEv2 perform up to seven additional key exchanges beyond the initial one, which is the framework that carries the post-quantum KEM alongside ECDH while keeping backward compatibility.
• RFC 8784 — "Mixing Preshared Keys in IKEv2 for Post-quantum Security": an interim approach that folds an out-of-band post-quantum PSK into the key derivation.
• ML-KEM (FIPS 203, 2024) — the standardized post-quantum KEM used as the quantum-resistant component.

Interview tip: Hybrid = ECDH + ML-KEM carried by RFC 9370; the session survives as long as either piece resists quantum attack.

A VTI (Virtual Tunnel Interface) is a logical interface that represents one end of an IPsec tunnel, just like a physical port represents a cable. You give it an IP address, point it at a peer, and the device treats it like any other interface.

The key idea: traffic gets selected into the tunnel by routing, not by hand-written match lists. If a packet's route points out the VTI (a static route, or a route learned from a dynamic routing protocol), it is encrypted and sent. Think of the VTI as a toll-road on-ramp; the routing table is the sign telling each car which traffic uses that ramp.

This keeps config clean: add a route and more traffic is protected, with no need to edit crypto rules. It is the foundation of route-based VPNs on Cisco, FortiGate, Palo Alto, and others.

👉 Interview tip: Say "VTI = routable tunnel interface; the routing table decides what gets encrypted."

DMVPN (Dynamic Multipoint VPN) is a Cisco design that lets many branch offices (spokes) connect over the internet to a central site (hub) without manually configuring a separate tunnel to every other branch. The big win: spokes can build direct, on-demand tunnels to each other when they need to talk, then tear them down when idle.

Analogy: instead of every branch keeping a permanent private line to every other branch (which explodes as you grow), DMVPN works like a phonebook plus a switchboard. A branch asks the hub "what's the address of Branch B?", gets the answer, and dials a direct call only when needed.

This makes large WANs scalable, cheaper (it rides ordinary internet links), and far less work to manage.

👉 Interview tip: One line: "DMVPN gives scalable, on-demand spoke-to-spoke IPsec tunnels without configuring a full mesh by hand."

In a policy-based VPN, you define exactly which source/destination subnet pairs (the "proxy IDs" or traffic selectors) get encrypted. Each new subnet pair often means another IPsec SA and another line in the policy, like writing a separate rule for every road between two cities.

In a route-based VPN, you build a tunnel interface (a VTI) and let the routing table decide what enters it. Encryption is tied to "is the route pointing out the tunnel?", not to specific subnet pairs.

Route-based scales better because:

• Adding networks means adding routes, not editing crypto policy.
• It supports dynamic routing (OSPF, BGP, EIGRP) over the tunnel for automatic failover.
• One SA pair can cover all traffic (often using a 0.0.0.0/0-to-0.0.0.0/0 selector), avoiding the SA explosion of many proxy-ID pairs.

👉 Interview tip: Policy-based = match traffic selectors; route-based = route into a VTI. Modern designs favor route-based.

Classic IPsec (in tunnel mode without a VTI) was designed to protect unicast IP traffic between specific subnets. It does not natively carry multicast or broadcast packets, and most dynamic routing protocols rely on those (OSPF hellos and EIGRP updates use multicast).

GRE (Generic Routing Encapsulation) is a simple wrapper that can carry almost anything, including multicast, broadcast, and even non-IP protocols. So the trick is: routing-protocol packets ride inside GRE, and then the whole GRE packet is encrypted by IPsec. This is the classic GRE-over-IPsec design.

Analogy: IPsec is an armored truck that only accepts standard envelopes; GRE is a box that fits oddly-shaped parcels (multicast). Put the box in the truck and you can ship anything securely.

The result: routers form OSPF/EIGRP neighborships across the tunnel and learn routes dynamically, enabling failover. (Note: a modern route-based VTI achieves the same multicast support without a separate GRE header, which is why VTIs have largely replaced manual GRE-over-IPsec.)

👉 Interview tip: "GRE adds multicast support; IPsec adds encryption, so dynamic routing works."

DMVPN stands on four technologies working together:

• mGRE (multipoint GRE) - one tunnel interface on a router that can reach many peers, instead of a separate GRE tunnel per peer.
• NHRP (Next Hop Resolution Protocol) - the "address phonebook" that maps a spoke's private tunnel IP to its real public (NBMA) IP address.
• IPsec - encrypts the GRE traffic for confidentiality and integrity (technically optional in DMVPN, but always used in production).
• A dynamic routing protocol (EIGRP, OSPF, or BGP) - lets sites learn each other's networks automatically.

NHRP's role is the glue. Spokes register their public IP with the hub (which acts as the NHRP server / Next Hop Server). When Spoke A wants to reach Spoke B directly, it queries the hub: "what's B's real public IP?" NHRP answers, and A builds a direct mGRE + IPsec tunnel, with no full mesh needed.

👉 Interview tip: Remember the combo as mGRE + NHRP + IPsec + routing; NHRP is the resolver that enables dynamic spoke-to-spoke tunnels.

Manually configured hub-and-spoke means you hand-build and maintain a separate tunnel for every site, and all spoke-to-spoke traffic must hairpin through the hub. DMVPN fixes the pain points:

• Zero-touch hub for new spokes - add a branch and you only configure that branch; the hub does not need a new tunnel definition. With a manually built full mesh, connecting N sites needs on the order of N-squared tunnels (precisely N×(N-1)/2).
• Direct spoke-to-spoke paths - NHRP lets branches build on-demand tunnels to each other, cutting latency and offloading the hub (great for VoIP/video between branches).
• Dynamic routing + failover - OSPF/EIGRP/BGP run over the overlay, so paths heal automatically.
• Supports dynamic/changing spoke IPs - spokes on DHCP or dynamic public IPs still register with the hub via NHRP.

Analogy: manual tunnels are like mailing a fixed set of pre-addressed letters; DMVPN is a live directory that dials any branch on demand.

👉 Interview tip: Stress scalability (no N-squared config) and on-demand spoke-to-spoke as the headline wins.

DMVPN has three design phases, differing mainly in spoke-to-spoke behavior and how the routing table looks at the spokes:

• Phase 1 - Hub-and-spoke only. The hub runs mGRE; spokes typically run point-to-point GRE to the hub. All spoke-to-spoke traffic hairpins through the hub. The hub can advertise a summary or default route to spokes. No direct spoke-to-spoke tunnels.
• Phase 2 - Adds dynamic spoke-to-spoke tunnels. Spokes use mGRE and NHRP to resolve each other and build direct tunnels on demand. Crucially, the hub must preserve the original next-hop in routing updates (so on EIGRP, disable next-hop-self; on OSPF, use a broadcast/point-to-multipoint network type) and you must not summarize, so spokes learn the real next hop needed to trigger a direct tunnel.
• Phase 3 - Also has direct spoke-to-spoke tunnels but scales better using NHRP redirects and shortcuts. The hub can summarize routes; when a spoke sends traffic via the hub, the hub issues an NHRP redirect and the spoke installs an NHRP shortcut route to the other spoke. This is the modern default.

👉 Interview tip: Phase 1 = no direct tunnels; Phase 2 = direct but no summarization (next-hop preserved); Phase 3 = direct + summarization via NHRP redirect/shortcut.

GETVPN (Group Encrypted Transport VPN) shines on a private, fully-routed WAN (typically MPLS) where the provider already gives you any-to-any reachability and you just need to encrypt that traffic, often for compliance.

Its defining trait is tunnel-less, group encryption. Instead of point-to-point tunnels with per-pair SAs, all members share one common set of group SAs distributed by a Key Server (KS) using GDOI (Group Domain of Interpretation). Encryption uses IPsec tunnel mode with header preservation: the original source/destination IPs are copied into the outer header, so the MPLS core still routes natively and any-to-any works without building any mesh.

Analogy: DMVPN dials a private call to each peer; GETVPN is like everyone sharing one group radio key, so anyone can talk to anyone instantly, encrypted.

Choose GETVPN when you need native any-to-any (multicast-heavy or voice traffic) over a trusted private WAN. Choose DMVPN when the transport is the public internet (untrusted, with NAT and dynamic IPs), where header preservation cannot work because the original IPs are not routable across the internet.

👉 Interview tip: GETVPN = MPLS + group SA + header preservation; DMVPN = internet overlay with real tunnels.

FlexVPN is Cisco's unified VPN framework built entirely on IKEv2. Its goal is to replace a pile of older, fragmented VPN technologies, including legacy DMVPN, EzVPN (remote access), crypto-map site-to-site, and GRE/DVTI, each of which had its own quirky config, under one consistent CLI and one protocol.

The problem it solves: historically, site-to-site, hub-and-spoke, and remote-access VPNs each needed different commands and feature sets, and many relied on the older IKEv1. FlexVPN lets one framework cover all those topologies (point-to-point, hub-and-spoke with spoke-to-spoke, and remote access) using the same building blocks: IKEv2 proposals, profiles, and virtual tunnel interfaces (VTI / dVTI).

Benefits include native IKEv2 (stronger, fewer round trips, built-in NAT traversal and resilience such as anti-DoS cookies), per-user or per-peer attribute push, and flexible routing. Analogy: instead of separate tools for every job, FlexVPN is one well-organized toolbox.

👉 Interview tip: "FlexVPN = one IKEv2-based framework unifying site-to-site, hub-spoke, and remote access; it replaces legacy DMVPN/EzVPN/crypto-map sprawl."

For a brand-new 200-site WAN in 2026, the strong default is an SD-WAN overlay with automatic IPsec (FortiGate ADVPN, Cisco Catalyst SD-WAN, etc.) rather than hand-built DMVPN/GETVPN.

Why SD-WAN wins:

• Centralized orchestration - templates push config to all 200 sites; tunnels and routing auto-provision (zero-touch). Hand-building DMVPN or IKEv2 at 200 sites is slow and error-prone.
• Dynamic on-demand tunnels - ADVPN gives the same direct spoke-to-spoke benefit as DMVPN Phase 3, but managed centrally.
• Application-aware steering + visibility - per-app SLA, link failover across MPLS/internet/LTE, and dashboards, things raw IPsec cannot do.
• Faster operations - add, change, and troubleshoot from one controller.

Tradeoffs: licensing/subscription cost, controller dependency (design for HA so the data plane survives controller loss), and some vendor lock-in. DMVPN/GETVPN still make sense if you must stay licence-free, are a pure Cisco IOS shop with strong in-house expertise, or have a strict MPLS-only any-to-any compliance case (GETVPN).

👉 Interview tip: Recommend SD-WAN for greenfield scale, but name the cost/lock-in tradeoff, that balanced answer impresses.

An SSL/TLS VPN typically runs over TCP 443 — the same port as normal HTTPS web traffic. (Many modern clients also use UDP 443 via DTLS or QUIC for performance, but 443 is the key number.)

This is a huge advantage for traversal because:

• Port 443 is almost always open outbound — every network must allow HTTPS, or users can't browse the web.
• It blends in with ordinary web traffic, so restrictive firewalls, captive portals, and corporate proxies rarely block it.
• It can often pass through web proxies that would block IPsec's UDP 500/4500.

Compare this to IPsec, which needs special ports/protocols (UDP 500 for IKE, UDP 4500 for NAT-T, plus ESP as IP protocol 50) that hotels, cafés, and locked-down networks frequently block.

Analogy: an SSL VPN wears the same uniform as everyday web traffic, so the guard waves it through.

Interview tip: Say TCP 443 and explain it "looks like HTTPS," which is exactly why it's so firewall-friendly.

Both use SSL/TLS, but they differ in what's installed and how much access they grant:

• Clientless SSL VPN: Runs entirely in a web browser — no software to install. The user logs into a web portal and reaches a limited set of web apps, file shares, or RDP sessions proxied through the gateway. Convenient for contractors or kiosks, but limited to specific applications.
• Full-tunnel client (Cisco AnyConnect, Palo Alto GlobalProtect, FortiClient): A dedicated VPN app creates a virtual network adapter and tunnels the device's IP traffic into the corporate network, giving near full network access — like being plugged into the office LAN.

Trade-off: clientless is easy and low-footprint but restricted; a full client is powerful but installs software and grants broad access (higher risk if the device is compromised).

Interview tip: Phrase it as "browser-based, app-specific" (clientless) versus "installed agent, full network-layer access" (full-tunnel).

It's about which traffic goes through the VPN tunnel:

• Full tunnel: All the device's traffic — corporate and Internet (e.g. YouTube, Gmail) — is forced through the VPN to the corporate gateway, then out. More secure and more visible (everything passes corporate inspection/DLP), but adds latency and consumes corporate bandwidth.
• Split tunnel: Only corporate-bound traffic enters the VPN; general Internet traffic goes directly from the device. Faster and lighter on bandwidth, but that Internet traffic bypasses corporate security controls.

The tradeoff:

• Security: Full tunnel wins — everything is inspected; no direct, unmonitored Internet path on a connected device.
• Performance/cost: Split tunnel wins — less latency, less backhaul, better for cloud apps like Microsoft 365.

A common modern compromise: split-tunnel trusted SaaS, full-tunnel everything else, paired with endpoint protection.

Interview tip: State it as full tunnel = security & visibility, split tunnel = performance & bandwidth savings, then mention a hybrid policy.

Authentication happens in layers — device/tunnel auth, then user auth:

• PSK vs certificates: A PSK (shared secret) is simple but weak for remote access — one leaked key compromises everyone and it doesn't identify individual users. Certificates (per-device/per-user) are far stronger, support revocation, and scale — the modern default.
• XAUTH (IKEv1): An extension bolted onto IKEv1 to add per-user credential prompts (username/password) after the device-level PSK/cert phase. It's a legacy stopgap.
• EAP (incl. EAP-TLS) in IKEv2: IKEv2 natively supports EAP, cleanly carrying user authentication inside the IKE_AUTH exchange. EAP-TLS uses client certificates for strong, password-less mutual auth.
• RADIUS: The gateway acts as an authenticator, forwarding user credentials (often via EAP) to a central RADIUS/AD server for validation and policy.
• SAML/MFA: Modern SSL/TLS VPNs and ZTNA redirect login to an IdP via SAML/OIDC, enabling SSO and MFA — today's best practice.

Interview tip: Headline it: certificates > PSK; XAUTH is the IKEv1 hack, EAP is the clean IKEv2 way; RADIUS centralizes; SAML/MFA is the modern front door.

WireGuard is a modern, lightweight VPN protocol (built into the Linux kernel) designed to be simple, fast, and secure. Its defining trait is radical minimalism — roughly 4,000 lines of code versus tens of thousands for typical IPsec stacks, making it far easier to audit.

Its crypto is fixed and opinionated (no negotiation, so no downgrade attacks):

• Curve25519 — for Diffie-Hellman key exchange.
• ChaCha20-Poly1305 — fast authenticated encryption (great on CPUs without AES hardware).
• BLAKE2s for hashing, with the handshake built on the Noise protocol framework.

Cryptokey routing: Each peer's public key is tied to a set of allowed IPs. Routing and authentication become one decision — an inbound packet is only accepted if it's encrypted by the key authorized for that source IP, and outbound packets are sent to the peer whose allowed-IPs match the destination. No complex policies or SAs to manage.

It's faster/simpler because: a tiny codebase, no cipher negotiation, it runs in-kernel, and it is UDP-only with a stateless-style handshake.

Interview tip: Three soundbites — fixed modern crypto (no negotiation), cryptokey routing (public key = allowed IPs), and tiny auditable codebase.

WireGuard's minimalism is also its enterprise weakness — it deliberately leaves out things big networks rely on:

• No native identity / AAA: It authenticates keys, not users. There's no built-in integration with RADIUS, LDAP/AD, SAML, MFA, or per-user policy — you must bolt on external tooling (e.g. Tailscale/Netmaker) to get enterprise identity.
• Static key-to-IP model: Cryptokey routing is simple but rigid; the base protocol doesn't natively run dynamic routing protocols (BGP/OSPF) over the tunnel, which large WANs depend on for failover.
• Limited multicast/broadcast support — it's point-to-point by design, awkward for protocols needing multicast.
• Interoperability: IPsec is an IETF standard supported by virtually every firewall/router vendor (Cisco, Palo Alto, Fortinet, Juniper). WireGuard has fewer turnkey enterprise gateway integrations and no standardized policy framework.
• No built-in dynamic-IP roaming policy controls and a simpler NAT-keepalive model compared to mature IPsec/IKEv2 deployments (WireGuard relies on a persistent-keepalive setting rather than IKE's NAT-T machinery).

Interview tip: Summarize: WireGuard trades enterprise features (identity/AAA, dynamic routing, multicast, broad vendor interop) for speed and simplicity — great for cloud/host-to-host, less so as a drop-in enterprise concentrator.

AES-GCM is an AEAD (Authenticated Encryption with Associated Data) cipher — it does encryption and integrity in a single pass. Compared to AES-CBC + HMAC (encrypt, then separately authenticate), you gain:

• Performance: one operation, hardware-accelerated (AES-NI + PCLMULQDQ), and parallelizable — faster, higher throughput.
• Security simplicity: no fragile "encrypt-then-MAC" ordering to get wrong; CBC has a history of padding-oracle attacks. GCM avoids that padding-oracle class entirely.

Legacy algorithms to remove and why:

• DES / 3DES: DES's 56-bit key is trivially brute-forced; 3DES has a small 64-bit block and is vulnerable to the Sweet32 birthday attack — both are deprecated.
• MD5: badly broken (practical collisions); unfit for integrity/auth.
• SHA-1: collision-broken (SHAttered); phase out for SHA-256 or better.
• DH groups 1, 2, 5 (768/1024/1536-bit MODP): too weak, and 1024-bit MODP is exposed by Logjam-style nation-state precomputation; move to Group 14+ (2048-bit MODP) or ECDH (e.g. Group 19/20/21).

Interview tip: Say AES-GCM = AEAD = encrypt + authenticate in one fast pass, and tie each legacy algorithm to its named attack (Sweet32, SHAttered, Logjam) — that signals real depth.

A traditional VPN gives an authenticated user a network-level connection — once connected, the device sits inside the network and can often reach many systems ("connect first, then you're trusted"). ZTNA (Zero Trust Network Access) flips this: "never trust, always verify," granting access to individual applications, not the network.

Why flat VPN access is now a risk:

• A compromised laptop or stolen credential lands an attacker on the internal network, free to perform lateral movement and reconnaissance — a top cause of major breaches and ransomware spread.
• It assumes implicit trust based on network location, which Zero Trust rejects.

How ZTNA differs:

• Per-application access via a broker — users never see the network, only the specific apps they're authorized for (apps stay hidden/"dark" behind the broker).
• Continuous identity (SSO/MFA) and device-posture checks (patch level, EDR, compliance) before and during access.
• Least privilege + microsegmentation, drastically shrinking the attack surface and blast radius.

Interview tip: One-liner: a VPN connects you to a network; ZTNA connects you to an app, after verifying identity AND device posture, with no lateral movement.

SASE (Secure Access Service Edge) converges networking and security into a single, cloud-delivered service at the network edge, so policy follows the user wherever they are. It's commonly split into two halves:

• SD-WAN (the networking half) — intelligent, optimized routing across links to branches, cloud, and Internet.
• SSE — Security Service Edge (the security half), made of: ZTNA (per-app zero-trust access), CASB (cloud/SaaS visibility and control), SWG (secure web gateway / safe web browsing), and FWaaS (firewall-as-a-service).

Business case for migrating remote-access VPN into SASE:

• Eliminate VPN appliance patching & CVE exposure and capacity bottlenecks.
• Better UX — traffic hits a nearby cloud PoP, not a single backhauled concentrator (great for SaaS like Microsoft 365).
• Consistent zero-trust policy for all users/locations and consolidated vendor/cost.
• Scales elastically for hybrid work without buying more hardware.

Interview tip: Memorize the decomposition: SASE = SD-WAN + SSE, and SSE = ZTNA + CASB + SWG + FWaaS. The business pitch is consolidation, zero trust, and killing appliance risk.

My recommendation: treat internet-facing SSL-VPN as legacy and actively migrate off it toward ZTNA/SASE — but if you must run it, harden it aggressively. SSL-VPN appliances have become a prime attack target: they're internet-exposed, run complex code, grant network-level access, and have suffered repeated critical, often pre-auth remote-code-execution (RCE) zero-days (Ivanti Connect Secure, FortiOS SSL-VPN, Citrix-style). One unpatched gateway can mean full network compromise.

Hardening (if it stays):

• Patch urgently on vendor advisories and treat CISA KEV entries as emergency-change triggers.
• Enforce MFA on every login (no exceptions) and certificate-based device auth.
• Minimize exposure — geo/IP allow-listing, disable unused web portals/features, restrict to least-privilege access.
• Monitor for IOCs, run vendor integrity checkers, and alert on config/anomalies.

Migration plan: inventory who needs what → pilot ZTNA for high-risk apps (apps go dark, no network exposure) → migrate remote access app-by-app → fold into a SASE platform → decommission the appliance.

Interview tip: Don't give a flat "yes" or "no" — say "reduce reliance, harden what remains, and migrate to ZTNA"; note that pre-auth RCE is the recurring pattern and that patch speed plus MFA are the immediate wins.

Very first GUI check: open the IPsec / VPN monitor page and look at the tunnel/SA status — is Phase 1 (IKE) up, and is Phase 2 (IPsec SA) up? This instantly tells you whether nothing came up, or only Phase 1 came up. Confirm whether traffic counters (encrypt/decrypt, in/out bytes) are incrementing.

Basic escalation checklist before raising a ticket:

1. Reachability: can you reach the remote peer's public IP (ping/traceroute)? Is the WAN link/ISP up on both ends?
2. Phase status: P1 down, or P1 up but P2 down?
3. Recent change: any config edit, password/PSK change, IP change, or firmware update on either side?
4. Logs: read the IKE/VPN event log for the actual error (auth failure, no proposal chosen, selector mismatch).
5. Interesting traffic: is real traffic actually trying to cross to bring the tunnel up?

👉 Interview tip: Always state "check Phase 1 vs Phase 2 status first" — it scopes the entire problem before you touch anything.

Here's at least one verification command per vendor:

• Cisco (IOS/ASA): show crypto isakmp sa (IKEv1) or show crypto ikev2 sa (IKEv2) to check Phase 1, and show crypto ipsec sa to check Phase 2 and watch the encrypt/decrypt packet counters.
• FortiGate: diagnose vpn tunnel list (or get vpn ipsec tunnel summary) to see tunnel and SA status; diagnose vpn ike gateway list for the IKE side.
• Palo Alto (PAN-OS): show vpn ike-sa for Phase 1 and show vpn ipsec-sa for Phase 2; show vpn flow for tunnel flow/counters.

On all three, the key signal is: Phase 1 established, Phase 2 SA present, and encrypt/decrypt counters incrementing (both rising means bidirectional traffic is flowing).

👉 Interview tip: Don't just name the command — say what you're looking for: P1 up, P2 up, and counters incrementing in both directions.

If Phase 1 is up but Phase 2 won't form, the IKE authentication and basic negotiation succeeded, so the problem is in the IPsec SA / Phase 2 parameters. Top checks:

1. Traffic selectors / proxy-IDs: do the local and remote subnets defined on each side mirror exactly? (Side A's local must equal Side B's remote, and vice versa.)
2. Phase 2 transform set: matching encryption + hash, and PFS / DH group agreement.
3. Protocol/mode: ESP vs AH, tunnel mode on both.
4. Lifetime mismatch (less fatal but worth checking).

Why proxy-ID mismatch is the usual culprit: Phase 2 negotiates which traffic the SA will protect. If one side proposes 10.1.0.0/16 and the other expects 10.1.1.0/24, the proposal is rejected — you'll see logs like "no proposal chosen" or "received proxy-ID does not match." Cisco policy-based VPNs (crypto-ACL) and route-based peers commonly disagree here.

👉 Interview tip: Phase 1 up + Phase 2 down → think "selectors / transform / PFS" first, selectors most of all.

"Interesting traffic" = the traffic each side has decided must be encrypted and sent through the tunnel. Both vendors express the same concept differently:

• Cisco: defines it with a crypto-ACL (a permit ACL bound to the crypto map). The ACL's source/destination become the proxy-IDs proposed in Phase 2 quick mode.
• FortiGate: defines it with the phase-2 quick-mode selectors — explicit local/remote subnet fields (or 0.0.0.0/0 if left wide open).

These must mirror: Cisco's ACL source = Forti's local selector, Cisco's ACL destination = Forti's remote selector. A common trap: FortiGate route-based VPNs default selectors to 0.0.0.0/0, while Cisco proposes specific subnets — they don't match.

In the logs: Cisco shows "IPSEC(validate_proposal_request): proposal not chosen" or a proxy-ID mismatch; FortiGate's diagnose debug app ike shows "no matching phase2" / "peer SA proposal not match local policy."

👉 Interview tip: Fix by making selectors identical, or set both to 0.0.0.0/0 on a route-based pair.

If Phase 1 never comes up, the two peers can't agree on IKE/ISAKMP. These must match on both sides:

• IKE version: both IKEv1 or both IKEv2 (mixing them fails instantly).
• Encryption + hash/PRF: e.g., AES-256 + SHA-256 must be a common proposal.
• DH (Diffie-Hellman) group: e.g., group 14/19/20 — a mismatch is a classic silent failure.
• Authentication method: PSK vs certificates — and if PSK, the pre-shared key must be identical.
• Peer identity / IP: correct peer address and IKE ID; for IKEv1, aggressive vs main mode.
• Lifetime: should align (often non-fatal but check).

Debugging: on Cisco run debug crypto isakmp (or debug crypto ikev2) and watch for "no proposal chosen" (algo/DH mismatch) or "phase 1 retransmit / pre-shared key mismatch". On FortiGate run diagnose debug app ike -1 + diagnose debug enable and look for "negotiation failure" or PSK/peer-ID errors.

👉 Interview tip: "No proposal chosen" almost always = encryption/hash/DH mismatch; auth-stage failure = PSK or peer-ID wrong.

The clue is that the tunnel builds and one direction works, but traffic from behind the NATed peer never arrives — a classic NAT-T / asymmetric encapsulation symptom.

Confirm it's NAT-T:

1. Check the IKE session details — most firewalls show a "NAT detected" flag and report the negotiation running over UDP 4500 instead of UDP 500. If NAT was detected, NAT-T must be working end to end.
2. Verify NAT-T is enabled on both peers (some platforms disable it by default).
3. Look at encrypt vs decrypt counters: if you encrypt but never decrypt, return ESP-in-UDP isn't getting back.

What to check for UDP 4500: ensure UDP 4500 (and UDP 500) is permitted inbound/outbound on every firewall and the intermediate NAT/ISP device, that no ACL or upstream filtering is dropping it, and that the NAT device isn't timing out the UDP 4500 mapping (tune DPD/keepalives to hold the pinhole open).

👉 Interview tip: One-way data + peer behind NAT → suspect blocked or timed-out UDP 4500 first.

This "drops when idle, comes back when traffic resumes" pattern points to the tunnel being torn down during inactivity. Likely causes:

• Idle timeout: the SA is configured to expire after X seconds of no traffic, so a lull kills it.
• DPD (Dead Peer Detection) too aggressive: during a lull there's no traffic, DPD probes go unanswered (or are mis-tuned), and the peer is wrongly declared dead, tearing the SA down.
• NAT pinhole timeout: if a NAT sits in the path, the UDP 4500 mapping ages out during the lull, so probes can't return.

Fixes:

1. Disable or lengthen the idle timeout so the tunnel stays up.
2. Tune DPD sensibly (reasonable interval + retries; not too aggressive) or enable NAT keepalives to keep the pinhole open.
3. Optionally send periodic keepalive traffic (e.g., a small ping) to prevent idling.

👉 Interview tip: The tell is "idle = down, traffic = up." Name idle-timeout, DPD tuning, and NAT keepalive as the three levers.

Symptom (small pings work, large transfers/HTTPS hang) is the textbook MTU / PMTUD black-hole. IPsec adds overhead (new IP header + ESP), so a full-size 1500-byte packet plus encapsulation exceeds the path MTU. Large TCP packets typically carry the DF (Don't Fragment) bit, so the router can't fragment — it should send back an ICMP "fragmentation needed" (type 3, code 4) message. If a firewall or ISP blocks that ICMP, the sender never learns to shrink packets: small packets (ping, TCP handshake) pass, but big data packets are silently dropped → connections hang. That blocked-ICMP failure is the "black hole."

Diagnosis: ping with progressively larger sizes and DF set (e.g., ping -f -l 1400 on Windows, or ping -M do -s 1400 on Linux) to find where it stops; confirm the handshake succeeds but bulk transfer stalls.

Fix (in order):

1. TCP MSS clamping on the tunnel interface (commonly 1350-1360) — the cleanest fix; it caps the TCP segment size so packets never exceed path MTU.
2. Lower the tunnel/interface MTU to account for IPsec overhead.
3. Allow ICMP type 3 code 4 so PMTUD works.

👉 Interview tip: "Ping OK, big transfers hang" = MTU/PMTUD black hole → answer MSS clamping first.

"Flaps every few hours, no config change" points to a periodic, timer-driven or path-driven cause. Work through it systematically:

1. Rekey collisions: note the flap interval — if it lines up with the Phase 1/2 lifetime, both vendors are likely rekeying simultaneously and creating duplicate/overlapping SAs (IKEv1 is notorious; vendors disagree on who reinitiates). Fix: align lifetimes, designate one initiator, prefer/upgrade to IKEv2.
2. DPD storms: mismatched DPD intervals across vendors cause false "peer dead" declarations and constant reconnects. Check logs for repeated DPD timeouts; standardize DPD settings.
3. Asymmetric routing: if return traffic takes a different path (multi-WAN/ECMP), packets bypass the SA or anti-replay drops them. Verify routing is symmetric for tunnel endpoints.
4. ISP path issues: intermittent loss/latency on the underlay drops IKE keepalives. Run continuous ping/MTR to the peer's public IP during a flap window and correlate timestamps with the VPN logs.

👉 Interview tip: Correlate the flap interval with lifetimes first — matching interval screams rekey collision; random interval points to ISP/DPD/routing.

The goal: migrate 60+ partner tunnels to IKEv2 + AES-GCM + strong DH/PFS with zero flag-day outage. Run it as a phased program:

1. Discover & baseline: inventory every tunnel — peer, IKE version, encryption/hash, DH group, PFS, lifetimes. Rank by risk (deprecated 3DES/DES/MD5/DH-1/2/5 first) and by partner responsiveness.
2. Define a target standard: e.g., IKEv2, AES-256-GCM, SHA-256+, DH group 19/20 (ECDH), PFS on, sane lifetimes — plus a documented "acceptable interim" tier for laggards.
3. Pilot: migrate 2-3 low-risk, cooperative partners first; validate and build a repeatable runbook.
4. Phased rollout: schedule per-partner change windows; coordinate so both sides cut over together (a one-sided proposal change = instant mismatch). Where supported, configure multiple proposals so the strongest mutual one is selected automatically — this avoids hard cutovers.
5. Stubborn partners: isolate them on the interim tier, document the risk/exception, set a deadline, and monitor.
6. Verify & decommission: confirm each tunnel renegotiated on the new policy, then remove deprecated proposals.

👉 Interview tip: Stress proposal lists for graceful negotiation + coordinated per-partner windows — that's how you avoid a flag-day outage.