IPsec VPN Overview

 

A VPN is a private network that uses a public network to connect two or more remote sites. Instead of using dedicated connections between networks, VPNs use virtual connections routed (tunneled) through public networks. IPsec VPN is a protocol, consists of set of standards used to establish a VPN connection.

IPsec VPN Overview

A VPN provides a means by which remote computers communicate securely across a public WAN such as the Internet.

A VPN connection can link two LANs (site-to-site VPN) or a remote dial-up user and a LAN. The traffic that flows between these two points passes through shared resources such as routers, switches, and other network equipment that make up the public WAN. To secure VPN communication while passing through the WAN, the two participants create an IP Security (IPsec) tunnel.

Note

The term tunnel does not denote tunnel mode (see Packet Processing in Tunnel Mode). Instead, it refers to the IPsec connection.

IPsec is a suite of related protocols for cryptographically securing communications at the IP Packet Layer. IPsec also provides methods for the manual and automatic negotiation of security associations (SAs) and key distribution, all the attributes for which are gathered in a domain of interpretation (DOI). The IPsec DOI is a document containing definitions for all the security parameters required for the successful negotiation of a VPN tunnel—essentially, all the attributes required for SA and IKE negotiations. See RFC 2407 and RFC 2408 for more information.

This topic includes the following sections:

Security Associations

A security association (SA) is a unidirectional agreement between the VPN participants regarding the methods and parameters to use in securing a communication channel. Full bidirectional communication requires at least two SAs, one for each direction. Through the SA, an IPsec tunnel can provide the following security functions:

  • Privacy (through encryption)

  • Content integrity (through data authentication)

  • Sender authentication and—if using certificates—nonrepudiation (through data origin authentication)

The security functions you employ depend on your needs. If you need only to authenticate the IP packet source and content integrity, you can authenticate the packet without applying any encryption. On the other hand, if you are concerned only with preserving privacy, you can encrypt the packet without applying any authentication mechanisms. Optionally, you can both encrypt and authenticate the packet. Most network security designers choose to encrypt, authenticate, and replay-protect their VPN traffic.

An IPsec tunnel consists of a pair of unidirectional SAs—one SA for each direction of the tunnel—that specify the security parameter index (SPI), destination IP address, and security protocol (Authentication Header [AH] or Encapsulating Security Payload [ESP] employed. An SA groups together the following components for securing communications:

For inbound traffic, Junos OS looks up the SA by using the following triplet:

  • Destination IP address.

  • Security protocol, either AH or ESP. (See IPsec Security Protocols.)

  • Security parameter index (SPI) value.

For outbound VPN traffic, the policy invokes the SA associated with the VPN tunnel.

IPsec Key Management

The distribution and management of keys are critical to using VPNs successfully. Junos OS supports IPsec technology for creating VPN tunnels with three kinds of key creation mechanisms:

  • Manual key

  • AutoKey IKE with a preshared key or a certificate

You can choose your key creation mechanism—also called authentication method—during Phase 1 and Phase 2 proposal configuration. See IPsec Tunnel Negotiation.

This topic includes the following sections:

Manual Key

With manual keys, administrators at both ends of a tunnel configure all the security parameters. This is a viable technique for small, static networks where the distribution, maintenance, and tracking of keys are not difficult. However, safely distributing manual-key configurations across great distances poses security issues. Aside from passing the keys face-to-face, you cannot be completely sure that the keys have not been compromised while in transit. Also, whenever you want to change the key, you are faced with the same security issues as when you initially distributed it.

AutoKey IKE

When you need to create and manage numerous tunnels, you need a method that does not require you to configure every element manually. IPsec supports the automated generation and negotiation of keys and security associations using the Internet Key Exchange (IKE) protocol. Junos OS refers to such automated tunnel negotiation as AutoKey IKE and supports AutoKey IKE with preshared keys and AutoKey IKE with certificates.

  • AutoKey IKE with preshared keys—Using AutoKey IKE with preshared keys to authenticate the participants in an IKE session, each side must configure and securely exchange the preshared key in advance. In this regard, the issue of secure key distribution is the same as that with manual keys. However, once distributed, an autokey, unlike a manual key, can automatically change its keys at predetermined intervals using the IKE protocol. Frequently changing keys greatly improves security, and automatically doing so greatly reduces key-management responsibilities. However, changing keys increases traffic overhead; therefore, changing keys too often can reduce data transmission efficiency.

    Note

    A preshared key is a key for both encryption and decryption, which both participants must have before initiating communication.

  • AutoKey IKE with certificates—When using certificates to authenticate the participants during an AutoKey IKE negotiation, each side generates a public-private key pair and acquires a certificate. As long as the issuing certificate authority (CA) is trusted by both sides, the participants can retrieve the peer’s public key and verify the peer's signature. There is no need to keep track of the keys and SAs; IKE does it automatically.

Diffie-Hellman Exchange

A Diffie-Hellman (DH) exchange allows participants to produce a shared secret value. The strength of the technique is that it allows participants to create the secret value over an unsecured medium without passing the secret value through the wire. The size of the prime modulus used in each group's calculation differs as follows:

  • DH Group 1—768-bit modulus

  • DH Group 2—1024-bit modulus

  • DH Group 5—1536-bit modulus

  • DH Group 14—2048-bit modulus

  • DH Group 15—3072-bit modulus

  • DH Group 16—4096-bit modulus

  • DH Group 19—256-bit modulus elliptic curve

  • DH Group 20—384-bit modulus elliptic curve

  • DH Group 21—521-bit modulus elliptic curve

  • DH Group 24—2048-bit modulus with 256-bit prime order subgroup

Starting in Junos OS Release 19.1R1, SRX5000 line of devices with SRX5K-SPC3 card support DH groups 15, 16, and 21.

Note

We do not recommend the use of DH groups 1, 2, and 5.

Because the modulus for each DH group is a different size, the participants must agree to use the same group.

IPsec Security Protocols

IPsec uses two protocols to secure communications at the IP layer:

  • Authentication Header (AH)—A security protocol for authenticating the source of an IP packet and verifying the integrity of its content

  • Encapsulating Security Payload (ESP)—A security protocol for encrypting the entire IP packet (and authenticating its content)

You can choose your security protocols—also called authentication and encryption algorithms—during Phase 2 proposal configuration. See IPsec Tunnel Negotiation.

For each VPN tunnel, both AH and ESP tunnel sessions are installed on Services Processing Units (SPUs) and the control plane. Tunnel sessions are updated with the negotiated protocol after negotiation is completed. For SRX5400, SRX5600, and SRX5800 devices, tunnel sessions on anchor SPUs are updated with the negotiated protocol while non-anchor SPUs retain ESP and AH tunnel sessions. ESP and AH tunnel sessions are displayed in the outputs for the show security flow session and show security flow cp-session operational mode commands.

This topic includes the following sections:

AH Protocol

The Authentication Header (AH) protocol provides a means to verify the authenticity and integrity of the content and origin of a packet. You can authenticate the packet by the checksum calculated through a Hash Message Authentication Code (HMAC) using a secret key and either MD5 or SHA hash functions.

  • Message Digest 5 (MD5)—An algorithm that produces a 128-bit hash (also called a digital signature or message digest) from a message of arbitrary length and a 16-byte key. The resulting hash is used, like a fingerprint of the input, to verify content and source authenticity and integrity.

  • Secure Hash Algorithm (SHA)—An algorithm that produces a 160-bit hash from a message of arbitrary length and a 20-byte key. It is generally regarded as more secure than MD5 because of the larger hashes it produces. Because the computational processing is done in the ASIC, the performance cost is negligible.

Note

For more information on MD5 hashing algorithms, see RFC 1321 and RFC 2403. For more information on SHA hashing algorithms, see RFC 2404. For more information on HMAC, see RFC 2104.

ESP Protocol

The Encapsulating Security Payload (ESP) protocol provides a means to ensure privacy (encryption) and source authentication and content integrity (authentication). ESP in tunnel mode encapsulates the entire IP packet (header and payload) and then appends a new IP header to the now-encrypted packet. This new IP header contains the destination address needed to route the protected data through the network. (See Packet Processing in Tunnel Mode.)

With ESP, you can both encrypt and authenticate, encrypt only, or authenticate only. For encryption, you can choose one of the following encryption algorithms:

  • Data Encryption Standard (DES)—A cryptographic block algorithm with a 56-bit key.

  • Triple DES (3DES)—A more powerful version of DES in which the original DES algorithm is applied in three rounds, using a 168-bit key. DES provides significant performance savings but is considered unacceptable for many classified or sensitive material transfers.

  • Advanced Encryption Standard (AES)—An encryption standard which offers greater interoperability with other devices. Junos OS supports AES with 128-bit, 192-bit, and 256-bit keys.

For authentication, you can use either MD5 or SHA algorithms.

Note

Even though it is possible to select NULL for encryption, it has been demonstrated that IPsec might be vulnerable to attack under such circumstances. Therefore, we suggest that you choose an encryption algorithm for maximum security.

IPsec Tunnel Negotiation

To establish an AutoKey IKE IPsec tunnel, two phases of negotiation are required:

  • In Phase 1, the participants establish a secure channel in which to negotiate the IPsec security associations (SAs).

  • In Phase 2, the participants negotiate the IPsec SAs for encrypting and authenticating the ensuing exchanges of user data.

For a manual key IPsec tunnel, because all the SA parameters have been previously defined, there is no need to negotiate which SAs to use. In essence, the tunnel has already been established. When traffic matches a policy using that manual key tunnel or when a route involves the tunnel, the Juniper Networks device simply encrypts and authenticates the data, as you determined, and forwards it to the destination gateway.

The remote IKE gateway address can be in any virtual routing (VR) instance. VR is determined during IKE Phase 1 and Phase 2 negotiation. VR does not have to be configured in the IKE proposals. If the IKE gateway interface is moved from one VR to another, the existing IKE Phase 1 and Phase 2 negotiations for the IKE gateway are cleared, and new Phase 1 and Phase 2 negotiations are performed.

Note
  • On SRX Series devices, when you enable VPN, overlapping of IP addresses across virtual routers is supported with the following limitations:

    • An IKE external interface address cannot overlap with any other virtual router.

    • An internal or trust interface address can overlap across virtual routers.

    • An st0 interface address cannot overlap in route-based VPN in point-to-multipoint tunnel such as NHTB.

    • An st0 interface address can overlap in route-based VPN in point-to-point tunnel.

  • The combinations of local IP addresses and remote gateway IP addresses of IPsec VPN tunnels configured across VRs have to be unique.

  • When the loopback interface is used as the IKE gateway external interface, the physical interface for IKE negotiation should be in the same VR.

IPsec VPN Topologies on SRX Series Devices

The following are some of the IPsec VPN topologies that Junos operating system (OS) supports:

  • Site-to-site VPNs—Connects two sites in an organization together and allows secure communications between the sites.

  • Hub-and-spoke VPNs—Connects branch offices to the corporate office in an enterprise network. You can also use this topology to connect spokes together by sending traffic through the hub.

  • Remote access VPNs—Allows users working at home or traveling to connect to the corporate office and its resources. This topology is sometimes referred to as an end-to-site tunnel.

Comparison of Policy-Based VPNs and Route-Based VPNs

Note

Policy-based VPNs are only supported on SRX5400, SRX5600, and SRX5800 devices. Platform support depends on the Junos OS release in your installation.

Table 1 summarizes the differences between policy-based VPNs and route-based VPNs.

Table 1: Comparison Between Policy-Based VPNs and Route-Based VPNs

Policy-Based VPNs

Route-Based VPNs

In policy-based VPNs, a tunnel is treated as an object that, together with source, destination, application, and action, constitutes a tunnel policy that permits VPN traffic.

In route-based VPNs, a policy does not specifically reference a VPN tunnel.

A tunnel policy specifically references a VPN tunnel by name.

A route determines which traffic is sent through the tunnel based on a destination IP address.

The number of policy-based VPN tunnels that you can create is limited by the number of tunnels that the device supports.

The number of route-based VPN tunnels that you create is limited by the number of st0 interfaces (for point-to-point VPNs) or the number of tunnels that the device supports, whichever is lower.

With a policy-based VPN, although you can create numerous tunnel policies referencing the same VPN tunnel, each tunnel policy pair creates an individual IPsec SA with the remote peer. Each SA counts as an individual VPN tunnel.

Because the route, not the policy, determines which traffic goes through the tunnel, multiple policies can be supported with a single SA or VPN.

In a policy-based VPN, the action must be permit and must include a tunnel.

In a route-based VPN, the regulation of traffic is not coupled to the means of its delivery.

The exchange of dynamic routing information is not supported in policy-based VPNs.

Route-based VPNs support the exchange of dynamic routing information through VPN tunnels. You can enable an instance of a dynamic routing protocol, such as OSPF, on an st0 interface that is bound to a VPN tunnel.

If you need more granularity than a route can provide to specify the traffic sent to a tunnel, using a policy-based VPN with security policies is the best choice.

Route-based VPNs uses routes to specify the traffic sent to a tunnel; a policy does not specifically reference a VPN tunnel.

With a policy-based VPN tunnel, you can consider a tunnel as an element in the construction of a policy.

When the security device does a route lookup to find the interface through which it must send traffic to reach an address, it finds a route through a secure tunnel (st0) interface.

With a route-based VPN tunnel, you can consider a tunnel as a means for delivering traffic, and can consider the policy as a method for either permitting or denying the delivery of that traffic.

Understanding IKE and IPsec Packet Processing

An IPsec VPN tunnel consists of tunnel setup and applied security. During tunnel setup, the peers establish security associations (SAs), which define the parameters for securing traffic between themselves. (See IPsec VPN Overview.) After the tunnel is established, IPsec protects the traffic sent between the two tunnel endpoints by applying the security parameters defined by the SAs during tunnel setup. Within the Junos OS implementation, IPsec is applied in tunnel mode, which supports the Encapsulating Security Payload (ESP) and Authentication Header (AH) protocols.

This topic includes the following sections:

Packet Processing in Tunnel Mode

IPsec operates in one of two modes—transport or tunnel. When both ends of the tunnel are hosts, you can use either mode. When at least one of the endpoints of a tunnel is a security gateway, such as a Junos OS router or firewall, you must use tunnel mode. Juniper Networks devices always operate in tunnel mode for IPsec tunnels.

In tunnel mode, the entire original IP packet—payload and header—is encapsulated within another IP payload, and a new header is appended to it, as shown in Figure 1. The entire original packet can be encrypted, authenticated, or both. With the Authentication Header (AH) protocol, the AH and new headers are also authenticated. With the Encapsulating Security Payload (ESP) protocol, the ESP header can also be authenticated.

Figure 1: Tunnel Mode
Tunnel Mode

In a site-to-site VPN, the source and destination addresses used in the new header are the IP addresses of the outgoing interface. See Figure 2.

Figure 2: Site-to-Site VPN in Tunnel Mode
Site-to-Site VPN in Tunnel Mode

In a dial-up VPN, there is no tunnel gateway on the VPN dial-up client end of the tunnel; the tunnel extends directly to the client itself (see Figure 3). In this case, on packets sent from the dial-up client, both the new header and the encapsulated original header have the same IP address: that of the client’s computer.

Note

Some VPN clients, such as the dynamic VPN client and Netscreen-Remote, use a virtual inner IP address (also called a “sticky address”). Netscreen-Remote enables you to define the virtual IP address. The dynamic VPN client uses the virtual IP address assigned during the XAuth configuration exchange. In such cases, the virtual inner IP address is the source IP address in the original packet header of traffic originating from the client, and the IP address that the ISP dynamically assigns the dial-up client is the source IP address in the outer header.

Figure 3: Dial-Up VPN in Tunnel Mode
Dial-Up VPN in Tunnel Mode

IKE Packet Processing

When a cleartext packet arrives on a Juniper Networks device that requires tunneling, and no active Phase 2 SA exists for that tunnel, Junos OS begins IKE negotiations and drops the packet. The source and destination addresses in the IP packet header are those of the local and remote IKE gateways, respectively. In the IP packet payload, there is a UDP segment encapsulating an ISAKMP (IKE) packet. The format for IKE packets is the same for Phase 1 and Phase 2. See Figure 4.

Meanwhile, the source host has sent the dropped packet again. Typically, by the time the second packet arrives, IKE negotiations are complete, and Junos OS protects the packet and all subsequent packets in the session—with IPsec before forwarding it.

Figure 4: IKE Packet for Phases 1 and 2
IKE Packet for Phases 1 and 2

The Next Payload field contains a number indicating one of the following payload types:

  • 0002—SA Negotiation Payload contains a definition for a Phase 1 or Phase 2 SA.

  • 0004—Proposal Payload can be a Phase 1 or Phase 2 proposal.

  • 0008—Transform Payload gets encapsulated in a proposal payload that gets encapsulated in an SA payload.

  • 0010—Key Exchange (KE) Payload contains information necessary for performing a key exchange, such as a DH public value.

  • 0020—Identification (IDx) Payload.

    • In Phase 1, IDii indicates the initiator ID, and IDir indicates the responder ID.

    • In Phase 2, IDui indicates the user initiator, and IDur indicates the user responder.

    The IDs are IKE ID types such as FQDN, U-FQDN, IP address, and ASN.1_DN.

  • 0040—Certificate (CERT) Payload.

  • 0080—Certificate Request (CERT_REQ) Payload.

  • 0100—Hash (HASH) Payload contains the digest output of a particular hash function.

  • 0200—Signature (SIG) Payload contains a digital signature.

  • 0400—Nonce (Nx) Payload contains some pseudorandom information necessary for the exchange).

  • 0800—Notify Payload.

  • 1000—ISAKMP Delete Payload.

  • 2000—Vendor ID (VID) Payload can be included anywhere in Phase 1 negotiations. Junos OS uses it to mark support for NAT-T.

Each ISAKMP payload begins with the same generic header, as shown in Figure 5.

Figure 5: Generic ISAKMP Payload Header
Generic ISAKMP Payload Header

There can be multiple ISAKMP payloads chained together, with each subsequent payload type indicated by the value in the Next Header field. A value of 0000 indicates the last ISAKMP payload. See Figure 6 for an example.

Figure 6: ISAKMP Header with Generic ISAKMP Payloads
ISAKMP Header with Generic ISAKMP Payloads

IPsec Packet Processing

After IKE negotiations complete and the two IKE gateways have established Phase 1 and Phase 2 security associations (SAs), all subsequent packets are forwarded using the tunnel. If the Phase 2 SA specifies the Encapsulating Security Protocol (ESP) in tunnel mode, the packet looks like the one shown in Figure 7. The device adds two additional headers to the original packet that the initiating host sends.

Note

For information about ESP, see ESP Protocol. For information about tunnel mode, see Packet Processing in Tunnel Mode.

As shown in Figure 7, the packet that the initiating host constructs includes the payload, the TCP header, and the inner IP header (IP1).

Figure 7: IPsec Packet—ESP in Tunnel Mode
IPsec Packet—ESP in Tunnel Mode

The router IP header (IP2), which Junos OS adds, contains the IP address of the remote gateway as the destination IP address and the IP address of the local router as the source IP address. Junos OS also adds an ESP header between the outer and inner IP headers. The ESP header contains information that allows the remote peer to properly process the packet when it receives it. This is shown in Figure 8.

Figure 8: Outer IP Header (IP2) and ESP Header
Outer IP Header (IP2) and ESP Header

The Next Header field indicates the type of data in the payload field. In tunnel mode, this value is 4, indicating an IP packet is contained within the payload. See Figure 9.

Figure 9: Inner IP Header (IP1) and TCP Header
Inner IP Header (IP1) and TCP Header

Understanding Phase 1 of IKE Tunnel Negotiation

Phase 1 of an AutoKey Internet Key Exchange (IKE) tunnel negotiation consists of the exchange of proposals for how to authenticate and secure the channel. The participants exchange proposals for acceptable security services such as:

  • Encryption algorithms—Data Encryption Standard (DES), triple Data Encryption Standard (3DES), and Advanced Encryption Standard (AES). (See IPsec VPN Overview.)

  • Authentication algorithms—Message Digest 5 (MD5 ) and Secure Hash Algorithm (SHA). (See IPsec VPN Overview.)

  • Diffie-Hellman (DH) group. (See IPsec VPN Overview.)

  • Preshared key or RSA/DSA certificates. (See IPsec VPN Overview.)

A successful Phase 1 negotiation concludes when both ends of the tunnel agree to accept at least one set of the Phase 1 security parameters proposed and then process them. Juniper Networks devices support up to four proposals for Phase 1 negotiations, allowing you to define how restrictive a range of security parameters for key negotiation you will accept. Junos OS provides predefined standard, compatible, and basic Phase 1 proposal sets. You can also define custom Phase 1 proposals.

Phase 1 exchanges can take place in either main mode or aggressive mode. You can choose your mode during IKE policy configuration.

This topic includes the following sections:

Main Mode

In main mode, the initiator and recipient send three two-way exchanges (six messages total) to accomplish the following services:

  • First exchange (messages 1 and 2)—Proposes and accepts the encryption and authentication algorithms.

  • Second exchange (messages 3 and 4)—Executes a DH exchange, and the initiator and recipient each provide a pseudorandom number.

  • Third exchange (messages 5 and 6)—Sends and verifies the identities of the initiator and recipient.

The information transmitted in the third exchange of messages is protected by the encryption algorithm established in the first two exchanges. Thus, the participants’ identities are encrypted and therefore not transmitted “in the clear.”

Aggressive Mode

In aggressive mode, the initiator and recipient accomplish the same objectives as with main mode, but in only two exchanges, with a total of three messages:

  • First message—The initiator proposes the security association (SA), initiates a DH exchange, and sends a pseudorandom number and its IKE identity.

    Note

    When configuring aggressive mode with multiple proposals for Phase 1 negotiations, use the same DH group in all proposals because the DH group cannot be negotiated. Up to four proposals can be configured.

  • Second message—The recipient accepts the SA; authenticates the initiator; and sends a pseudorandom number, its IKE identity, and, if using certificates, the recipient's certificate.

  • Third message—The initiator authenticates the recipient, confirms the exchange, and, if using certificates, sends the initiator's certificate.

Because the participants’ identities are exchanged in the clear (in the first two messages), aggressive mode does not provide identity protection.

Note

Main and aggressive modes applies only to IKEv1 protocol. IKEv2 protocol does not negotiate using main and aggressive modes.

Understanding Phase 2 of IKE Tunnel Negotiation

After the participants have established a secure and authenticated channel, they proceed through Phase 2, in which they negotiate security associations (SAs) to secure the data to be transmitted through the IPsec tunnel.

Similar to the process for Phase 1, the participants exchange proposals to determine which security parameters to employ in the SA. A Phase 2 proposal also includes a security protocol—either Encapsulating Security Payload (ESP) or Authentication Header (AH)—and selected encryption and authentication algorithms. The proposal can also specify a Diffie-Hellman (DH) group, if Perfect Forward Secrecy (PFS) is desired.

Regardless of the mode used in Phase 1, Phase 2 always operates in quick mode and involves the exchange of three messages.

Juniper Networks devices support up to four proposals for Phase 2 negotiations, allowing you to define how restrictive a range of tunnel parameters you will accept. Junos OS provides predefined standard, compatible, and basic Phase 2 proposal sets. You can also define custom Phase 2 proposals.

This topic includes the following sections:

Proxy IDs

In Phase 2, the peers exchange proxy IDs. A proxy ID consists of a local and remote IP address prefix. The proxy ID for both peers must match, which means that the local IP address specified for one peer must be the same as the remote IP address specified for the other peer.

Perfect Forward Secrecy

PFS is a method for deriving Phase 2 keys independent from and unrelated to the preceding keys. Alternatively, the Phase 1 proposal creates the key (the SKEYID_d key) from which all Phase 2 keys are derived. The SKEYID_d key can generate Phase 2 keys with a minimum of CPU processing. Unfortunately, if an unauthorized party gains access to the SKEYID_d key, all your encryption keys are compromised.

PFS addresses this security risk by forcing a new DH key exchange to occur for each Phase 2 tunnel. Using PFS is thus more secure, although the rekeying procedure in Phase 2 might take slightly longer with PFS enabled.

Replay Protection

A replay attack occurs when an unauthorized person intercepts a series of packets and uses them later either to flood the system, causing a denial of service (DoS), or to gain entry to the trusted network. Junos OS provides a replay protection feature that enables devices to check every IPsec packet to see if it has been received previously. If packets arrive outside a specified sequence range, Junos OS rejects them. Use of this feature does not require negotiation, because packets are always sent with sequence numbers. You simply have the option of checking or not checking the sequence numbers.

Supported IPsec and IKE Standards

On routers equipped with one or more MS-MPCs, MS-MICs, or DPCs, the Canada and U.S. version of Junos OS substantially supports the following RFCs, which define standards for IP Security (IPsec) and Internet Key Exchange (IKE).

  • RFC 2085, HMAC-MD5 IP Authentication with Replay Prevention

  • RFC 2401, Security Architecture for the Internet Protocol (obsoleted by RFC 4301)

  • RFC 2402, IP Authentication Header (obsoleted by RFC 4302)

  • RFC 2403, The Use of HMAC-MD5-96 within ESP and AH

  • RFC 2404, The Use of HMAC-SHA-1-96 within ESP and AH (obsoleted by RFC 4305)

  • RFC 2405, The ESP DES-CBC Cipher Algorithm With Explicit IV

  • RFC 2406, IP Encapsulating Security Payload (ESP) (obsoleted by RFC 4303 and RFC 4305)

  • RFC 2407, The Internet IP Security Domain of Interpretation for ISAKMP (obsoleted by RFC 4306)

  • RFC 2408, Internet Security Association and Key Management Protocol (ISAKMP) (obsoleted by RFC 4306)

  • RFC 2409, The Internet Key Exchange (IKE) (obsoleted by RFC 4306)

  • RFC 2410, The NULL Encryption Algorithm and Its Use With IPsec

  • RFC 2451, The ESP CBC-Mode Cipher Algorithms

  • RFC 2460, Internet Protocol, Version 6 (IPv6)

  • RFC 2560, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP

  • RFC 3193, Securing L2TP using IPsec

  • RFC 3280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile

  • RFC 3602, The AES-CBC Cipher Algorithm and Its Use with IPsec

  • RFC 3948, UDP Encapsulation of IPsec ESP Packets

  • RFC 4106, The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)

  • RFC 4210, Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)

  • RFC 4211, Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)

  • RFC 4301, Security Architecture for the Internet Protocol

  • RFC 4302, IP Authentication Header

  • RFC 4303, IP Encapsulating Security Payload (ESP)

  • RFC 4305, Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)

  • RFC 4306, Internet Key Exchange (IKEv2) Protocol

  • RFC 4307, Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)

  • RFC 4308, Cryptographic Suites for IPsec

    Note

    Only Suite VPN-A is supported in Junos OS.

  • RFC 4754, IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA)

  • RFC 4835, Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)

  • RFC 5996, Internet Key Exchange Protocol Version 2 (IKEv2)

Junos OS partially supports the following RFCs for IPsec and IKE:

  • RFC 3526, More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)

  • RFC 5114, Additional Diffie-Hellman Groups for Use with IETF Standards

  • RFC 5903, Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2

The following RFCs and Internet draft do not define standards, but provide information about IPsec, IKE, and related technologies. The IETF classifies them as “Informational.”

  • RFC 2104, HMAC: Keyed-Hashing for Message Authentication

  • RFC 2412, The OAKLEY Key Determination Protocol

  • RFC 3706, A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers

  • Internet draft draft-eastlake-sha2-02.txt, US Secure Hash Algorithms (SHA and HMAC-SHA) (expires July 2006)

Understanding Distributed VPNs in SRX Series Services Gateways

In the SRX5400, SRX5600, and SRX5800 devices, IKE provides tunnel management for IPsec and authenticates end entities. IKE performs a Diffie-Hellman (DH) key exchange to generate an IPsec tunnel between network devices. The IPsec tunnels generated by IKE are used to encrypt, decrypt, and authenticate user traffic between the network devices at the IP layer.

The VPN is created by distributing the IKE and IPsec workload among the multiple Services Processing Units (SPUs) of the platform. For site-to-site tunnels, the least-loaded SPU is chosen as the anchor SPU. If multiple SPUs have the same smallest load, any of them can be chosen as an anchor SPU. Here, load corresponds to the number of site-to-site gateways or manual VPN tunnels anchored on an SPU. For dynamic tunnels, the newly established dynamic tunnels employ a round-robin algorithm to select the SPU.

In IPsec, the workload is distributed by the same algorithm that distributes the IKE. The Phase 2 SA for a given VPN tunnel termination points pair is exclusively owned by a particular SPU, and all IPsec packets belonging to this Phase 2 SA are forwarded to the anchoring SPU of that SA for IPsec processing.

Multiple IPsec sessions (Phase 2 SA) can operate over one or more IKE sessions. The SPU that is selected for anchoring the IPsec session is based on the SPU that is anchoring the underlying IKE session. Therefore, all IPsec sessions that run over a single IKE gateway are serviced by the same SPU and are not load-balanced across several SPUs.

Table 2 shows an example of an SRX5000 line device with three SPUs running seven IPsec tunnels over three IKE gateways.

Table 2: Distribution of IKE and IPsec Sessions Across SPUs

SPU

IKE Gateway

IPsec Tunnel

SPU0

IKE-1

IPsec-1

IPsec-2

IPsec-3

SPU1

IKE-2

IPsec-4

IPsec-5

IPsec-6

SPU2

IKE-3

IPsec-7

The three SPUs have an equal load of one IKE gateway each. If a new IKE gateway is created, SPU0, SPU1, or SPU2 could be selected to anchor the IKE gateway and its IPsec sessions.

Setting up and tearing down existing IPsec tunnels does not affect the underlying IKE session or existing IPsec tunnels.

Use the following show command to view the current tunnel count per SPU: show security ike tunnel-map.

Use the summary option of the command to view the anchor points of each gateway: show security ike tunnel-map summary.

Understanding VPN Support for Inserting Services Processing Cards

SRX5400, SRX5600, and SRX5800 devices have a chassis-based distributed processor architecture. The flow processing power is shared and is based on the number of Services Processing Cards (SPCs). You can scale the processing power of the device by installing new SPCs.

In an SRX5400, SRX5600, or SRX5800 chassis cluster, you can insert new SPCs on the devices without affecting or disrupting the traffic on the existing IKE or IPsec VPN tunnels. When you insert a new SPC in each chassis of the cluster, the existing tunnels are not affected and traffic continues to flow without disruption.

However, existing tunnels cannot use the processing power of the Service Processing Units (SPUs) in the new SPCs. A new SPU can anchor newly established site-to-site and dynamic tunnels. Newly configured tunnels are not, however, guaranteed to be anchored on a new SPU.

Site-to-site tunnels are anchored on different SPUs based on a load-balancing algorithm. The load-balancing algorithm is dependent on number flow threads each SPU is using. Tunnels belonging to the same local and remote gateway IP addresses are anchored on the same SPU on different flow RT threads used by the SPU. The SPU with the smallest load is chosen as the anchor SPU. Each SPU maintains number of flow RT threads that are hosted in that particular SPU. The number of flow RT threads hosted on each SPU vary based on the type of SPU.

Tunnel load factor = Number of tunnels anchored on the SPU / Total number of flow RT threads used by the SPU.

Dynamic tunnels are anchored on different SPUs based on a round-robin algorithm. Newly configured dynamic tunnels are not guaranteed to be anchored on the new SPC.

Starting in Junos OS Release 18.2R2 and 18.4R1, all the existing IPsec VPN features that are currently supported on SRX5K-SPC3 (SPC3) only will be supported on SRX5400, SRX5600, and SRX5800 devices when SRX5K-SPC-4-15-320 (SPC2) and SPC3 cards are installed and operating on the device in a chassis cluster mode or in a standalone mode.

When both SPC2 and SPC3 cards are installed, you can verify the tunnel mapping on different SPUs using the show security ipsec tunnel-distribution command.

Use the command show security ike tunnel-map to view the tunnel mapping on different SPUs with only SPC2 card inserted. The command show security ike tunnel-map is not valid in an environment where SPC2 and SPC3 cards are installed.

Enabling IPsec VPN Feature Set on SRX5K-SPC3 Services Processing Card

SRX 5000 Series devices with SRX5K-SPC3 card requires junos-ike package to install and to enable any of the IPsec VPN features. By default, Junos-ike package is included in Junos OS releases for SRX 5000 Series device , but not installed. You need to manually install the junos-ike package when a SPC3 card is plugged in the SRX 5000 Series device chassis for the first time.

When SPC3 card is plugged into the device for the first time, the following command should be executed to enable IPsec VPN feature support. For all the subsequent software upgrades of the device, the junos-ike package is upgraded automatically from the new Junos OS releases that is being installed in the device.

user@host> request system software add optional://junos-ike.tgz

The above configuration is required only for the first time when SPC3 card is plugged in a SRX5000 Series device.

Note

The CLI request system software add optional://junos-ike.tgz command should be executed on both the nodes if a chassis cluster is enabled.

If junos-ike package is not added when SPC3 card is plugged in the chassis, you get the below syslog warning.

Warning

KMD_INSTALL_JUNOS_IKE: IPsec VPN functionality on SPC3 needs junos-ike pkg, Please execute on cli: request system software add optional://junos-ike.tgz

You get the above syslog warning for every 60 seconds for 30 minutes. After the initial set of 30 syslog warnings, you get the syslog warning once for every 24 hours.

For example:

On SRX5000 Series device, if you have already installed the junos-ike package, and later change the hardware configuration to use only SPC2 cards, then you must uninstall the junos-ike package and reboot the device. If you are operating your SRX Series device in chassis cluster mode, ensure that you uninstall the junos-ike package on both nodes and reboot the nodes.

To uninstall the junos-ike package, use the following command from the operational mode:

To check the installed junos-ike package, use the following command:

user@host> show version | grep ike

IPsec VPN Configurations Not Supported with SRX5K-SPC3 Services Processing Card

Following IPsec VPN configurations are not supported with SRX5K-SPC3 services processing card:

  • set security ipsec proposal <proposal name> lifetime-kilobytes

  • set security ipsec vpn <vpn-name> manual

  • Only set security ike traceoptions flag all configuration is supported. Other configurations under ike traceoption flags are not supported.

  • set security ike proposal <ike proposal name> authentication-method dsa-signatures

  • set security ike policy <ike policy name> reauth-frequency

  • set security ike policy <ike policy name> certificate policy-oids

  • set security ike gateway <gateway name> advpn

  • set security ike gateway <gateway name> dynamic connections-limit

  • set security ike gateway <gateway name> aaa

  • set security ike gateway <gateway name> tcp-encap-profile

  • set security ipsec vpn <vpn name> vpn-monitor

  • set security ipsec vpn <vpn name> multi-sa

Following are the CLI commands are not supported with SRX5K-SPC3 services processing card:

  • show security ipsec tunnel-events-statistics

  • show security ipsec control-plane-security-associations

  • show security ike tunnel-map

IPsec VPN Feature Processes Supported with SRX5K-SPC3 Services Processing Card

IPsec VPN feature is supported by 2 processes, iked and ikemd on SRX5K-SPC3. A single instance of iked and ikemd will run on the Routing Engine at a time.

To restart ikemd process in the Routine Engine:

To restart iked process in the Routing Engine:

SRX5K-SPC3 Card Supported IPsec VPN Features

Note

To determine if a feature is supported by a specific platform or Junos OS release, refer Feature Explorer.

Table 3 lists the IPsec VPN features that are supported on SRX5K-SPC3 services processing card.

Table 3: IPsec VPN Feature Support on SRX Series Devices

Features

Supported on SRX5K-SPC3 Services Processing Card

Anti-Replay.

Yes

Authentication Header (AH).

Yes

Auto Discovery VPN (ADVPN) protocol.

No

Automatic and manual SA and key management.

No

Automatic or manual enrollment over IPv4.

Yes

Automatic or manual revocation over IPv4.

Yes

Automatic or manual enrollment over IPv6.

Yes

Automatic or manual revocation over IPv6.

Yes

AutoVPN

Yes

AutoVPN hubs.

Yes

AutoVPN Protocol Independent Multicast (PIM) point-to-multipoint mode.

No

AutoVPN RIP support for unicast traffic.

No

AutoVPN spokes and Auto Discovery VPN (ADVPN) partners.

No

AutoVPN with routing protocols (p2mp).

Yes

AutoVPN with traffic selectors.

Yes

Bidirectional Forwarding Detection (BFD) over OSPFv3 routes on st0 interface.

Yes

Binding trusted CAs to an IKE Policy.

Yes

BGP over IPsec.

Yes

Configuring forwarding class on IPsec VPNs.

No

Config Mode (draft-dukes-ike-mode-cfg-03).

No

Certificate - Configure local certificate sent to peer.

Yes

Certificate - Configure requested CA of peer certificate.

Yes

Certificate - Encoding: PKCS7.

Yes

Certificate chain authentication.

Yes

Certificate - Encoding: X509.

Yes

Class of service.

Yes

Chassis cluster.

Yes

Copying outer IP header DSCP and ECN to inner IP header.

Yes

CoS support for the st0 interface.

Yes

Dead peer detection (DPD) and DPD gateway failover.

No

DF bit.

Yes

Dialup VPN.

No

Diffie-Hellman (PFS) Group 1.

Yes

Diffie-Hellman (PFS) Group 2.

Yes

Diffie-Hellman (PFS) Group 5.

Yes

Diffie-Hellman Group 1.

Yes

Diffie-Hellman Group 2.

Yes

Diffie-Hellman Group 5.

Yes

DNS name as IKE gateway address.

Yes

DSA signature authentication (1024-bit, 2048-bit, or 4096-bit key size).

Yes

Dual-stack (parallel IPv4 and IPv6 tunnels) over a single physical interface.

Yes

Dynamic IP address.

Yes

Dynamic Policy for Dialup (based of IKE/IPsec).

No

Dual active-backup IPsec VPN chassis clusters.

Yes

Dynamic endpoint VPN.

Yes

ECDSA signatures.

Yes

Encapsulating Security Payload (ESP) protocol.

Yes

Encryption Algorithms 3DES.

Yes

Encryption Algorithms AES 128, 192, and 256.

Yes

Encryption Algorithms DES.

Yes

Encryption Algorithms NULL (authentication only).

Yes

Encrypted control link.

Yes

Encryption sets, authentication algorithms, and DH groups support.

Yes

Enhanced VPN support for inactive-tunnel reporting and syslog.

Yes

Enhanced X2 interface monitoring.

Yes

ESP and AH transport modes.

No

ESP and AH tunnel modes.

Yes

Extended sequence number.

No

Fragmentation and reassembly.

Yes

Generic proposals and policies for IPv6 and IPv4.

Yes

General IKE ID.

Yes

Group VPN.

No

Hard lifetime limit.

Yes

Hash Algorithms MD5.

Yes

Hash Algorithms SHA-1

Yes

Hash Algorithms SHA-2 (SHA-256).

Yes

HMAC-SHA-256-128 authentication.

Yes

Hub-and-spoke scenario for site-to-site VPNs.

Yes

Hub and Spoke VPN.

Yes

Idle timers for IKE.

No

Idle timers for IPsec SA.

No

IKE Diffie Hellman Group 14 support.

Yes

IKE Phase 1

Yes

IKE Phase 1 lifetime.

Yes

IKE Phase 2.

Yes

IKE Phase 2 lifetime.

Yes

IKEv2 configuration payload support with RADIUS.

Yes

IKEv2 message fragmentation.

Yes

IKEv2 reauthentication.

Yes

IKEv2 with NAT-T and dynamic endpoint VPN.

Yes

Improvements in VPN debugging capabilities.

Yes

Improvements in VPN Debug Capabilities.

Yes

Increased IKE security associations.

Yes

Invalid SPI response.

No

Initial Contact.

Yes

Internet Key Exchange (IKE) support.

Yes

Internet Key Exchange version 2 (IKEv2).

Yes

IPsec NAT-Traversal.

No

IPsec tunnel termination in routing-instances.

Yes

IPv6 address for point-to-point AutoVPN networks that use traffic selectors.

Yes

IPv6 support for dynamic endpoint VPNs.

Yes

IPv6 addresses within PKI certificate fields.

Yes

IPv6 support for AutoVPN and ADVPN with dynamic routing protocol.

No

IPv6 extension headers.

Yes

ISSU.

Yes

J-Web support for IKE path fragmentation.

Yes

Lifetime of IKE or IPsec SA, in seconds.

Yes

Lifetime of IKE SA, in kilobytes.

No

Local address selection.

Yes

Logical system.

No

Loopback address termination.

Yes

Loopback interface for chassis cluster VPN.

Yes

Manual key management.

No

Manual proxy-ID (Phase 2 ID) configuration.

Yes

Manual VPN.

No

Multicast dynamic routing (PIM).

No

Multicast over IPsec tunnels.

No

Multiple SPUs.

Yes

Multiple traffic selector pairs.

Yes

Multicast traffic.

No

NAT-Traversal (NAT-T) for IPv4 IKE peers.

Yes

NCP Exclusive Remote Access Client connections to IPsec VPN gateways.

No

Neighbor Discovery Protocol (NDP) over st0 interfaces.

No

NHTB - Next Hop Tunnel Binding.

Yes

Numbered and unnumbered tunnel interfaces.

Yes

Packet size configuration for IPsec datapath verification.

No

Packet reordering for IPv6 fragments over tunnel.

No

PKI authentication.

Yes

PKI in virtual router.

Yes

PKI Support.

Yes

Point-to-point tunnel interfaces.

Yes

Point-to-multipoint tunnel interfaces.

No

Policy-based IPsec VPN.

No

Preshared key or certificate authentication.

Yes

Preshared key (PSK).

Yes

Protocol Requirements for IP Modular Encryption (PRIME) IKEv2 AES-GCM.

Yes

Remote Access.

No

Remote Access user IKE peer.

No

Remote Access user-group IKE peer - group IKE ID.

No

RIP over IPsec.

No

Route-based VPN.

Yes

RSA signature authentication (512-bit, 1024-bit, 2048-bit, or 4096-bit key size).

Yes

Single proxy ID pairs.

Yes

Site-to-site VPN support for NAT-T.

No

Site-to-site VPN.

Yes

SNMP MIB.

Yes

Soft lifetime.

Yes

Stateful Failover - IPsec VPN (Route based).

Yes

SSL remote access VPNs by encapsulating IPsec traffic over TCP connections.

No

SSL remote access VPN support by bypassing an application-based firewall.

No

Stateful Failover - IPsec VPN (Policy based).

No

Statistics, logs, per-tunnel debugging.

Yes

Static IP address.

Yes

Suite B cryptographic suites.

Yes

Support group IKE IDs for Dynamic VPN configuration.

Yes

Traffic selectors for IKEv2 site-to-site VPNs.

Yes

TOS/DSCP Honoring for IPsec (outer/Inner).

Yes

Tunnel IP services (Screen, NAT, ALG, IPS, and AppSecure).

No

Tunnel Mode with clear/copy/set Don't Fragement bit.

Yes

Unicast static and dynamic (RIP, OSPF, BGP) routing.

Yes

Verification of the IPsec data path before a point-to-point secure tunnel (st0) interface is activated.

No

Virtual router.

Yes

Virtual router support for route-based VPNs.

Yes

VPN monitoring.

No

VPN support for inserting Services Processing Cards.

Yes

VPN session affinity.

Yes

VPN tunnel.

No

VPN tunnel interface.

No

XAuth (draft-beaulieu-ike-xauth-03).

No

Xauth or modecfg over IPv6.

No

X.509 encoding for IKE.

Yes

Anti-Replay Window

On SRX Series devices, anti-replay-window is enabled by default with a window size value of 64.

On the SRX Series 5000 line of devices with SPC3 cards installed, you can configure the anti-replay-window size in the range of 64 to 8192 (power of 2). To configure the window size, use the new anti-replay-window-size option. An incoming packet is validated for replay attack based on the anti-replay-window-size that is configured.

You can configure replay-window-size at two different levels:

  • Global level—Configured at the [edit security ipsec] hierarchy level.

    For example:

  • VPN object—Configured at the [edit security ipsec vpn vpn-name ike] hierarchy level.

    For example:

If anti-replay is configured at both levels, the window size configured for a VPN object level takes precedence over the window size configured at the global level. If anti-replay is not configured, the window size is 64 by default.

To disable the anti-replay window option on a VPN object, use the set no-anti-replay command at the [edit security ipsec vpn vpn-name ike] hierarchy level. You cannot disable anti-replay at the global level.

Note

You cannot configure both anti-replay-window-size and no-anti-replay on a VPN object.

Understanding Hub-and-Spoke VPNs

If you create two VPN tunnels that terminate at a device, you can set up a pair of routes so that the device directs traffic exiting one tunnel to the other tunnel. You also need to create a policy to permit the traffic to pass from one tunnel to the other. Such an arrangement is known as hub-and-spoke VPN. (See Figure 10.)

You can also configure multiple VPNs and route traffic between any two tunnels.

Note

SRX Series devices support only the route-based hub-and-spoke feature.

Figure 10: Multiple Tunnels in a Hub-and-Spoke VPN Configuration
Multiple Tunnels in a Hub-and-Spoke
VPN Configuration
Release History Table
Release
Description
Starting in Junos OS Release 19.1R1, SRX5000 line of devices with SRX5K-SPC3 card support DH groups 15, 16, and 21.