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:
Each IPsec rule consists of a set of terms, similar to a firewall filter.
A term consists of the following:
- from statement—Specifies the match conditions and applications that are included and excluded.
- then statement—Specifies the actions and action modifiers to be performed by the router software.
The following sections explain how to configure the components of IPsec rules:
- Configuring Match Direction for IPsec Rules
- Configuring Match Conditions in IPsec Rules
- Configuring Actions in 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:
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.
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 matches 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:
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 OS Routing Policy 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 the 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.
The Junos OS 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. |
A special situation is provided by a term containing an “any-any” match condition (usually because the from statement is omitted). If there is an any-any match in a tunnel, a flow is not needed, because all flows within this tunnel use the same security association (SA) and packet selectors do not play a significant role. As a result, these tunnels will use packet-based IPsec. This strategy saves some flow resources on the PIC, which can be used for other tunnels that need a flow-based service.
The following configuration example shows an any-any tunnel configuration with no from statement in term-1. Missing selectors in the from clause result in a packet-based IPsec service.
Flowless IPsec service is provided to link-type tunnels with an any-any matching, as well as to dynamic tunnels with any-any matching in both dedicated and shared mode.
For link-type tunnels, a mixture of flowless and flow-based IPsec is supported within a service set. If a service set includes some terms with any-any matching and some terms with selectors in the from clause, packet-based service is provided for the any-any tunnels and flow-based service is provided for the other tunnels with selectors.
For non link-type tunnels, if a service set contains both any-any terms and selector-based terms, flow-based service is provided to all the tunnels.
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:
The principal IPsec actions are to configure a dynamic or manual SA:
- You configure a dynamic SA by including the dynamic statement at the [edit services ipsec-vpn rule rule-name term term-name then] hierarchy level and referencing policies you have configured at the [edit services ipsec-vpn ipsec] and [edit services ipsec-vpn ike] hierarchy levels.
- You configure a manual SA by including the manual statement at the [edit services ipsec-vpn rule rule-name term term-name then] hierarchy level.
You can configure the following additional properties:
- Enabling IPsec Packet Fragmentation
- Configuring Destination Addresses for Dead Peer Detection
- Configuring or Disabling IPsec Anti-Replay
- Enabling System Log Messages
- Specifying the MTU for IPsec Tunnels
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:
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:
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:
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.
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 fail over to the backup address:
- The adaptive services message triggers the DPD protocol to send a hello message to the peer.
- If no acknowledgment is received, two retries are sent at 2-second intervals, and then the tunnel is declared dead.
- 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.
- 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:
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.
Configuring or Disabling IPsec Anti-Replay
To configure the size of the IPsec antireplay window, include the anti-replay-window-size statement at the [edit services ipsec-vpn rule rule-name term term-name then] hierarchy level:
anti-replay-window-size can take values in the range from 64 through 4096 bits. The default value is 64 bits for AS PICs and 128 bits for Multiservices PICs and DPCs. AS PICs can support a maximum replay window size of 1024 bits, whereas Multiservices PICs and DPCs can support a maximum replay window size of 4096 bits. When the software is committing an IPsec configuration , the key management process (kmd) is unable to differentiate between the service interface types. As a result, if the maximum antireplay window size exceeds 1024 for AS PICs, the commit succeeds and no error message is produced. However, the software internally sets the antireplay window size for AS PICs to 1024 bits even if the configured value of the anti-replay-window-size is larger.
To disable the IPsec antireplay feature, include the no-anti-replay statement at the [edit services ipsec-vpn rule rule-name term term-name then] hierarchy level:
By default, antireplay 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:
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:
| 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. |
