New subnet not reachable over site-to-site VPN
An R81.20 cluster (gw1 active, gw2 standby) terminates a domain-based site-to-site VPN with a Cisco ASA. The community uses certificate authentication. Existing traffic between 10.10.0.0/16 and 192.168.10.0/24 works. A new subnet 10.20.0.0/24 was added to the local encryption domain and the policy was installed. Hosts in 10.20.0.0/24 cannot reach 192.168.20.0/24, although 192.168.20.0/24 is already in the remote encryption domain and was reachable from 10.10.0.0/16. SmartLog shows 'Encryption Failure: No response from peer' for the first packets, and ike.elg shows Quick Mode proposal failures for the new subnet. The partner confirms no change on its side. No NAT is configured for 10.20.0.0/24.
1. How do you determine whether the failure is Phase 1, Phase 2, or policy/encryption-domain mismatch?
Read the worked answer
Because existing 10.10.0.0/16 to 192.168.10.0/24 traffic works, Phase 1 and the peer relationship are healthy. The failure is specific to the new source subnet, so focus on Phase 2 traffic selectors and encryption-domain matching. On the gateway, run vpn tu and list SAs; look for an SA for 10.20.0.0/24 to 192.168.20.0/24. Check ike.elg around the test timestamp for Quick Mode failures, and use a short vpn debug or fw monitor capture to see whether the gateway encrypts the packet. In SmartLog, 'Encryption Failure: No response from peer' plus Quick Mode errors indicates Phase 2, not a missing access rule. A policy drop would name a rule; an encryption-domain mismatch often fails before the rule can accept the cleartext.
2. What is the most likely configuration gap, and what must be changed on each side?
Read the worked answer
Most likely the partner's remote encryption domain (the set of local networks it accepts from you) still contains only 10.10.0.0/16 and not 10.20.0.0/24, even though your local encryption domain was updated. On Check Point, verify the local encryption domain includes 10.20.0.0/24 and the remote encryption domain includes 192.168.20.0/24, then install policy. On the Cisco side, the mirrored crypto ACL or interesting-traffic definition must include 10.20.0.0/24 as a source to 192.168.20.0/24. If the partner uses a dynamic or summarized ACL, confirm the summary covers the new subnet. After both sides are updated, clear the old IKE and IPsec SAs with vpn tu so Phase 2 renegotiates; otherwise the old selectors may persist.
3. How would you validate without relying only on ping, and what would you monitor?
Read the worked answer
Do not validate with ping alone; ICMP may be allowed by a different rule or handled differently by the partner. Use a TCP test to 192.168.20.x on an allowed port and confirm the SA with vpn tu. Run fw monitor and look for the packet being encrypted and the reply being decrypted; on the wire, tcpdump should show ESP between the peers. Check SmartLog for accepts and for encryption errors, and confirm no NAT is hiding 10.20.0.0/24. Repeat after clearing SAs. If TCP works but ping fails, investigate ICMP policy separately; if neither works, re-check the selectors on both sides.