Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

CoS-Based IPsec VPNs

Read this topic to understand CoS-based IPsec VPNs and how you can configure the feature in Junos OS devices.

We support Junos class of service (CoS) feature that can provide multiple classes of service for VPNs. On the device, you can configure multiple forwarding classes for transmitting packets, define which packets are placed into each output queue, schedule the transmission service level for each queue, and manage congestion. IKE negotiates an IPsec tunnel for every Forwarding Class (FC) and each FC is mapped to a set of Differentiated Services Code Point (DSCP) values.

Understand CoS-Based IPsec VPNs with Multiple IPsec SAs

In this topic, you'll learn about concepts that are related to class of service (CoS) based IPsec VPNs.

Overview

The CoS forwarding classes (FCs) that are configured on the Junos OS device can be mapped to IPsec security associations (SAs). Packets for each FC are mapped to a different IPsec SA, thus providing for CoS treatment on the local device and on intermediate routers. This feature is proprietary to Juniper Networks and works with supported Junos OS devices and Junos OS releases. The VPN peer device must be a Junos OS device that supports this feature or any other product that supports the same functionality in the same way as the Junos OS device.

Benefits

  • Helps you ensure different data streams, with each tunnel using a separate set of security associations.

  • Helps you to facilitate the IPsec VPN deployments where differentiated traffic is required, such as voice-over-IP.

Map FCs to IPsec SAs

You can configure up to 8 forwarding classes (FC) for a VPN with the multi-sa forwarding-classes configuration statement at the [edit security ipsec vpn vpn-name] hierarchy level. The number of IPsec SAs negotiated with a peer gateway is based on the number of FCs configured for the VPN. The mapping of FCs to IPsec SAs applies to all traffic selectors that are configured for the VPN.

All IPsec SAs created for the FCs of a specific VPN are represented by the same tunnel ID. Tunnel-related events consider the state and statistics of all IPsec SAs. All IPsec SAs related to a tunnel are anchored to the same SPU or the same thread ID on the Junos OS device.

The order of FC configuration need not be same in both the peers. So Junos OS doesn't guarantee the same IPsec SA pair for the same FC on both ends of the VPN tunnel.

IPsec SA Negotiation

When you configure multiple FCs for a VPN, a unique IPsec SA is negotiated with the peer for each FC. In addition, a default IPsec SA is negotiated to send packets that do not match a configured FC. The default IPsec is negotiated even if the VPN peer device is not configured for FCs or does not support FC to IPsec SA mapping. The default IPsec SA is the first IPsec SA to be negotiated and the last SA to be torn down.

Depending on the number of FCs configured, when IPsec SAs are in the process of negotiating, packets might arrive with an FC for which an IPsec SA has yet to be negotiated. Until an IPsec SA for a given FC is negotiated, the traffic is sent to the default IPsec SA. A packet with an FC that does not match any of the IPsec SAs is sent on the default IPsec SA.

Mapping of FCs to IPsec SAs is done on the local VPN gateway. The local and peer gateways might have FCs configured in a different order. Each peer gateway maps FCs in the order in which IPsec SA negotiations are completed. Thus, the local and peer gateways might have different FC to IPsec SA mappings. A gateway stops negotiating new IPsec SAs once the configured number of FCs is reached. A peer gateway might initiate more IPsec SAs than the number of FCs configured on the local gateway. In this case, the local gateway accepts the additional IPsec SA requests—up to 18 IPsec SAs. The local gateway uses the other IPsec SAs only for decrypting incoming IPsec traffic. If a packet is received with an FC that does not match any configured FC, the packet is sent on the default FC IPsec SA.

If a delete notification is received for the default IPsec SA from the peer device, only the default IPsec SA is deleted and the default IPsec SA is negotiated newly. During this time, traffic which might go on default IPsec SA is be dropped. The VPN tunnel is brought down only if the default IPsec SA is the last SA.

If the establish-tunnels immediately option is configured and committed for the VPN, the Junos OS device negotiates IPsec SA without waiting for traffic to arrive. If negotiations do not complete for an IPsec SA for a configured FC, negotiations are retried every 60 seconds.

If the establish-tunnels on-traffic option is configured for the VPN, the Junos OS device negotiates IPsec SAs when the first data packet arrives; the FC for the first packet does not matter. With either option, the default IPsec SA is negotiated first, then each IPsec SA is negotiated one by one in the order in which the FCs are configured on the device.

Rekey

When using multiple SAs with Differentiated Services Code Point (DSCP) traffic steering with traffic selectors, the following behavior occurs during rekey—When the traffic selectors perform rekeying, if one or more of the traffic selectors are unable to rekey for any reason, the specific SA is brought down when the lifetime expires. In this case, traffic that use to match the specific SA is sent through the default traffic selector instead.

Add or Delete FCs from a VPN

When FCs are added or deleted from a VPN, the IKE and IPsec SAs for the VPN are brought up or down and restarts the negotiations. The clear security ipsec security-associations command clears all IPsec SAs.

Dead Peer Detection (DPD)

When DPD is configured with this feature, the optimized mode sends probes only when there is outgoing traffic and no incoming traffic on any of the IPsec SA. While the probe-idle mode sends probes only when there is no outgoing and no incoming traffic on any of the IPsec SAs. VPN monitoring is not supported with DPD feature.

Commands

The show security ipsec sa details index tunnel-id command displays all IPsec SA details including the FC name.

The show security ipsec stats index tunnel-id command displays statistics for each FC.

Supported VPN Features

The following VPN features are supported with CoS-based IPsec VPNs:

  • Route-based site-to-site VPNs. Policy-based VPNs are not supported.

  • Traffic selectors.

  • AutoVPN.

  • Auto Discovery VPNs (ADVPNs).

  • IKEv2. IKEv1 is not supported.

  • Dead peer detection (DPD). VPN monitoring is not supported.

  • PMI is not supported.

Understand Traffic Selectors and CoS-Based IPsec VPNs

A traffic selector is an agreement between the IKE peers to permit traffic through a VPN tunnel if the traffic matches a specified pair of local and remote addresses. Only traffic that conforms to a traffic selector is permitted through the associated security association (SA).

The CoS-based IPsec VPN feature supports the following scenarios

  • One or multiple traffic selectors in a route-based site-to-site VPN with the same FCs.

  • Multiple traffic selectors, with different FCs for each traffic selector. This scenario requires separate VPN configurations.

This topic describes the VPN configurations and the IPsec SA that are negotiated for each scenario.

In the following scenarios, three FCs are configured on the Junos OS device:

In the first scenario, VPN vpn1 is configured with a single traffic selector ts1 and the three FCs. In this configuration, four IPsec SAs are negotiated for traffic selector ts1—one for the default IPsec SA and three for the IPsec SAs that are mapped to FCs.

In the second scenario, VPN vpn1 is configured with two traffic selectors ts1 and ts2 and the three FCs. In this configuration, four IPsec SAs are negotiated for traffic selector ts1 and four IPsec SAs are negotiated for traffic selector ts2. For each traffic selector, there is one IPsec SA negotiated for the default IPsec SA and three IPsec SAs negotiated for the IPsec SAs that are mapped to FCs.

In the third scenario, traffic selectors ts1 and ts2 support different sets of FCs. The traffic selectors need to be configured for different VPNs. In this configuration, four IPsec SAs are negotiated for traffic selector ts1 in VPN vpn1—one for the default IPsec SA and three for the IPsec SAs that are mapped to FCs.

Example: Configure CoS-Based IPsec VPNs

This example shows how to configure a CoS-based IPsec VPNs with multiple IPsec SAs to allow packets mapping for each forwarding class to a different IPsec SA, thus providing for CoS treatment on the local device and on intermediate routers.

This feature is proprietary to Juniper Networks and only works with supported Junos OS devices and Junos OS releases. The VPN peer device must be an Junos OS device that supports this feature.

Requirements

This example uses the following hardware:

  • Junos OS device such as the SRX Series Firewall

Before you begin:

  • Understand how Class of service (CoS) forwarding classes (FCs) configured on the SRX Series Firewall can be mapped to IPsec security associations (SAs). See Understanding CoS-Based IPsec VPNs with Multiple IPsec SAs.

  • Understand Traffic Selectors and CoS-Based IPsec VPNs. See Understanding Traffic Selectors and CoS-Based IPsec VPNs.

Overview

In this example, you configure an IPsec route-based VPN for a branch office in Chicago, because you do not need to conserve tunnel resources or configure many security policies to filter traffic through the tunnel. Users in the Chicago office will use the VPN to connect to their corporate headquarters in Sunnyvale.

Figure 1 shows an example of an IPsec route-based VPN topology. In this topology, one SRX Series Firewall is located in Sunnyvale, and one SRX Series Firewall is located in Chicago.

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

In this example, you configure interfaces, an IPv4 default route and security zones. Then you configure IKE, IPsec, a security policy, and CoS parameters. See Table 1 through Table 4.

Table 1: Interface, Static Route, and Security Zone 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

  • All system services are allowed.

  • 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: sha-256

  • Encryption algorithm: aes-256-cbc

Policy

ike-policy

  • Mode: main

  • Proposal reference: ike-proposal

  • 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

VPN

ipsec_vpn1

  • IKE gateway reference: gw-chicago

  • IPsec policy reference: ipsec_pol

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

Configuration

Configuring Basic Network and Security Zone Information

CLI Quick Configuration

To quickly configure this 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, and security zone 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, and show security zones 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 CoS

CLI Quick Configuration

To quickly configure this 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 CoS:

  1. Configure behavior aggregate classifiers for DiffServ CoS.

  2. Configure a best-effort forwarding class classifier.

  3. Define the DSCP value to be assigned to the forwarding class.

  4. Define eight forwarding classes (queue names) for the eight queues.

  5. Configure classifiers on the ingress (ge) interfaces.

  6. Apply the scheduler map to the ge interface.

  7. Configure the scheduler map to associate schedulers with defined forwarding classes.

  8. Define the schedulers with priority and transmit rates.

Results

From configuration mode, confirm your configuration by entering the show class-of-service 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 IKE

CLI Quick Configuration

To quickly configure this 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 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. Specify the lifetime (in seconds) of an IPsec security association (SA).

  7. Create the IPsec policy.

  8. Specify the IPsec proposal reference.

  9. Specify the interface to bind.

  10. Configure the forwarding class to the multiple IPsec SA.

  11. Specify the IKE gateway.

  12. Specify the IPsec policies.

  13. Specify that the tunnel be brought up immediately to negotiate IPsec SA when the first data packet arrives to be sent.

  14. Configure local IP addresses for a traffic selector.

  15. Configure remote IP addresses for a traffic selector.

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 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.

Enable security policies trace options for troubleshooting the policy-related issues.

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.

Verification

Confirm that the configuration is working properly.

Verifying IPsec Security Associations

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 131073 detail and show security ipsec statistics index 131073 commands.

For brevity, the show command outputs does not display all the values of the configuration. Only a subset of the configuration is displayed. Rest of the configuration on the system has been replaced with ellipses (...).

Meaning

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

  • The ID number is 131073. 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.

  • The SPIs, lifetime (in seconds), and usage limits (or lifesize in KB) are shown for both directions. The 1949/ unlim value indicates that the Phase lifetime expires in 1949 seconds, and that no lifesize has been specified, which indicates that it is unlimited.

  • 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 show security ike security-associations index 131073 detail command lists additional information about the SA with an index number of 131073:

  • 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 Phase failure. If no IPsec SA is listed, confirm that Phase proposals, including the proxy ID settings, are correct for both peers.

  • Displays all the child SA details including forwarding class name.

The show security ipsec statistics index 131073 command lists statistics for each forwarding class name.

  • An error value of zero in the output indicates a normal condition.

  • We recommend running this command multiple times to observe any packet loss issues across a VPN. Output from this command also displays the statistics for encrypted and decrypted packet counters, error counters, and so on.

  • You must enable security flow trace options to investigate which ESP packets are experiencing errors and why.

Understand 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 Firewalls and vSRX2.0:

  • Classifiers

  • Policers

  • Queuing, scheduling, and shaping

  • Rewrite markers

  • Virtual channels

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 5 describes the st0 CoS feature support for different types of VPNs.

    Table 5: CoS Feature Support for VPN
    Classifier Features Site-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.

    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.

Change History Table

Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.

Release
Description
24.4R1
Starting with Junos OS Release 24.4R1, support for CoS-based IPsec VPNs with the iked process is added.
17.4R1
Starting with Junos OS Release 17.4R1, support for listed CoS features is added for the st0 interface for SRX4600 devices.
15.1X49-D70
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.
15.1X49-D60
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.