IPsec VPN Passes Only One Subnet Pair
Acme Manufacturing connects an SRX340 at headquarters to a Cisco ASA at a partner site. HQ uses 10.1.0.0/16 and 10.2.0.0/16; the partner uses 192.168.10.0/24 and 192.168.20.0/24. The VPN is route-based with st0.0, IKEv2, and a pre-shared key. Phase 1 and phase 2 are up. The SRX configuration has one traffic selector: local 10.1.0.0/16, remote 192.168.10.0/24. Static routes for both remote subnets point to st0.0, and security policies permit both local subnets to both remote subnets. A test from 10.1.5.10 to 192.168.10.50 succeeds. A test from 10.2.5.10 to 192.168.20.50 fails. The partner administrator confirms the ASA crypto ACL includes 10.1.0.0/16 to 192.168.10.0/24 and 10.2.0.0/16 to 192.168.20.0/24. The partner also says they see no phase 2 proposals for the second pair.
1. Why does only one subnet pair work when routing and security policies are already in place?
Read the worked answer
Route-based VPN does not eliminate traffic selectors. On Junos, the IPsec VPN configuration still defines which local and remote prefixes are negotiated for each SA. Here only one selector exists: 10.1.0.0/16 to 192.168.10.0/24. Traffic from 10.2.0.0/16 to 192.168.20.0/24 may match a static route to st0.0, but it does not match any negotiated selector, so the SRX cannot encrypt it. The partner sees no phase 2 proposals for the second pair because the SRX never initiates them. The static routes only determine that the packet should use st0.0; they do not create an SA. The security policy also only permits the flow after a tunnel exists. To confirm, I would check the IPsec SA list and look for only one pair of selectors, then run a flow trace from 10.2.5.10 to 192.168.20.50 and observe that no tunnel is selected. The first pair works because its selector exactly matches the configured traffic selector.
2. How would you fix the SRX configuration, and what should you confirm with the partner?
Read the worked answer
Add a second traffic selector for local 10.2.0.0/16 and remote 192.168.20.0/24, or replace the specific selectors with 0.0.0.0/0 on both sides if the partner supports wildcard selectors and the design permits it. With two specific selectors, the SRX will negotiate two phase 2 SAs, one per pair. Confirm that the ASA crypto ACL matches each selector exactly, because IKEv2 proxy IDs must match in both directions. Also confirm that the partner's ASA is not policy-based with a single tunnel group that rejects multiple selectors. If it is policy-based and limited, you may need a separate VPN or a summarized selector that covers both local and remote prefixes. After the change, clear the old SAs or let them rekey, then verify both SAs and test in both directions. Do not rely on static routes alone; they are necessary but not sufficient.
3. What would you check if the second selector is added but phase 2 still fails?
Read the worked answer
If the second selector is configured but phase 2 fails, compare the exact proxy IDs on both peers: local and remote prefix, protocol, and port. A common failure is a summary mismatch, such as 10.2.0.0/16 on one side and 10.2.0.0/24 on the other. Check the IKEv2 proposal and policy settings as well, because the peer may require a specific encryption or DH group for the second tunnel. Confirm that the ASA's crypto ACL order or tunnel-group mapping does not cause the second pair to be evaluated against the wrong policy. On the SRX, review the kmd logs and the IPsec SA detail output for the proposed selectors. Also verify that no NAT rule is translating 10.2.0.0/16 or 192.168.20.0/24 before the VPN, because NAT can change the addresses that the selector must match. Finally, test with a single ping sourced from the correct local subnet so the flow trace shows the exact selector being attempted.