Site-to-Site VPN Phase 1 Up Phase 2 Down Troubleshooting
Short answer
C Check the encryption domain on each device to ensure the interesting traffic definitions match for Phase 2 negotiation.
Question
Key Takeaways
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.
Common mistake: 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.
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
This link opens the official vendor documentation in a new tab.
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?
What is an encryption domain in IPsec?
Discussion 6 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.
From public community threads 6
-
devildog 👍 3 Answered CI believe the answer is C. encryption domain - this is the "interesting traffic" that is meant to be encrypted. If I'm not mistaken, the other options are all performed in phase 1 and phase 1 is up.
-
ITVI 👍 2 Answered CAs mentioned by others, C is correct since Phase 1 is already up, Phase 2 is all 'crypto acl or proxy ID' therefore the 'interesting traffic' is not matching so check your encryption domain.
-
luismg 👍 2 Answered Cike phase 1 passes so that means the peer ips are ok including the preshared key phase 2 is the encryption domain. Answer C
-
XBfoundX 👍 1Subnet masks must match precisely between peers. A broader mask like 10.0.0.0/8 on the remote side would not correctly encrypt traffic from more specific networks like 10.20.1.0/24 or 10.40.0.0/24. Mismatched subnet masks typically result in traffic drops or tunnel establishment failures. Different vendors handle encryption domain matching with varying levels of strictness. Cisco and Oracle, for instance, enforce exact matches for Phase 2 security association (SA) negotiation. In contrast, Check Point and Palo Alto may be more flexible, potentially accepting broader ranges but risking interoperability issues with other vendors.
-
XBfoundX 👍 1 Answered CPolicy-based IPSec VPNs with encryption domains require exact matching between both peers for successful tunnel negotiation and traffic flow. The encryption domains, also known as proxy IDs or traffic selectors, must be mirrored on both sides of the VPN connection. For example, if the local side defines domains as 10.20.1.0/24 and 10.40.0.0/24 (source) with a remote domain of 192.168.72.0/24 (destination), the remote peer must configure two corresponding domains: 192.168.72.0/24 (source) to 10.20.1.0/24 (destination), and 192.168.72.0/24 (source) to 10.40.0.0/24 (destination).
Show 1 more comment
-
masal 👍 1Configure the IKEv1 policy ! crypto ikev1 policy 10 authentication pre-share encryption aes-256 hash sha group 5 lifetime 3600 from https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-firewalls/215884-configure-a-site-to-site-vpn-tunnel-with.html peer IP address is ther correct answer. It in not a blief, just proof.
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.