PermitANY
JuniperConfig523 downloads

Juniper JunOS Site-to-Site IPSec VPN

IKEv2 site-to-site IPSec VPN for Juniper SRX firewalls: IKE proposal/policy/gateway, IPSec proposal/policy/VPN, tunnel interface, and security zone/policy binding.

↓ example.txt

What is it?

Juniper SRX IPSec VPN uses a zone-based security model with dedicated 'st0' (secure tunnel) interfaces. The configuration has four layers: IKE proposal (algorithms), IKE policy (authentication), IKE gateway (peer), and IPSec VPN (binds to st0 interface). The st0 interface is placed in a dedicated VPN zone, and security policies control traffic between the VPN zone and internal zones — identical in concept to Palo Alto's tunnel interface + zone approach. Juniper SRX is widely used for MPLS-based VPNs and large-scale hub-and-spoke designs.

When to use

  • ·Site-to-site VPN on Juniper SRX firewalls
  • ·Connecting SRX to third-party gateways (Cisco ASA, Palo Alto, AWS)
  • ·Hub-and-spoke topologies with SRX as the hub
  • ·AutoVPN (dynamic spoke-to-spoke tunnels) for large branch deployments

When NOT to use

  • ·Remote user VPN — use Juniper's Pulse Secure or SRX Dynamic VPN instead
  • ·MX series routers — MX uses a different IPSec implementation (not SRX-style zones)

How it compares

vs Palo Alto IPSec VPNVery similar architecture — both use a tunnel interface (st0 vs tunnel.X) in a dedicated zone with security policies. Palo Alto calls the interface 'tunnel.X'; Juniper calls it 'st0.X'. Configuration syntax differs but concepts are identical.
vs Cisco IOS IPSec (crypto map)IOS crypto maps are applied to physical interfaces without a dedicated tunnel interface. Juniper st0 is a dedicated routed interface — cleaner routing and easier policy application.

Prerequisites

  • →WAN interface with public IP must be configured
  • →st0 interface unit number chosen (st0.0, st0.1, etc.) — one per tunnel
  • →Dedicated VPN zone must be created before assigning st0 to it
  • →Security policies must be created for both directions: trust-to-vpn-zone and vpn-zone-to-trust
  • →IKE and IPSec proposal parameters must match the remote peer exactly

Config Generator

Verification commands

show security ike security-associations

Verify IKE Phase 1 SA is established

ExpectedShows SA with peer IP and 'UP' state. 'DOWN' or no output means Phase 1 failed.

show security ipsec security-associations

Verify IPSec Phase 2 tunnel is up and passing traffic

ExpectedShows SA with peer, bytes in/out. Zero bytes means tunnel is up but no traffic is flowing.

show interfaces st0.X

Verify st0 tunnel interface is up

ExpectedPhysical link and protocol should both be 'Up'. 'Down' means VPN is not established.

Debug commands

show security ike statistics

Show IKE negotiation statistics and failure counts

Common mistakes & fixes

SymptomIKE Phase 1 not establishing
CauseUDP 500/4500 blocked by security policy, wrong PSK, or IKE proposal mismatch
FixVerify security policy allows UDP 500 from untrust. Check 'show security ike statistics' for error codes. Test PSK matches on both sides.
SymptomPhase 1 up but Phase 2 not establishing
CauseIPSec proposal mismatch or traffic selectors (proxy IDs) don't match
FixFor route-based VPN, traffic selectors default to 0.0.0.0/0 — but policy-based peers may require specific selectors. Check IPSec proposal algorithms match exactly.
SymptomTunnel up but traffic not passing between sites
CauseSecurity policy missing for the traffic direction, or route to remote subnet not via st0
FixVerify static route: 'show route <remote-subnet>'. Verify security policies exist in both directions for the VPN zone.

Further learning

Recommended books to go deeper on this topic.

Palo Alto Networks Firewall Deployment and Administration

Tom Piens · Packt · IPsec VPN on PAN-OS — IKEv1/v2, GlobalProtect, tunnel configuration

Cisco ASA: All-in-One Next-Gen Firewall, IPS, and VPN Services

Jazib Frahim, Omar Santos, Andrew Ossipov · Cisco Press · IKE phase 1 & 2 deep dive — concepts apply to all vendors

Related configs