IPsec VPN Overview

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.

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

In this topic, you’ll learn about sharing the point-to-point st0 logical interface between multiple VPN objects.

Junos OS supports sharing of point-to-point st0 logical interface when you run IPsec VPN service using the iked process to provide a migration path from the kmd process. You can configure multiple VPNs objects to share a point-to-point st0 interface if you meet the following prerequisites:

• You've configured explicit traffic selectors.

• You've not used wildcard network mask in your configuration.

Read further to understand the benefits and limitations of shared point-to-point st0 interface.

• Benefits
• Limitations
• Sample Configuration

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

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

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.

Some VPN clients, such as the Netscreen-Remote, use a virtual inner IP address (also called a “sticky address”). Netscreen-Remote enables you to define the virtual IP address. 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

Review the Platform-Specific SPUs VPN Processing Behavior section for notes related to your platform.

In SRX Series Firewalls, 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 3 shows an example of the firewall with three SPUs running seven IPsec tunnels over three IKE gateways.

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.

Review the Platform-Specific SRX5000 Line SPC Behavior section for notes related to your platform.

See the Additional Platform Information for kmd and iked Process in SRX5000 Line section for more information.

In high-end SRX Series chassis cluster, you can insert SPCs on the devices without affecting or disrupting the traffic on the existing IKE or IPsec VPN tunnels.

You can insert SPC3 or SPC2 card to an existing chassis containing SPC3 card. You can only insert the cards in a higher slot than the existing SPC3 card on the chassis.

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.

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.

Inserting SPC3 Card: Guidelines and Limitations:

• In a chassis cluster, if one of the nodes has 1 SPC3 card and the other node has 2 SPC3 cards, the failover to the node that has 1 SPC3 card is not supported.

• You must insert the SPC3 or SPC2 in an existing chassis in a higher slot than a current SPC3 present in a lower slot.

• For SPC3 ISHU to work, you must insert the new SPC3 card into the higher slot number.

• We do not support SPC3 hot removal.

The two processes, iked and ikemd support IPsec VPN features on SRX Series Firewalls. A single instance of iked and ikemd run on the Routing Engine at a time.

With junos-ike package, the firewall runs IPsec VPN service using the iked process. SRX Series Firewalls support junos-ike package is multiple releases.

See the Additional Platform Information for junos-ike Package Support section for more information.

Both the iked and ikemd processes running on the Routing Engine are available with the junos-ike package.

To install the junos-ike package on SRX Series Firewall, use the following command:

To restart the ikemd process in the Routine Engine use the restart ike-config-management command.

To restart the iked process in the Routing Engine use the restart ike-key-management command.

To operate IPsec VPN features using the legacy kmd process on SRX Series Firewalls, run the request system software delete junos-ike command and reboot the device.

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

Review the Platform-Specific Cryptographic Acceleration Behavior section for notes related to your platform.

See the Additional Platform Information for Cryptographic Acceleration Support section for more information.

Junos OS supports acceleration of cryptographic operations to the hardware cryptographic engine. SRX Series Firewall can offload DH, RSA, and ECDSA cryptographic operations to the hardware cryptographic engine.

With junos-ike package, the firewall runs IPsec VPN service using the iked process. The firewall requires the iked process as the control plane software to install and enable advanced IPsec VPN features. As a result of junos-ike package the firewall runs the iked and ikemd process on the routing engine by default instead of IPsec key management daemon (kmd).

The firewalls support hardware acceleration for various ciphers.

See the Table 12, Table 13, Table 14, Table 15, Table 16, and Table 17 in Additional Platform Information section for more information.

Junos OS supports routing protocols on IPsec VPN tunnels with SRX Series Firewalls and MX Series routers with SPC3. Supported protocols include OSPF, BGP, PIM, RIP, and BFD when running the kmd or iked process. The protocol support varies based on the following:

• IP addressing scheme: IPv4 or IPv6 addresses

• Type of st0 interface: point-to-point (P2P) or point-to-multipoint (P2MP)

Review the Platform-Specific Antireplay Window Behavior section for notes related to your platform.

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

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.

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

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 4.)

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

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

Figure 4: Multiple Tunnels in a Hub-and-Spoke VPN Configuration

Use Feature Explorer to confirm platform and release support for specific features.

See the Additional Platform Information section for more information.

Use the following tables to review platform-specific behaviors for your platforms.

• Platform-Specific SPUs VPN Processing Behavior
• Platform-Specific SRX5000 Line SPC Behavior
• Platform-Specific Cryptographic Acceleration Behavior
• Platform-Specific Antireplay Window Behavior

Use Feature Explorer to confirm platform and release support for specific features. Additional Platforms may be supported.