Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation
Guide That Contains This Content
[+] Expand All
[-] Collapse All

    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 {
    anti-replay-window-size bits;
    ike-policy policy-name;
    ipsec-policy policy-name;
    }
    direction (inbound | outbound | bidirectional) {
    algorithm (hmac-md5-96 | hmac-sha1-96);
    key (ascii-text key | hexadecimal key);
    }
    auxiliary-spi spi-value;
    algorithm algorithm;
    key (ascii-text key | hexadecimal key);
    }
    protocol (ah | bundle | esp);
    spi spi-value;
    }
    }
    tunnel-mtu bytes;
    }
    }
    }

    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

    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]

    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 Routing Policies, Firewall Filters, and Traffic Policers Feature 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.

    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.

    Note: To configure link-type tunnels, you can configure AMS logical interfaces as the IPsec internal interfaces by using the ipsec-inside-interface interface-name statement at the [edit services ipsec-vpn rule rule-name term term-name from] hierarchy level.

    Note: Starting with Junos OS Release 14.1, you can configure a maximum of up to 8,000 IPsec tunnels using 6,000 service sets on a router. In such a scenario, you can employ up to 8,000 logical interfaces in your environment and configure IPv4, IPv6, and dead peer detection (DPD) protocols. Until Junos OS Release 13.3, the maximum number of IPsec tunnels supported with 6,000 service sets was 6,000 tunnels.

    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.

    services {
    ipsec-vpn {
    rule rule-1 {
    term term-1 {
    then {
    remote-gateway 10.1.0.1;
    dynamic {
    ike-policy ike_policy;
    ipsec-policy ipsec_policy;
    }
    }
    }
    match-direction input;
    }
    .....
    }

    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:

    [edit services ipsec-vpn rule rule-name term term-name]
    anti-replay-window-size bits;
    ike-policy policy-name;
    ipsec-policy policy-name;
    }
    direction (inbound | outbound | bidirectional) {
    algorithm (hmac-md5-96 | hmac-sha1-96);
    key (ascii-text key | hexadecimal key);
    }
    auxiliary-spi spi-value;
    algorithm algorithm;
    key (ascii-text key | hexadecimal key);
    }
    protocol (ah | bundle | esp);
    spi spi-value;
    }
    }
    tunnel-mtu bytes;
    }

    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; for more information, see Configuring Dynamic Security Associations.
    • 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; for more information, see Configuring Manual Security Associations.

    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]

    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.

    In packets that are transmitted through IPSec tunnels, you can enable the value set in the Don't Fragment (DF) bit of the packet entering the tunnel to be copied only to the outer header of the IPsec packet and to not cause any modification to the DF bit in the inner header of the IPsec packet. 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. To copy the DF bit value to only the outer header and not modify the inner header, use the copy-dont-fragment-bit statement at the [edit services ipsec-vpn rule rule-name term term-name then] hierarchy level. You can also configure the DF bit to be set only in the outer IPv4 header of the IPsec packet and not be defined in the inner IPv4 header. To configure the DF bit in only the outer header of the IPsec packet and to leave the inner header unmodified, include the set-dont-fragment-bit statement at the [edit services ipsec-vpn rule rule-name term term-name then] hierarchy level. These settings apply for static endpoint tunnels and not for dynamic tunnels, for which you need to include the clear-dont-fragment-bit statement at the [edit services service-set service-set-name ipsec-vpn-options] hierarchy level to clear the DF bit in the IPv4 packets that enter the tunnel. These functionalities are supported on MX Series routers with MS-MICs and MS-MPCs.

    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]

    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]

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

    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:

    [edit services ipsec-vpn rule rule-name term term-name then]
    anti-replay-window-size bits;

    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:

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

    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:

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

    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. This defines the maximum size of an IP packet, including the IPsec overhead.

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

    Modified: 2018-03-05