[ Contents] [ Prev] [ Next] [ Index] [ Report an Error]

Configuring IPsec Rules

To configure an IPsec rule, include the rule statement and specify a rule name at the [edit services ipsec-vpn] hierarchy level:

[edit services ipsec-vpn]
rule rule-name {
match-direction (input | output);
term term-name {
from {
destination-address address;
ipsec-inside-interface interface-name;
source-address address;
}
then {
backup-remote-gateway address;
clear-dont-fragment-bit;
dynamic {
ike-policy policy-name;
ipsec-policy policy-name;
}
initiate-dead-peer-detection;
manual {
direction (inbound | outbound | bidirectional) {
authentication {
algorithm (hmac-md5-96 | hmac-sha1-96);
key (ascii-text key | hexadecimal key);
}
auxiliary-spi spi-value;
encryption {
algorithm algorithm;
key (ascii-text key | hexadecimal key);
}
protocol (ah | bundle | esp);
spi spi-value;
}
}
no-anti-replay;
remote-gateway address;
syslog;
tunnel-mtu bytes;
}
}
}

Each IPsec rule consists of a set of terms, similar to a firewall filter. A term consists of the following:

The following sections explain how to configure the components of IPSec rules:

Configuring Match Direction for IPsec Rules

Each rule must include a match-direction statement that specifies whether the match is applied on the input or output side of the interface. To configure where the match is applied, include the match-direction (input | output) statement at the [edit services ipsec-vpn rule rule-name] hierarchy level:

[edit services ipsec-vpn rule rule-name]
match-direction (input | output);

The match direction is used with respect to the traffic flow through the AS or MultiServices PIC. When a packet is sent to the PIC, direction information is carried along with it.

With an interface service set, packet direction is determined by whether a packet is entering or leaving the interface on which the service set is applied.

With a next-hop service set, packet direction is determined by the interface used to route the packet to the AS or MultiServices PIC. If the inside interface is used to route the packet, the packet direction is input. If the outside interface is used to direct the packet to the PIC, the packet direction is output. For more information on inside and outside interfaces, see Configuring Service Sets to be Applied to Services Interfaces.

On the AS or MultiServices PIC, a flow lookup is performed. If no flow is found, rule processing is performed. All rules in the service set are considered. During rule processing, the packet direction is compared against rule directions. Only rules with direction information that match the packet direction are considered.

Configuring Match Conditions in IPsec Rules

To configure the match conditions in an IPsec rule, include the from statement at the [edit services ipsec-vpn rule rule-name term term-name] hierarchy level:

[edit services ipsec-vpn rule rule-name term term-name]
from {
destination-address address;
ipsec-inside-interface interface-name;
source-address address;
}

You can use either the source address or the destination address as a match condition, in the same way that you would configure a firewall filter; for more information, see the JUNOS Policy Framework Configuration Guide.

IPsec services support both IPv4 and IPv6 address formats. If you do not specifically configure either the source address or destination address, the default value 0.0.0.0/0 (IPv4 ANY) is used. To use IPv6 ANY (0::0/128) as either source or destination address, you must configure it explicitly.

For next-hop-style service sets only, the ipsec-inside-interface statement allows you to assign a logical interface to the tunnels established as a result of this match condition. The inside-service-interface statement that you can configure at the [edit services service-set name next-hop-service] hierarchy level allows you to specify .1 and .2 as inside and outside interfaces. However, you can configure multiple adaptive services logical interfaces with the service-domain inside statement and use one of them to configure the ipsec-inside-interface statement. For more information, see Configuring Service Sets to be Applied to Services Interfaces and Service Interface Configuration Guidelines.

The JUNOS software evaluates the criteria you configure in the from statement. If multiple link-type tunnels are configured within the same next-hop-style service set, the ipsec-inside-interface value enables the rule lookup module to distinguish a particular tunnel from other tunnels in case the source and destination addresses for all of them are 0.0.0.0/0 (ANY-ANY).

Note: When you configure the ipsec-inside-interface statement, interface-style service sets are not supported.

Configuring Actions in IPsec Rules

To configure actions in an IPsec rule, include the then statement at the [edit services ipsec-vpn rule rule-name term term-name] hierarchy level:

[edit services ipsec-vpn rule rule-name term term-name]
then {
backup-remote-gateway address;
clear-dont-fragment-bit;
dynamic {
ike-policy policy-name;
ipsec-policy policy-name;
}
initiate-dead-peer-detection;
manual {
direction (inbound | outbound | bidirectional) {
authentication {
algorithm (hmac-md5-96 | hmac-sha1-96);
key (ascii-text key | hexadecimal key);
}
auxiliary-spi spi-value;
encryption {
algorithm algorithm;
key (ascii-text key | hexadecimal key);
}
protocol (ah | bundle | esp);
spi spi-value;
}
}
no-anti-replay;
remote-gateway address;
syslog;
tunnel-mtu bytes;
}

The principal IPsec actions are to configure a dynamic or manual SA:

You can configure the following additional properties:

Enabling IPsec Packet Fragmentation

To enable fragmentation of IP version 4 (IPv4) packets in IPsec tunnels, include the clear-dont-fragment-bit statement at the [edit services ipsec-vpn rule rule-name term term-name then] hierarchy level:

[edit services ipsec-vpn rule rule-name term term-name then]
clear-dont-fragment-bit;

Setting the clear-dont-fragment-bit statement clears the Don’t Fragment (DF) bit in the packet header, regardless of the packet size. If the packet size exceeds the tunnel maximum transmission unit (MTU) value, the packet is fragmented before encapsulation. For IPsec tunnels, the default MTU value is 1500 regardless of the interface MTU setting.

Configuring Destination Addresses for Dead Peer Detection

To specify the remote address to which the IPsec traffic is directed, include the remote-gateway statement at the [edit services ipsec-vpn rule rule-name term term-name then] hierarchy level:

[edit services ipsec-vpn rule rule-name term term-name then]
remote-gateway address;

To specify a backup remote address, include the backup-remote-gateway statement at the [edit services ipsec-vpn rule rule-name term term-name then] hierarchy level:

[edit services ipsec-vpn rule rule-name term term-name then]
backup-remote-gateway address;

These two statements support both IPv4 and IPv6 address formats.

Configuring the backup-remote-gateway statement enables the dead peer detection (DPD) protocol, which monitors the tunnel state and remote peer availability. When the primary tunnel defined by the remote-gateway statement is active, the backup tunnel is in standby mode. If the DPD protocol determines that the primary remote gateway address is no longer reachable, a new tunnel is established to the backup address.

Note: Configuration of the backup-remote-gateway statement is not supported on J-series Services Routers. These routers cannot send DPD Hello messages but can respond to Hello messages sent by the peer.

If there is no incoming traffic from a peer during a defined interval of 10 seconds, the router detects a tunnel as inactive. A global timer polls all tunnels every 10 seconds and the Adaptive Services (AS) or MultiServices Physical Interface Card (PIC) sends a message listing any inactive tunnels. If a tunnel becomes inactive, the router takes the following steps to failover to the backup address:

  1. The adaptive services message triggers the DPD protocol to send a hello message to the peer.
  2. If no acknowledgment is received, two retries are sent at 2-second intervals, and then the tunnel is declared dead.
  3. Failover takes place if the tunnel is declared dead or there is an IPsec Phase 1 negotiation timeout. The primary tunnel is put in standby mode and the backup becomes active.
  4. If the negotiation to the backup tunnel times out, the router switches back to the primary tunnel. If both peers are down, it tries the failover six times. It then stops failing over and reverts to the original configuration, with the primary tunnel active and the backup in standby mode.

You can also enable triggering of DPD Hello messages without configuring a backup remote gateway by including the initiate-dead-peer-detection statement at the [edit services ipsec-vpn rule rule-name term term-name then] hierarchy level:

[edit services ipsec-vpn rule rule-name term term-name then]
initiate-dead-peer-detection;

The monitoring behavior is the same as described for the backup-remote-gateway statement. This configuration enables the router to initiate DPD Hellos when a backup IPsec gateway does not exist and clean up the IKE and IPsec SAs in case the IKE peer is not reachable.

If the DPD protocol determines that the primary remote gateway address is no longer reachable, a new tunnel is established to the backup address. However, when you configure initiate-dead-peer-detection without a backup remote gateway address and the DPD protocol determines that the primary remote gateway address is no longer reachable, the tunnel is declared dead and IKE and IPsec SAs are cleaned up.

For more information on the DPD protocol, see RFC 3706, A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers.

Disabling IPSec Anti-Replay

To disable the IPsec anti-replay feature, include the no-anti-replay statement at the [edit services ipsec-vpn rule rule-name term term-name then] hierarchy level:

[edit services ipsec-vpn rule rule-name term term-name then]
no-anti-replay;

By default, anti-replay service is enabled. Occasionally this can cause interoperability issues with other vendors’ equipment.

Enabling System Log Messages

To record an alert in the system logging facility, include the syslog statement at the [edit services ipsec-vpn rule rule-name term term-name then] hierarchy level:

[edit services ipsec-vpn rule rule-name term term-name then]
syslog;

Specifying the MTU for IPsec Tunnels

To configure a specific maximum transmission unit (MTU) value for IPsec tunnels, include the tunnel-mtu statement at the [edit services ipsec-vpn rule rule-name term term-name then] hierarchy level:

[edit services ipsec-vpn rule rule-name term term-name then]
tunnel-mtu bytes;

Note: The tunnel-mtu setting is the only place you need to configure an MTU value for IPsec tunnels. Inclusion of an mtu setting at the [edit interfaces sp-fpc/pic/port unit logical-unit-number family inet] hierarchy level is not supported.

[ Contents] [ Prev] [ Next] [ Index] [ Report an Error]

[an error occurred while processing this directive]