Short answer: In IKEv1, Phase 1 authenticates the VPN peers and establishes the IKE/ISAKMP security association that protects their negotiation; Phase 2 uses that protected channel to negotiate IPsec security associations for data traffic.[1] An established Phase 1 is therefore not proof that your application traffic has a working IPsec SA.
This is the distinction behind the interview question, “What is the difference between IPsec Phase 1 and Phase 2?” The terminology belongs to IKEv1: IKEv2 uses IKE_SA_INIT, IKE_AUTH and CREATE_CHILD_SA exchanges rather than the same two-phase process.[2] IKEv1 is deprecated; learn its terminology for interviews and legacy troubleshooting, not as a recommendation for a new deployment.[3]
IPsec Phase 1 vs Phase 2: comparison table
The following table describes the IKEv1 model, not an IKEv2 packet trace.[1]
| Question | Phase 1 | Phase 2 |
|---|---|---|
| What is established? | IKE/ISAKMP SA: the protected negotiation channel.[1] | IPsec SAs: protection for the selected data flows.[1] |
| Which exchange? | Main Mode or Aggressive Mode.[1] | Quick Mode, protected by the Phase 1 SA.[1] |
| What is agreed? | IKE encryption/hash, authentication method and DH group.[1] | IPsec protection parameters and keying material; identities can specify protected traffic.[1] |
| What should I inspect first? | Peer reachability, IKE policy, identity and authentication | IPsec proposal, protected subnet pair and PFS settings |
| Does success prove application delivery? | No: check the data SAs next | No: test forwarding and the application as well |
The final two rows are a suggested troubleshooting order, not a vendor-independent list of state names.
What is a security association?
A security association, or SA, is the policy and keying state used to protect communication.[1] The IKEv1 ISAKMP SA is bidirectional, whereas IPsec data SAs are directional; IKEv2 describes ESP/AH SAs as pairs with one SA in each direction.[1][2] In a basic two-way ESP connection, think “an outbound data SA and an inbound data SA,” not “one encryption key for everything.”
One IKEv1 Phase 1 negotiation can support multiple Phase 2 negotiations.[1] When troubleshooting, identify the affected subnet pair instead of assuming that one working network proves that every protected network is covered.
Phase 1: establish the protected negotiation channel
Phase 1 negotiates the IKE protection parameters and authenticates the peers, using Main Mode or Aggressive Mode.[1] Pre-shared-key authentication is one supported method; signature-based authentication is another.[1] Do not confuse the public peer address with the identity that the authentication policy expects.
A useful conceptual flow is:
Reach the intended peer
-> agree on IKE protection parameters
-> exchange keying material
-> authenticate peer identities
-> establish the IKE/ISAKMP SA
This is a learning outline, not the exact ordering of every payload in every authentication mode. RFC 2409 defines the actual exchanges.[1]
Suggested first checks: confirm the configured IKE version, peer address, bidirectional reachability, accepted proposals and authentication policy. With certificates, inspect trust, validity and identity matching; with a pre-shared key, verify configuration securely without pasting secrets into logs or tickets.
Phase 2: negotiate protection for selected data traffic
Quick Mode runs under the established IKEv1 SA and negotiates the data-protection SAs and fresh keying material.[1] It can include an additional Diffie-Hellman exchange for perfect forward secrecy (PFS).[1] A successful Phase 1 does not establish that the peers agree on the Phase 2 policy.
For a practical peer-to-peer comparison, record the IPsec protocol and algorithms, tunnel/transport mode, protected traffic identities, PFS requirement/group and lifetime settings. Cisco crypto-map configuration exposes transform sets, SA lifetime and PFS settings separately.[4] Compare accepted policy, not just object names: local configuration names are not proof of an interoperable proposal.
Transform-set, crypto map and crypto domain
- Transform-set: in Cisco terminology, an acceptable combination of security protocols and algorithms for an IPsec SA.[4]
- Crypto map: in a classic Cisco policy-based VPN, the configuration ties together the traffic-matching ACL, peer and transform-set, with additional options such as lifetime and PFS; the map is applied to the relevant interface.[4]
- Crypto domain / encryption domain: terminology used for the networks or traffic intended to be protected. For troubleshooting, translate the label into concrete local/remote addresses, masks and any protocol/port restrictions rather than relying on the name alone.
In IKEv2, traffic selectors explicitly describe address ranges, protocols and port ranges, and the responder can narrow a proposal to an allowed subset.[2] Do not assume that every platform's “crypto domain” object has identical semantics.
A simple packet-flow example
The following topology is fictional and illustrative; it is not an executed router lab. Assume tunnel-mode ESP, no address translation for this flow, and policy permitting the application in both directions.
Client 10.10.10.10 Server 10.20.20.20
| |
Gateway A -- public/underlay network -- Gateway B
Protected network at A: local 10.10.10.0/24, remote 10.20.20.0/24
Protected network at B: local 10.20.20.0/24, remote 10.10.10.0/24
- The client sends a packet toward the server; check that Gateway A receives it and selects the intended VPN path.
- If negotiation is needed, separate establishment of the IKE SA from establishment of the data SAs.
- Check that the installed data SA covers this particular client-to-server flow.
- Trace encapsulation at A, delivery across the underlay and decapsulation at B.
- Follow the decrypted packet to the server, then repeat the observations for the reply.
This is an operational test plan, not evidence that any given device performs NAT, routing and policy lookup in that exact order. Record the actual packet identities at the appropriate points on your platform.
How is IKEv2 different?
Do not answer an IKEv2 question by simply renaming Main Mode and Quick Mode. In the common initial exchange, IKE_SA_INIT negotiates IKE parameters and exchanges nonces and DH values; IKE_AUTH authenticates the peers and establishes the first Child SA.[2] CREATE_CHILD_SA creates additional Child SAs or performs rekeying, including IKE SA rekeying.[2]
IKEv1: Phase 1 -> protected Quick Mode / Phase 2 -> IPsec data traffic
IKEv2: IKE_SA_INIT -> IKE_AUTH, normally including first Child SA
-> additional/rekey exchanges when required
These are conceptual summaries of the exchange models, not universal message-count promises.[1][2] In particular, the first IKEv2 Child SA normally does not wait for a separate CREATE_CHILD_SA exchange.[2]
Troubleshooting: choose the next check from the evidence
Use this checklist as a hypothesis generator. None of these observations, by itself, proves a single root cause.
| Observation | Suggested next checks |
|---|---|
| No IKE SA | Peer/version, underlay reachability, filtering, proposal and authentication logs |
| IKE SA present, relevant IPsec SA absent | Protected subnet pair/selectors, transform proposal, mode, PFS and negotiation logs |
| Data SA present, no encapsulation during your test | Did the client packet arrive? Check selected path, matching policy and actual translated/original tuple |
| Local encapsulation rises, peer decapsulation does not | Correlate the same test on both peers; inspect underlay delivery and inbound IPsec drops |
| Peer decapsulation rises, application still fails | Peer LAN path, security policy, server listener, return route and reverse counters |
| Failure appears around rekey | Compare event timestamps, proposals, PFS settings, lifetimes and replacement-SA installation |
IKE commonly uses UDP 500; IKEv2 reserves UDP 4500 for UDP-encapsulated ESP and IKE and requires UDP encapsulation for ESP when NAT is detected under its NAT-traversal procedure.[2][4] Native ESP uses IP protocol 50, not “TCP port 50.”[4] Check the transport actually observed on the wire rather than blindly opening every possible protocol.
For a classic Cisco crypto-map configuration, these are read-only inspection examples from the configuration guide; availability depends on platform and release.[4]
show crypto map
show crypto ipsec transform-set
Use the device's IKE-SA and IPsec-SA status views separately, and take before/after counter snapshots around one approved application attempt. Keep disruptive SA-clearing commands out of the initial checks; Cisco explicitly notes that an unrestricted clear of the SA database clears active security sessions.[4]
Common interview pitfalls
- “Phase 1 encrypts the user traffic.” It establishes the protected IKE negotiation channel; Phase 2 establishes the data-protection SAs.[1]
- “IKEv2 has the same Main Mode and Quick Mode phases.” It uses a different exchange model, with the first Child SA normally established during IKE_AUTH.[2]
- “One successful Phase 2 means every subnet works.” Check the exact installed policy/selectors and the test flow rather than generalizing from another subnet.
- “A green VPN icon proves application reachability.” Treat SA establishment, packet forwarding and application success as separate acceptance checks.
- “An old example is a secure deployment template.” IKEv1 is deprecated, and RFC 9395 recommends upgrading/reconfiguring to IKEv2 rather than carrying over old algorithms unchanged.[3]
A concise interview answer
“In IKEv1, Phase 1 authenticates the peers and builds the IKE/ISAKMP SA; Phase 2 uses Quick Mode over that channel to negotiate the IPsec SAs that protect the selected traffic.[1] If Phase 1 succeeds but Phase 2 fails, I compare the data-protection proposal, protected networks and PFS settings before testing forwarding. For IKEv2, I explain IKE_SA_INIT and IKE_AUTH instead, including the first Child SA in the normal IKE_AUTH exchange.[2]”
Related reading
- NAT vs PAT vs Static NAT vs DNAT: follow address and port changes
- Palo Alto IPsec tunnel up but no traffic: routing and proxy-ID troubleshooting
Summary: Separate the negotiation channel, the data SAs and the application test. Identify the IKE version before using phase terminology, and troubleshoot the precise protected flow rather than the tunnel's overall status.
Preparing for a network engineering interview? Practise explaining the difference without looking at the table, then describe your next three checks when the IKE SA is up but the remote application is unreachable.
Post a Comment