Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?


Step 2: Configure and Verify an IPsec VPN

It has been a big day, we know. Before you go home, there’s one more ask for the new branch office. You'll need to establish a secure IPsec VPN tunnel to the remote corporate office. This tunnel allows members of the trust zone to securely reach specific corporate resources on the subnet over the Internet.

Secure tunnels are a key feature of SRX platforms. Being able to send sensitive traffic over the public Internet without concern for eavesdropping, or data theft, is no small task. An IPsec VPN lets you securely tunnel traffic through the public Internet. Because the traffic is tunneled, there's no need to perform source NAT.

Don't worry, we'll make this easy for you!

This step covers how to:

  • Configure st0 tunnel interfaces
  • Configure static routing to steer traffic into the IPsec tunnel
  • Configure IKE and IPsec parameters for a dynamic route-based VPN
  • Adjust security policies to ensure that only traffic from the trust zone sent to is presented to the IPsec tunnel
  • Use the Junos CLI to verify IPsec VPN operation
Figure 1: An IPsec VPN for Secure Branch to Remote Office Connectivity An IPsec VPN for Secure Branch to Remote Office Connectivity

IPsec VPN Overview

In this example, traffic sent from the trust zone to uses the IPsec tunnel. This traffic bypasses source NAT and exits the remote end with the original source IP from the trust-vlan subnet.

The tunnel operates point-to-point between the branch and the remote office. This makes IP address assignment optional. In this example, we assign addresses to the tunnel endpoints to permit ping testing as a diagnostic aid. A static route is used at each end to direct traffic into the tunnel. Note that the static route at the remote location matches the subnet of the trust zone. You must match on this address because source NAT does not occur for traffic using the tunnel.


The topology shows a cloud between the branch and remote location. Typically this cloud is the Internet. To reduce the number of devices in our topology, we have a direct connection between the branch and remote locations. As a result, we have a single subnet that spans the Internet cloud.

This means that later, when you define the Internet Key Exchange (IKE) local and remote gateways, the two endpoints share the subnet. There's no difference in configuration or operation if the IKE gateways are on remote subnets. Specifying a remote IKE gateway is the typical use case when the two sites have intervening hops through the Internet.