Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Traffic Selectors in Route-Based VPNs

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

Understanding Traffic Selectors in Route-Based VPNs

A traffic selector is an agreement between IKE peers to permit traffic through a tunnel if the traffic matches a specified pair of local and remote addresses. With this feature, you can define a traffic selector within a specific route-based VPN, which can result in multiple Phase 2 IPsec security associations (SAs). Only traffic that conforms to a traffic selector is permitted through the associated SA.

Starting with Junos OS Release 12.1X46-D10 and Junos OS Release 17.3R1, traffic selectors can be configured with IKEv1 site-to-site VPNs. Starting with Junos OS Release 15.1X49-D100, traffic selectors can be configured with IKEv2 site-to-site VPNs.

Traffic Selector Configuration

To configure a traffic selector, use the traffic-selector configuration statement at the [edit security ipsec vpn vpn-name] hierarchy level. The traffic selector is defined with the mandatory local-ip ip-address/netmask and remote-ip ip-address/netmask statements. The CLI operational command show security ipsec security-association detail displays traffic selector information for SAs. The show security ipsec security-association traffic-selector traffic-selector-name CLI command displays information for a specified traffic selector.

For a given traffic selector, a single address and netmask is specified for the local and remote addresses. Traffic selectors can be configured with IPv4 or IPv6 addresses. Address books cannot be used to specify local or remote addresses.

Multiple traffic selectors can be configured for the same VPN. A maximum of 200 traffic selectors can be configured for each VPN. Traffic selectors can be used with IPv4-in-IPv4, IPv4-in-IPv6, IPv6-in-IPv6, or IPv6-in-IPv4 tunnel modes.

Below features are not supported with traffic selectors:

  • VPN monitoring

  • Different address families configured for the local and remote IP addresses in a traffic selector

  • A remote address of 0.0.0.0/0 (IPv4) or 0::0 (IPv6) for site-to-site VPNs

    Starting with Junos OS Release 15.1X49-D140, on all SRX Series Firewalls and vSRX Virtual Firewall instances, when you configure the traffic-selector with a remote address of 0::0 (IPv6), the following “error: configuration check-out failed” message is displayed when performing the commit and the configuration checkout fails.

  • Point-to-multipoint interfaces

  • Dynamic routing protocols configured on st0 interfaces

When there are multiple traffic selectors configured for a route-based VPN, clear traffic may enter a VPN tunnel without matching a traffic selector if the IKE gateway external interface is moved to another virtual router (VR). The software does not handle the multiple asynchronous interface events generated when an IKE gateway external interface is moved to another VR. As a workaround, first deactivate the IPsec VPN tunnel and commit the configuration without that tunnel before moving the IKE gateway external interface to another VR.

From Junos OS Release 21.1R1 onwards, you can configure multiple sets of local IP prefix, remote IP prefix, source port range, destination port range, and protocol for traffic selection. This means, multiple sets of IP address ranges, port ranges, and protocols can be part of same traffic selector as defined in RFC 7296. When you configure multiple traffic selectors, each traffic selector leads to a separate negotiation that results in the multiple IPsec tunnels. But, if you configure multiple terms under one traffic selector, this configuration results in single IPsec SA negotiation with multiple IP prefixes, ports, and protocols. See Traffic Selector.

Understanding Auto Route Insertion

Auto route insertion (ARI) automatically inserts a static route for the remote network and hosts protected by a remote tunnel endpoint. A route is created based on the remote IP address configured in the traffic-selector. In the case of traffic selectors, the configured remote address is inserted as a route in the routing instance associated with the st0 interface that is bound to the VPN.

Routing protocols and traffic selector configuration are mutually exclusive ways of steering traffic to a tunnel. ARI routes might conflict with routes that are populated through routing protocols. Therefore, you should not configure routing protocols on an st0 interface that is bound to a VPN on which traffic selectors are configured.

ARI is also known as reverse route insertion (RRI). ARI routes are inserted in the routing table as follows:

  • If the establish-tunnels immediately option is configured at the [edit security ipsec vpn vpn-name] hierarchy level, ARI routes are added after Phase 1 and Phase 2 negotiations are complete. Because a route is not added until SAs are established, a failed negotiation does not result in traffic being routed to a st0 interface that is down. An alternate or backup tunnel is used instead.

  • If the establish-tunnels immediately option is not configured at the [edit security ipsec vpn vpn-name] hierarchy level, ARI routes are added at configuration commit.

  • An ARI route is not added if the configured or negotiated remote address in a traffic selector is 0.0.0.0/0 or 0::0.

The preference for the static ARI route is 5. This value is necessary to avoid conflict with similar routes that might be added by a routing protocol process. There is no configuration of the metric for the static ARI route.

The static ARI route cannot be leaked to other routing instances using the rib-groups configuration. Use the import-policy configuration to leak static ARI routes.

Understanding Traffic Selectors and Overlapping IP Addresses

This section discusses overlapping IP addresses in traffic selector configurations.

Overlapping IP Addresses in Different VPNs Bound to the Same st0 Interface

This scenario is not supported with traffic selectors. Traffic selectors cannot be configured on different VPNs that are bound to the same point-to-multipoint st0 interface, as shown in the following example:

Overlapping IP Addresses in the Same VPN Bound to the Same st0 Interface

When overlapping IP addresses are configured for multiple traffic selectors in the same VPN, the first configured traffic selector that matches the packet determines the tunnel used for packet encryption.

In the following example, four traffic selectors (ts-1, ts-2, ts-3, and ts-4) are configured for the VPN (vpn-1), which is bound to the point-to-point st0.1 interface:

A packet with a source address 192.168.5.5 and a destination address 10.1.5.10 matches traffic selectors ts-1 and ts-2. However, traffic selector ts-1 is the first configured match and the tunnel associated with ts-1 is used for packet encryption.

A packet with a source address 172.16.5.5 and a destination address 10.2.5.10 matches the traffic selectors ts-3 and ts-4. However, traffic selector ts-3 is the first configured match and the tunnel associated with traffic selector ts-3 is used for packet encryption.

Overlapping IP Addresses in Different VPNs Bound to Different st0 Interfaces

When overlapping IP addresses are configured for multiple traffic selectors in different VPNs that are bound to different point-to-point st0 interfaces, an st0 interface is first selected by the longest prefix match for a given packet. Within the VPN that is bound to the selected st0 interface, the traffic selector is then selected based on the first configured match for the packet.

In the following example, a traffic selector is configured in each of two VPNs. The traffic selectors are configured with the same local subnetwork but different remote subnetworks.

Different remote subnetworks are configured in each traffic selector, therefore two different routes are added to the routing table. Route lookup uses the st0 interface bound to the appropriate VPN.

In the following example, a traffic selector is configured in each of two VPNs. The traffic selectors are configured with different remote subnetworks. The same local subnetwork is configured for each traffic selector, but different netmask values are specified.

A different remote subnetwork is configured in each traffic selector, therefore two different routes are added to the routing table. Route lookup uses the st0 interface bound to the appropriate VPN.

In the following example, traffic selectors are configured in each of two VPNs. The traffic selectors are configured with different local and remote subnetworks.

In this case, the traffic selectors do not overlap. The remote subnetworks configured in the traffic selectors are different, therefore two different routes are added to the routing table. Route lookup uses the st0 interface bound to the appropriate VPN.

In the following example, a traffic selector is configured in each of two VPNs. The traffic selectors are configured with the same local subnetwork. The same remote subnetwork is configured for each traffic selector, but different netmask values are specified.

Note that the remote-ip configured for ts-1 is 10.1.1.0/24 while the remote-ip configured for ts-2 is 10.1.0.0/16. For a packet destined to 10.1.1.1, route lookup selects the st0.1 interface as it has the longer prefix match. The packet is encrypted based on the tunnel corresponding to the st0.1 interface.

In some cases, valid packets can be dropped due to traffic selector traffic enforcement. In the following example, traffic selectors are configured in each of two VPNs. The traffic selectors are configured with different local subnetworks. The same remote subnetwork is configured for each traffic selector, but different netmask values are specified.

Two routes to 10.1.1.0 (10.1.1.0/24 via interface st0.1 and 10.1.0.0/16 via interface st0.2) are added to the routing table. A packet sent from source 172.16.1.1 to destination 10.1.1.1 matches the routing table entry for 10.1.1.0/24 via interface st0.1. However, the packet does not match the traffic specified by traffic selector ts-1 and is dropped.

If multiple traffic selectors are configured with the same remote subnetwork and netmask, equal cost routes are added to the routing table. This case is not supported with traffic selectors as the route chosen cannot be predicted.

Example: Configuring Traffic Selectors in a Route-Based VPN

This example shows how to configure traffic selectors for a route-based VPN.

Requirements

Before you begin,

Overview

This example configures traffic selectors to allow traffic to flow between subnetworks on SRX_A and subnetworks on SRX_B.

Table 1 shows the traffic selectors for this example. Traffic selectors are configured under Phase 2 options.

Table 1: Traffic Selector Configurations

SRX_A

SRX_B

Traffic Selector Name

Local IP

Remote IP

Traffic Selector Name

Local IP

Remote IP

TS1-ipv6

2001:db8:10::0/64

2001:db8:20::0/64

TS1-ipv6

2001:db8:20::0/64

2001:db8:10::0/64

TS2-ipv4

192.168.10.0/24

192.168.0.0/16

TS2-ipv4

192.168.0.0/16

192.168.10.0/24

Flow-based processing of IPv6 traffic must be enabled with the mode flow-based configuration option at the [edit security forwarding-options family inet6] hierarchy level.

Topology

In Figure 1, an IPv6 VPN tunnel carries both IPv4 and IPv6 traffic between the SRX_A and SRX_B devices. That is, the tunnel operates in both IPv4-in-IPv6 and IPv6-in-IPv6 tunnel modes.

Figure 1: Traffic Selector Configuration ExampleTraffic Selector Configuration Example

Configuration

Configuring SRX_A

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 traffic selectors:

  1. Configure the external interface.

  2. Configure the secure tunnel interface.

  3. Configure the internal interface.

  4. Configure Phase 1 options.

  5. Configure Phase 2 options.

  6. Enable IPv6 flow-based forwarding.

  7. Configure security zones and the security policy.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show security ike, show security ipsec, show security forwarding-options, show security zones, and show security policies 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 SRX_B

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 traffic selectors:

  1. Configure the external interface.

  2. Configure the secure tunnel interface.

  3. Configure the internal interfaces.

  4. Configure Phase 1 options.

  5. Configure Phase 2 options.

  6. Enable IPv6 flow-based forwarding.

  7. Configure security zones and the security policy.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show security ike, show security ipsec, show security forwarding-options, show security zones, and show security policies 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.

Verification

Confirm that the configuration is working properly.

The sample outputs shown are on SRX-A.

Verifying IPsec Phase 2 Status

Purpose

Verify the IPsec Phase 2 status.

Action

From operational mode, enter the show security ipsec security-associations command.

From operational mode, enter the show security ipsec security-associations detail command.

Meaning

The show security ipsec security-associations command lists all active IKE Phase 2 SAs. If no SAs are listed, there was a problem with Phase 2 establishment. Check the IKE policy parameters and external interface settings in your configuration. Phase 2 proposal parameters must match on the peer devices.

Verifying Traffic Selectors

Purpose

Verify negotiated traffic selectors on the secure tunnel interface.

Action

From operational mode, enter the show security ipsec traffic-selector st0.1 command.

Verifying Routes

Purpose

Verify active routes

Action

From operational mode, enter the show route command.

Meaning

The show route command lists active entries in the routing tables. Routes to the remote IP address configured in each traffic selector should be present with the correct st0 interface.

Release History Table
Release
Description
15.1X49-D140
Starting with Junos OS Release 15.1X49-D140, on all SRX Series Firewalls and vSRX Virtual Firewall instances, when you configure the traffic-selector with a remote address of 0::0 (IPv6), the following “error: configuration check-out failed” message is displayed when performing the commit and the configuration checkout fails.
15.1X49-D100
Starting with Junos OS Release 15.1X49-D100, traffic selectors can be configured with IKEv2 site-to-site VPNs.
12.1X46-D10
Starting with Junos OS Release 12.1X46-D10 and Junos OS Release 17.3R1, traffic selectors can be configured with IKEv1 site-to-site VPNs.