Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?


Configure an IPsec VPN

IPSec VPN Design Goals

Your IPsec VPN must meet these criteria:

  • Configure a dynamic IPsec VPN to support DHCP address assignment to the WAN interface by the Internet service provider.
  • Ensure that only traffic originating in the trust zone is able to use the IPsec tunnel.
  • Ensure that only traffic destined to the subnet uses the IPsec tunnel.
We'll use the parameters in Table 1 to configure an IPsec VPN.
Table 1: IPsec VPN Parameters
Parameter Value
Tunnel interface st0
Branch Tunnel IP
Corporate Tunnel IP
IKE Proposal standard
IKE mode aggressive
Pre-shared key "srx_branch"
Tunnel establishment immediately
Branch identity branch
Corporate identity hq
Tunnel security zone vpn

Configure a Route-Based IPsec VPN

Let's get going and configure an IPsec VPN!

  1. Log in as root on the device console. Start the CLI, and enter configuration mode.
  2. Configure the st0 tunnel interface. An unnumbered tunnel is supported in this scenario. Here, we opt to number the tunnel end points. One benefit of numbering the tunnel is to permit ping testing of the tunnel end points to help debug any connectivity issues.
  3. Define a static route to direct traffic destined to into the IPsec tunnel.
  4. Configure the IKE parameters. The local-identity and remote-identity parameters are important for supporting a dynamic IPsec VPN. When static IP addresses are used, you define a local and remote IKE gateway specifying those static IP addresses.

    By the way, we'll be configuring security stuff for a bit so you park yourself at the [edit security] hierarchy:


    To support a dynamic IPsec VPN, the remote end must have the set security ike gateway ike-gw dynamic hostname <name> statement configured in the IKE proposal. When the remote end initiates a connection, the name is used to match the IKE proposal rather than an IP. This method is used when IP addresses can change due to dynamic assignment.

  5. Configure the IPsec tunnel parameters.
  6. Adjust the security policies to create a vpn zone, and to permit traffic to flow from the trust zone to the vpn zone. We configure the vpn zone to allow host-bound ping for use in debugging, given we opted to number our IPsec tunnel. In this step, you also place the IPsec tunnel interface in the vpn zone.

    In this example, we keep it simple and match on any source or destination IP address. We rely on the static route to only direct traffic destined to the remote site into the tunnel. For better security, consider defining address book entries for the local branch and the remote subnets. With address book entries defined for the two subnets, you match on source-address <source_name> and destination-address <dest_name> in your security policy. Including the source and destination subnets in your policy makes it that much more explicit as to the traffic that is able to use the tunnel.

  7. Hang in there, you're almost done. Recall that IKE is used to negotiate the shared keys for securing the IPsec tunnel. IKE messages must be sent and received over the WAN interface to establish the tunnel on the st0 interface.

    You'll need to modify the local host services that are accessible over the untrust WAN interface to include IKE.

That's it. You've configured the IPsec route-based VPN at the branch location. Be sure to commit your changes.


Let's display the result of your IPsec route-based VPN configuration. We omit parts of the default configuration for brevity.

Be sure to commit your configuration to activate the changes on the branch SRX.

Quick Configurations

Quick Configuration: Branch Office

To quickly configure an IPsec VPN, use the following set statements. Simply edit the configuration statements as needed for your environment, and paste them into your SRX.

Here's the IPsec VPN configuration for the branch SRX:

Quick Configuration: Remote Location

For completeness, here's the matching IPsec VPN Quick Configuration for the remote site. It's similar to the one we detailed for the branch. The key differences are that we use the dynamic hostname statement, and a different destination for the static route used to steer traffic into the tunnel. We allow ping in the vpn zone at the remote site. As a result, you ping both the tunnel endpoints (we numbered our tunnel), as well as the loopback interface. The loopback interface at the remote site represents the subnet. The remote site's lo0 interface is placed in the vpn zone.

Be sure to commit the changes. In the next section, we'll show you how to verify that your IPsec tunnel works correctly.