Spoke-to-Spoke Traffic Through a Hub IPsec VPN
An SRX at the hub terminates two route-based IPsec VPNs. st0.0 connects spoke A (192.168.10.0/24); st0.1 connects spoke B (192.168.20.0/24). Both st0 interfaces are in zone vpn. IKEv2 SAs and IPsec SAs are up for both spokes. Hub LAN 10.0.0.0/24 is reachable from both spokes. Spoke A can reach the hub LAN but cannot reach spoke B; spoke B also cannot reach spoke A. show security flow session source-prefix 192.168.10.0/24 destination-prefix 192.168.20.0/24 returns no sessions on the hub. show security policies from-zone vpn to-zone vpn shows no policies. The hub has routes for 192.168.10.0/24 via st0.0 and 192.168.20.0/24 via st0.1. Both spokes use traffic selectors limited to their own local subnet and 10.0.0.0/24.
1. The tunnels are up and the hub has routes for both remote subnets, yet spoke-to-spoke traffic fails. What is the first policy issue, and why does the hub not create a session?
Read the worked answer
The hub receives the packet from spoke A on st0.0, which is in zone vpn. The destination 192.168.20.0/24 is reachable via st0.1, which is also in zone vpn. This is intra-zone traffic, and Junos denies intra-zone traffic by default when no policy exists. The hub therefore drops the packet before egressing it into the spoke B tunnel, which is why no session appears for 192.168.10.0/24 to 192.168.20.0/24.
The missing configuration is a from-zone vpn to-zone vpn policy that permits the spoke A subnet to the spoke B subnet, and the reverse direction if the design requires it. Because the two st0 interfaces are in the same zone, a normal inter-zone policy between vpn and some other zone will not help. After adding the intra-zone policy, confirm that the hit count increments and that a session appears. If the policy exists but still does not match, check the source and destination address book entries and confirm that both st0 interfaces are actually in zone vpn.
2. After the intra-zone policy is added, pings still fail. The SAs remain up. What is the next most likely cause, and how would you prove it from the spoke and hub outputs?
Read the worked answer
The next likely cause is a traffic-selector mismatch. The hub can route the packet into st0.1, but spoke B will only accept traffic that is permitted by the traffic selector negotiated for its IPsec SA. The scenario states that each spoke limits its selector to its own local subnet and 10.0.0.0/24. Spoke B's selector therefore does not include 192.168.10.0/24, so when the hub sends a packet sourced from 192.168.10.x to 192.168.20.x, spoke B has no matching SA policy and drops it. The tunnel can still show Phase 1 and Phase 2 as up because the existing selectors are valid for hub-LAN traffic.
Prove it by checking show security ipsec sa detail on spoke B for the installed traffic selectors, and by checking show security ipsec statistics for outbound packets that are dropped or not encapsulated. On the hub, verify that the packet is being routed into st0.1 and that the session exists. Then expand the selectors on both spokes to include the remote spoke subnet, or use a broader selector if the security design permits it. Re-establish the SAs and retest. Also confirm that the hub's policy permits the reverse direction, because stateful return may not cover a separate initiated flow.