Site-to-Site VPN Phase 1 Up Phase 2 Down Troubleshooting
A network engineer configures a site-to-site VPN with a colleague. During testing, the engineer discovers that only phase 1 is up, and application traffic cannot pass. Which configuration parameter must be checked on each device?
Community Insight
The question tests the distinction between Phase 1 (ISAKSA/IKE SA) and Phase 2 (IPsec SA) parameters, with the common trap being the assumption that peer connectivity issues persist even when the management plane is up.
When a site-to-site VPN tunnel has Phase 1 established but fails to pass traffic, the issue typically lies in Phase 2 negotiation parameters. This analysis identifies the encryption domain as the critical configuration element requiring verification on both peers.
Many learners select 'peer IP address' or 'preshared key' because these are fundamental to VPN setup; however, since Phase 1 is successfully up, these parameters have already been validated by the IKE negotiation process.
Community Discussion (6 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
Phase 1 of an IPsec VPN establishes the secure channel for managing the connection, validating identities, and negotiating cryptographic policies. Since the prompt states that "phase 1 is up," we can definitively rule out mismatches in authentication credentials (like preshared keys), network reachability (peer IPs), and basic hash/encryption algorithms agreed upon during IKEv1/v2 handshake. Phase 2 is responsible for establishing the actual data security association (SA) and defining which traffic should be encrypted. This definition is controlled by the "encryption domain" (also known as proxy IDs or traffic selectors). If the encryption domains do not match exactly on both peers, the tunnel will remain in Phase 1 without proceeding to Phase 2, resulting in no application traffic passing.Why the Other Options Are Wrong
Options A (hash algorithm), B (peer IP address), and D (preshared key) are all components of the Phase 1 negotiation. For Phase 1 to complete successfully, the peers must agree on the hash algorithm, reach each other via the specified IP addresses, and authenticate using the correct preshared key. If any of these were mismatched or incorrect, Phase 1 would fail to establish entirely, leaving the tunnel in a down state. The fact that Phase 1 is active proves these elements are functioning correctly.Community Comment Notes
Community consensus strongly supports Option C, noting that the encryption domain dictates the "interesting traffic." As user devildog noted, "encryption domain - this is the 'interesting traffic' that is meant to be encrypted." Another commenter, XBfoundX, emphasized that "Policy-based IPSec VPNs with encryption domains require exact matching between both peers for successful tunnel negotiation." While one user suggested checking the peer IP, the community largely corrected this by pointing out that Phase 1 success implies IP reachability and authentication are already verified.Official Reference
Exam Strategy
Always evaluate the state of the VPN tunnel first. If Phase 1 is up, ignore authentication and reachability settings; focus immediately on Phase 2 parameters like encryption domains (proxy IDs) and transform sets.
Frequently Asked Questions
Why is the preshared key wrong if the tunnel isn't working?
A mismatched preshared key prevents Phase 1 from completing. Since Phase 1 is up, the keys are correct.
What is an encryption domain in IPsec?
It defines the traffic selectors (source/dest subnets) that are considered 'interesting' and eligible for encryption in Phase 2.