Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Route-Based IPsec VPNs

 

A route-based VPN is a configuration in which an IPsec VPN tunnel created between two end points is referenced by a route that determines which traffic is sent through the tunnel based on a destination IP address.

Understanding Route-Based IPsec VPNs

With route-based VPNs, you can configure dozens of security policies to regulate traffic flowing through a single VPN tunnel between two sites, and there is just one set of IKE and IPsec SAs at work. Unlike policy-based VPNs, for route-based VPNs, a policy refers to a destination address, not a VPN tunnel. When Junos OS looks up a route to find the interface to use to send traffic to the packet’s destination address, it finds a route through a secure tunnel interface (st0.x). The tunnel interface is bound to a specific VPN tunnel, and the traffic is routed to the tunnel if the policy action is permit.

Note

A secure tunnel (st0) interface supports only one IPv4 address and one IPv6 address at the same time. This applies to all route-based VPNs. The disable option is not supported on st0 interfaces.

Examples of where route-based VPNs can be used:

  • There are overlapping subnets or IP addresses between the two LANs.

  • A hub-and-spoke VPN topology is used in the network, and spoke-to-spoke traffic is required.

  • Primary and backup VPNs are required.

  • A dynamic routing protocol (for example, OSPF, RIP, or BGP) is running across the VPN.

    Note

    Configuring RIP demand circuits over point-to-multipoint VPN interfaces is not supported.

We recommend that you use route-based VPN when you want to configure VPN between multiple remote sites. Route-based VPN allows for routing between the spokes between multiple remote sites; it is easier to configure, monitor, and troubleshoot.

Example: Configuring a Route-Based VPN

This example shows how to configure a route-based IPsec VPN to allow data to be securely transferred between a branch office and the corporate office.

Requirements

This example uses the following hardware:

  • Any SRX Series device

  • SSG140 device

Before you begin, read IPsec VPN Overview.

Overview

In this example, you configure a route-based VPN for a branch office in Chicago, because you want to conserve tunnel resources but still get granular restrictions on VPN traffic. Users in the Chicago office will use the VPN to connect to their corporate headquarters in Sunnyvale, California.

Figure 1 shows an example of a route-based VPN topology. In this topology, the SRX Series device is located in Sunnyvale, and an SSG Series device (or a third-party device) is located in Chicago.

Figure 1: Route-Based VPN Topology
 Route-Based VPN Topology

In this example, you configure interfaces, an IPv4 default route, security zones, and address books. Then you configure IKE, IPsec, security policy, and TCP-MSS parameters. See Table 1 through Table 5 for specific configuration parameters used in this example.

Table 1: Interface, Static Route, Security Zone, and Address Book Information

Feature

Name

Configuration Parameters

Interfaces

ge-0/0/0.0

192.0.2.1/24

 

ge-0/0/3.0

10.1.1.2/30

 

st0.0 (tunnel interface)

10.10.11.10/24

Static routes

0.0.0.0/0 (default route)

The next hop is st0.0.

Security zones

trust

  • All system services are allowed.

  • The ge-0/0/0.0 interface is bound to this zone.

 

untrust

  • IKE is the only allowed system service.

  • The ge-0/0/3.0 interface is bound to this zone.

 

vpn

The st0.0 interface is bound to this zone.

   
   

Table 2: IKE Configuration Parameters

Feature

Name

Configuration Parameters

Proposal

ike-proposal

  • Authentication method: rsa-signatures

  • Diffie-Hellman group: group14

  • Authentication algorithm: sha256

  • Encryption algorithm: aes-256-cbc

Policy

ike-policy

  • Mode: main

  • Proposal reference: ike-policy

  • IKE policy authentication method: rsa-signatures

Gateway

gw-sunnyvale

  • IKE policy reference: ike-policy

  • External interface: ge-0/0/3.0

  • Gateway address: 10.2.2.2

Table 3: IPsec Configuration Parameters

Feature

Name

Configuration Parameters

Proposal

ipsec_prop

  • Protocol: esp

  • Authentication algorithm: hmac-sha-256

  • Encryption algorithm: aes-256-cbc

Policy

ipsec_pol

  • Proposal reference: ipsec_prop

  • PFS: Diffie-Hellman group2

VPN

ipsec_vpn1

  • IKE gateway reference: gw-sunnyvale

  • IPsec policy reference: ipsec_pol

  • Bind to interface: st0.0

Table 4: Security Policy Configuration Parameters

Purpose

Name

Configuration Parameters

The security policy permits traffic from the trust zone to the vpn zone.

vpn

  • Match criteria:

    • source-address sunnyvale

    • destination-address chicago

    • application any

  • Action: permit

The security policy permits traffic from the vpn zone to the trust zone.

vpn

  • Match criteria:

    • source-address chicago

    • destination-address sunnyvale

    • application any

  • Action: permit

Table 5: TCP-MSS Configuration Parameters

Purpose

Configuration Parameters

TCP-MSS is negotiated as part of the TCP three-way handshake and limits the maximum size of a TCP segment to better fit the MTU limits on a network. For VPN traffic, the IPsec encapsulation overhead, along with the IP and frame overhead, can cause the resulting ESP packet to exceed the MTU of the physical interface, which causes fragmentation. Fragmentation increases bandwidth and device resources.

Note: We recommend a value of 1350 as the starting point for most Ethernet-based networks with an MTU of 1500 or greater. You might need to experiment with different TCP-MSS values to obtain optimal performance. For example, you might need to change the value if any device in the path has a lower MTU, or if there is any additional overhead such as PPP or Frame Relay.

MSS value: 1350

Configuration

Configuring Basic Network and Security Zone Information

CLI Quick Configuration

To quickly configure this section of the example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure interface, static route, security zone, and address book information:

  1. Configure Ethernet interface information.
  2. Configure static route information.
  3. Configure the untrust security zone.
  4. Specify allowed system services for the untrust security zone.
  5. Assign an interface to the security zone.
  6. Specify allowed system services for the security zone.
  7. Configure the trust security zone.
  8. Assign an interface to the trust security zone.
  9. Specify allowed system services for the trust security zone.
  10. Configure the vpn security zone.
  11. Assign an interface to the security zone.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show routing-options, show security zones, and show security address-book commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

If you are done configuring the device, enter commit from configuration mode.

Configuring IKE

CLI Quick Configuration

To quickly configure this section of the example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure IKE:

  1. Create the IKE proposal.
  2. Define the IKE proposal authentication method.
  3. Define the IKE proposal Diffie-Hellman group.
  4. Define the IKE proposal authentication algorithm.
  5. Define the IKE proposal encryption algorithm.
  6. Create an IKE policy.
  7. Set the IKE policy mode.
  8. Specify a reference to the IKE proposal.
  9. Define the IKE policy authentication method.
  10. Create an IKE gateway and define its external interface.
  11. Define the IKE policy reference.
  12. Define the IKE gateway address.
  13. Define the IKE gateway version.

Results

From configuration mode, confirm your configuration by entering the show security ike command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

If you are done configuring the device, enter commit from configuration mode.

Configuring IPsec

CLI Quick Configuration

To quickly configure this section of the example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure IPsec:

  1. Enable IPsec trace options.
  2. Create an IPsec proposal.
  3. Specify the IPsec proposal protocol.
  4. Specify the IPsec proposal authentication algorithm.
  5. Specify the IPsec proposal encryption algorithm.
  6. Create the IPsec policy.
  7. Specify the IPsec proposal reference.
  8. Specify the IKE gateway.
  9. Specify the IPsec policy.
  10. Specify the interface to bind.

Results

From configuration mode, confirm your configuration by entering the show security ipsec command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

If you are done configuring the device, enter commit from configuration mode.

Configuring Security Policies

CLI Quick Configuration

To quickly configure this section of the example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure security policies:

  1. Create the security policy to permit traffic from the trust zone to the vpn zone.
  2. Create the security policy to permit traffic from the vpn zone to the trust zone.

Results

From configuration mode, confirm your configuration by entering the show security policies command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

If you are done configuring the device, enter commit from configuration mode.

Configuring TCP-MSS

CLI Quick Configuration

To quickly configure this section of the example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure TCP-MSS information:

  1. Configure TCP-MSS information.

Results

From configuration mode, confirm your configuration by entering the show security flow command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

If you are done configuring the device, enter commit from configuration mode.

Configuring the SSG Series Device

CLI Quick Configuration

For reference, the configuration for the SSG Series device is provided. For information about configuring SSG Series devices, see the Concepts and Examples ScreenOS Reference Guide, which is located at http://www.juniper.net/techpubs.

To quickly configure this section of the example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

Verification

To confirm that the configuration is working properly, perform these tasks:

Verifying the IKE Status

Purpose

Verify the IKE status.

Action

Note

Before starting the verification process, you need to send traffic from a host in the 192.0.2.10/24 network to a host in the 198.51.100.10/24 network. For route-based VPNs, traffic can be initiated by the SRX Series device through the tunnel. We recommend that when testing IPsec tunnels, test traffic be sent from a separate device on one side of the VPN to a second device on the other side of the VPN. For example, initiate a ping from 192.0.2.10 to 198.51.100.10.

From operational mode, enter the show security ike security-associations command. After obtaining an index number from the command, use the show security ike security-associations index index_number detail command.

user@host> show security ike security-associations
user@host> show security ike security-associations index 1 detail

Meaning

The show security ike security-associations command lists all active IKE SAs. If no SAs are listed, there was a problem with IKE establishment. Check the IKE policy parameters and external interface settings in your configuration.

If SAs are listed, review the following information:

  • Index—This value is unique for each IKE SA, which you can use in the show security ike security-associations index detail command to get more information about the SA.

  • Remote Address—Verify that the remote IP address is correct.

  • State

    • UP—The IKE SA has been established.

    • DOWN—There was a problem establishing the IKE SA.

  • Mode—Verify that the correct mode is being used.

Verify that the following are correct in your configuration:

  • External interfaces (the interface must be the one that receives IKE packets)

  • IKE policy parameters

  • Preshared key information

  • Proposal parameters (must match on both peers)

The show security ike security-associations index 1 detail command lists additional information about the security association with an index number of 1:

  • Authentication and encryption algorithms used

  • lifetime

  • Traffic statistics (can be used to verify that traffic is flowing properly in both directions)

  • Role information

    Note

    Troubleshooting is best performed on the peer using the responder role.

  • Initiator and responder information

  • Number of IPsec SAs created

  • Number of negotiations in progress

Verifying the IPsec Status

Purpose

Verify the IPsec status.

Action

From operational mode, enter the show security ipsec security-associations command. After obtaining an index number from the command, use the show security ipsec security-associations index index_number detail command.

user@host> show security ipsec security-associations
user@host> show security ipsec security-associations index 16384 detail

Meaning

The output from the show security ipsec security-associations command lists the following information:

  • The ID number is 16384. Use this value with the show security ipsec security-associations index command to get more information about this particular SA.

  • There is one IPsec SA pair using port 500, which indicates that no NAT-traversal is implemented. (NAT-traversal uses port 4500 or another random high-number port.)

  • The SPIs, lifetime (in seconds), and usage limits (or lifesize in KB) are shown for both directions. The 3363/ unlim value indicates that the lifetime expires in 3363 seconds, and that no lifesize has been specified, which indicates that it is unlimited. Lifetime can differ from lifetime, as IPsec is not dependent on IKE after the VPN is up.

  • VPN monitoring is not enabled for this SA, as indicated by a hyphen in the Mon column. If VPN monitoring is enabled, U indicates that monitoring is up, and D indicates that monitoring is down.

  • The virtual system (vsys) is the root system, and it always lists 0.

The output from the show security ipsec security-associations index 16384 detail command lists the following information:

  • The local identity and remote identity make up the proxy ID for the SA.

    A proxy ID mismatch is one of the most common causes for a IPsec failure. If no IPsec SA is listed, confirm that IPsec proposals, including the proxy ID settings, are correct for both peers. For route-based VPNs, the default proxy ID is local=0.0.0.0/0, remote=0.0.0.0/0, and service=any. Issues can occur with multiple route-based VPNs from the same peer IP. In this case, a unique proxy ID for each IPsec SA must be specified. For some third-party vendors, the proxy ID must be manually entered to match.

  • Another common reason for IPsec failure is not specifying the ST interface binding. If IPsec cannot complete, check the kmd log or set trace options.

Reviewing Statistics and Errors for an IPsec Security Association

Purpose

Review ESP and authentication header counters and errors for an IPsec security association.

Action

From operational mode, enter the show security ipsec statistics index index_number command, using the index number of the VPN for which you want to see statistics.

user@host> show security ipsec statistics index 16384

You can also use the show security ipsec statistics command to review statistics and errors for all SAs.

To clear all IPsec statistics, use the clear security ipsec statistics command.

Meaning

If you see packet loss issues across a VPN, you can run the show security ipsec statistics or show security ipsec statistics detail command several times to confirm that the encrypted and decrypted packet counters are incrementing. You should also check whether the other error counters are incrementing.

Testing Traffic Flow Across the VPN

Purpose

Verify the traffic flow across the VPN.

Action

You can use the ping command from the SRX Series device to test traffic flow to a remote host PC. Make sure that you specify the source interface so that the route lookup is correct and the appropriate security zones are referenced during policy lookup.

From operational mode, enter the ping command.

ssg-> ping 10.10.11.10 interface ge-0/0/0 count 5

You can also use the ping command from the SSG Series device.

user@host> ping 198.51.100.1 from ethernet0/6

Meaning

If the ping command fails from the SRX Series or SSG Series device, there might be a problem with the routing, security policies, end host, or encryption and decryption of ESP packets.

Understanding CoS Support on st0 Interfaces

Starting with Junos OS Release 15.1X49-D60 and Junos OS Release 17.3R1, class of service (CoS) features such as classifier, policer, queuing, scheduling, shaping, rewriting markers, and virtual channels can now be configured on the secure tunnel interface (st0) for point-to-point VPNs.

The st0 tunnel interface is an internal interface that can be used by route-based VPNs to route cleartext traffics to an IPsec VPN tunnel. The following CoS features are supported on the st0 interface on all available SRX Series devices and vSRX2.0:

  • Classifiers

  • Policers

  • Queuing, scheduling, and shaping

  • Rewrite markers

  • Virtual channels

Note

Starting with Junos OS Release 15.1X49-D70 and Junos OS Release 17.3R1, support for queuing, scheduling, shaping, and virtual channels is added to the st0 interface for SRX5400, SRX5600, and SRX5800 devices. Support for all the listed CoS features is added for the st0 interface for SRX1500, SRX4100, and SRX4200 devices. Starting with Junos OS Release 17.4R1, support for listed CoS features is added for the st0 interface for SRX4600 devices.

Limitations of CoS support on VPN st0 interfaces

The following limitations apply to CoS support on VPN st0 interfaces:

  • The maximum number for software queues is 2048. If the number of st0 interfaces exceeds 2048, not enough software queues can be created for all the st0 interfaces.

  • Only route-based VPNs can apply CoS features on st0 interfaces. Table 6 describes the st0 CoS feature support for different types of VPNs.

    Table 6: CoS Feature Support for VPN

    Classifier FeaturesSite-to-Site VPN (P2P)AutoVPN (P2P)Site-to-Site/Auto VPN /AD-VPN (P2MP)

    Classifiers, policers, and rewriting markers

    Supported

    Supported

    Supported

    Queueing, scheduling, and shaping based on st0 logical interfaces

    Supported

    Not supported

    Not supported

    Queueing, scheduling, and shaping based on virtual channels

    Supported

    Supported

    Supported

  • On SRX300, SRX320, SRX340, SRX345, and SRX550HM devices, one st0 logical interface can bind to multiple VPN tunnels. The eight queues for the st0 logical interface cannot reroute the traffic to different tunnels, so pre-tunneling is not supported.

    Note

    The virtual channel feature can be used as a workaround on SRX300, SRX320, SRX340, SRX345, and SRX550HM devices.

  • When defining a CoS shaping rate on an st0 tunnel interface, consider the following restrictions:

    • The shaping rate on the tunnel interface must be less than that of the physical egress interface.

    • The shaping rate only measures the packet size that includes the inner Layer 3 cleartext packet with an ESP/AH header and an outer IP header encapsulation. The outer Layer 2 encapsulation added by the physical interface is not factored into the shaping rate measurement.

    • The CoS behavior works as expected when the physical interface carries the shaped GRE or IP-IP tunnel traffic only. If the physical interface carries other traffic, thereby lowering the available bandwidth for tunnel interface traffic, the CoS features do not work as expected.

  • On SRX550M, SRX5400, SRX5600, and SRX5800 devices, bandwidth limit and burst size limit values in a policer configuration are a per-SPU, not per-system limitation. This is the same policer behavior as on the physical interface.

Related Documentation

Release History Table
Release
Description
Starting with Junos OS Release 17.4R1, support for listed CoS features is added for the st0 interface for SRX4600 devices.
Starting with Junos OS Release 15.1X49-D70 and Junos OS Release 17.3R1, support for queuing, scheduling, shaping, and virtual channels is added to the st0 interface for SRX5400, SRX5600, and SRX5800 devices. Support for all the listed CoS features is added for the st0 interface for SRX1500, SRX4100, and SRX4200 devices.
Starting with Junos OS Release 15.1X49-D60 and Junos OS Release 17.3R1, class of service (CoS) features such as classifier, policer, queuing, scheduling, shaping, rewriting markers, and virtual channels can now be configured on the secure tunnel interface (st0) for point-to-point VPNs.