IPsec Over a Private WAN: SRX Policy Boundaries to Check

A private WAN can carry the outer packets of an IPsec tunnel, so the peer addresses do not have to be public internet addresses. What changes is the path those outer packets take and the permissions on the interface that receives them. On an SRX, the outer control path, the tunnel interface binding, and the forwarded-traffic policy are three separate objects. Troubleshooting one while the other two are wrong is the usual reason a tunnel stays down.

Record the outer IKE path first

Write down four values before touching policy: the peer address, the local interface that receives IKE, the routing context that reaches the peer, and the route that selects that interface. IKE packets are addressed to the SRX itself, so they need host-inbound permission on the receiving zone, not a forwarded-traffic policy. A private WAN address does not remove that requirement, because the packet still terminates on the device.

Check the installed state with show security ike sa and the configuration with show configuration security ike. The first tells you whether phase 1 exists; the second tells you what the device thinks it should be doing.

Bind the tunnel interface to the right policy

A route-based VPN binds a tunnel interface to a VPN object, and protected prefixes are routed into that interface. Record which interface, which route, and which policy permits the applications between the relevant zones. A zone named trust is a policy container, and the name does not prove that the required control or data packets are allowed.

Read the actual bindings rather than an old diagram: show configuration security ipsec vpn for the bind-to-interface setting and show configuration security policies for the rules that reference the tunnel zone.

If the protected route points somewhere else, the tunnel can be up while traffic never enters it. That is a routing problem wearing an IPsec costume.

Keep the peer route on the underlay

The route to the external peer must resolve through the underlay, not recursively through the tunnel it establishes. If the peer route points at the tunnel interface, IKE packets chase their own tunnel and phase 1 never completes. The reply path for protected traffic needs its own correct route and policy, and it is usually the missing half when one direction works. Read the route table entry for the peer address and confirm the outgoing interface is the WAN interface.

Check it with show route 198.51.100.10, substituting the real peer address, and confirm the next hop is not a tunnel interface.

Verify control and service in order

Work upward: phase 1 state, phase 2 state, then a real application flow. show security ipsec sa lists the security associations, and show security flow session destination-prefix 10.60.0.0/16 shows whether forwarded sessions are being created for the protected network.

A healthy control relationship and a working data path are two different results, and phase 2 passing says nothing about whether policy permits the application. Test one permitted flow and one that policy should reject, so the difference is visible.

Record the peer route, the host-inbound permission, the tunnel binding, the inner route, and the application policy together. Those five records show which layer owns a future failure without relying on a port label.