ON THIS PAGE
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.
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.
The term tunnel does not denote tunnel mode (see Packet Processing in Tunnel Mode). Instead, it refers to the IPsec connection.
IPsec VPN Topologies on SRX Series Firewalls
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.
See Also
Comparing Policy-Based and Route-Based VPNs
It is important to understand the differences between policy-based and route-based VPNs and why one might be preferable to the other.
Table 1 lists the differences between route-based VPNs and policy-based VPNs.
Route-Based VPNs |
Policy-Based VPNs |
---|---|
With route-based VPNs, a policy does not specifically reference a VPN tunnel. |
With policy-based VPN tunnels, a tunnel is treated as an object that, together with source, destination, application, and action, constitutes a tunnel policy that permits VPN traffic. |
The policy references a destination address. |
In a policy-based VPN configuration, a tunnel policy specifically references a VPN tunnel by name. |
The number of route-based VPN tunnels that you create is limited by the number of route entries or the number of st0 interfaces that the device supports, whichever number is lower. |
The number of policy-based VPN tunnels that you can create is limited by the number of policies that the device supports. |
Route-based VPN tunnel configuration is a good choice when you want to conserve tunnel resources while setting granular restrictions on VPN traffic. |
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 security association (SA) with the remote peer. Each SA counts as an individual VPN tunnel. |
With a route-based approach to VPNs, the regulation of traffic is not coupled to the means of its delivery. You can configure dozens of policies to regulate traffic flowing through a single VPN tunnel between two sites, and only one IPsec SA is at work. Also, a route-based VPN configuration allows you to create policies referencing a destination reached through a VPN tunnel in which the action is deny. |
In a policy-based VPN configuration, the action must be permit and must include a tunnel. |
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. |
The exchange of dynamic routing information is not supported in policy-based VPNs. |
Route-based configurations are used for hub-and-spoke topologies. |
Policy-based VPNs cannot be used for hub-and-spoke topologies. |
With route-based VPNs, a policy does not specifically reference a VPN tunnel. |
When a tunnel does not connect large networks running dynamic routing protocols and you do not need to conserve tunnels or define various policies to filter traffic through the tunnel, a policy-based tunnel is the best choice. |
Route-based VPNs do not support remote-access (dial-up) VPN configurations. |
Policy-based VPN tunnels are required for remote-access (dial-up) VPN configurations. |
Route-based VPNs might not work correctly with some third-party vendors. |
Policy-based VPNs might be required if the third party requires separate SAs for each remote subnet. |
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 via a secure tunnel 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. |
With a policy-based VPN tunnel, you can consider a tunnel as an element in the construction of a policy. |
Route-based VPNs support NAT for st0 interfaces. |
Policy-based VPNs cannot be used if NAT is required for tunneled traffic. |
Proxy ID is supported for both route-based and policy-based VPNs. Route-based tunnels also offer the usage of multiple traffic selectors also known as multi-proxy ID. A traffic selector is an agreement between IKE peers to permit traffic through a tunnel, if the traffic matches a specified pair of local and remote IP address prefix, source port range, destination port range, and protocol. You define a traffic selector within a specific route-based VPN, which can result in multiple Phase 2 IPsec SAs. Only traffic that conforms to a traffic selector is permitted through an SA. The traffic selector is commonly required when remote gateway devices are non-Juniper Networks devices.
Policy-based VPNs are only supported on SRX5400, SRX5600, and SRX5800 line. Platform support depends on the Junos OS release in your installation.
See Also
Comparison of Policy-Based VPNs and Route-Based VPNs
Table 2 summarizes the differences 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 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.
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.
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.
See Also
Distribution of IKE and IPsec Sessions Across SPUs
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 3 shows an example of an SRX5000 line with three SPUs running seven IPsec tunnels over three IKE gateways.
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
.
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.
Starting in Junos OS Release 19.4R1, on all SRX5000 line chassis cluster, you can insert a new SRX5K-SPC3 (SPC3) or SRX5K-SPC-4-15-320 (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. You must reboot the node after the inserting SPC3 to activate the card. After the node reboot is complete, IPsec tunnels are distributed to the cards.
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.
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.
-
On SRX5800 chassis cluster, you must not insert the SPC3 card in the highest slot (slot no. 11) due to the power and heat distribution limit.
-
We do not support SPC3 hot removal.
Table 4 summarizes the SRX5000 line with SPC2 or SPC3 card that supports kmd
or iked
process:
SRX5000 Line |
Support for |
---|---|
SRX5000 line with only SPC2 card installed |
Supports |
SRX5000 line with only SPC3 card installed |
Supports |
SRX5000 line with both SPC2 and SPC3 card installed |
Supports |
See Also
Cryptographic acceleration support on SRX5K-SPC3 Card, SRX mid-range platforms and vSRX Virtual Firewall
SRX5000 line with SRX5K-SPC3 card (Services Processing Card), SRX mid-range platforms
(SRX4100, SRX4200, SRX1500 and SRX4600 Series Firewalls) and vSRX Virtual Firewall
requires junos-ike
package as the control plane software to install and
enable IPsec VPN features.
-
On SRX5000 line with RE3, by default,
junos-ike
package is installed in Junos OS Releases 20.1R2, 20.2R2, 20.3R2, 20.4R1, and later. As a result, iked and ikemd process runs on the routing engine by default instead of IPsec key management daemon (kmd). The SRX5000 line with SRX5K-SPC3 offloads the cryptographic operations to the hardware cryptographic engine. -
The SRX mid-range platforms covering SRX1500, SRX4100, SRX4200 and SRX4600 Series Firewalls, offloads the DH, RSA and ECDSA cryptographic operations to the hardware cryptographic engine with devices running
junos-ike
software. This feature is available from Junos OS Release 23.2R1 with devices havingjunos-ike
package installed. The devices that continue to run legacy iked software (kmd process) do not support this feature. -
On vSRX Virtual Firewall, the data plane CPU thread offloads the DH, RSA and ECDSA operations. Hardware acceleration is not available on these devices. This feature is available from Junos OS Release 23.2R1 with
junos-ike
package installed on the device.
The Table 5 describes the hardware acceleration support for various ciphers:
Ciphers | SRX1500 | SRX4100/SRX4200 | SRX4600 | SRX5K - SPC3 | vSRX3.0 | ||||
---|---|---|---|---|---|---|---|---|---|
KMD | IKED | KMD | IKED | KMD | IKED | IKED | KMD | IKED | |
DH (Groups 1, 2, 5, 14) | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
DH (Groups 19, 20) | No | Yes | No | Yes | No | Yes | Yes | Yes | Yes |
DH (Groups 15, 16) | No | Yes | No | Yes | No | Yes | Yes | Yes | Yes |
DH Group 21 | No | Yes | No | Yes | No | Yes | Yes | Yes | Yes |
DH Group 24 | Yes | Yes | Yes | Yes | Yes | Yes | No | No | No |
RSA | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
ECDSA (256, 384, 521) | No | Yes | No | Yes | No | Yes | Yes | Yes | Yes |
To install the Junos IKE package on your SRX Series Firewall, use the following command:
user@host> request system software add optional://junos-ike.tgz Verified junos-ike signed by PackageProductionECP256_2022 method ECDSA256+SHA256 Rebuilding schema and Activating configuration... mgd: commit complete Restarting MGD ... WARNING: cli has been replaced by an updated version: CLI release 20220208.163814_builder.r1239105 built by builder on 2022-02-08 17:07:55 UTC Restart cli using the new version ? [yes,no] (yes)
To use kmd
process in order to enable IPsec VPN features on SRX5000 line
without an SPC3 card, you must run the request system software delete
junos-ike
command. After running the command, reboot the device.
To check the installed junos-ike
package, use the following command:
user@host>
show version | grep ike
JUNOS ike [20190617.180318_builder_junos_182_x41]
JUNOS ike [20190617.180318_builder_junos_182_x41]
{primary:node0}
See Also
IPsec VPN Feature Support with New Package
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.
By default, junos-ike
package is installed in Junos OS Release 19.4R1
and later for SRX5K-SPC3 with RE3. Both the iked and
ikemd processes running on the Routing Engine are available
with this package. On SRX5K-SPC3 with RE2, this is an optional package and needs to be
installed explicitly.
To restart ikemd process in the Routine Engine use the
restart ike-config-management
command.
To restart iked process in the Routing Engine use the
restart ike-key-management
command.
Table 6 shows the details of Junos OS releases where
junos-ike
package is introduced.
Platform |
Junos OS Release with |
---|---|
SRX5K-SPC3 with RE3 |
19.4R1 and later as default package |
SRX5K-SPC3 with RE2 |
18.2R1 and later as optional package |
vSRX Virtual Firewall |
20.3R1 and later as optional package |
SRX1500 |
22.3R1 and later as optional package |
SRX4100, SRX4200, SRX4600 |
22.3R1 and later as optional package |
SRX1600, SRX2300 |
23.4R1 and later as default package |
SRX4300 |
24.2R1 and later as default package |
Disregarding the specified Junos OS release versions when installing the
junos-ike
package may result in unsupported features not
functioning as expected.
To operate IPsec VPN features using the legacy kmd process on
SRX5000 line without an SRX5K-SPC3 card, you must run the request system
software delete junos-ike
command and reboot the device. The SRX1600,
SRX2300, and SRX4300 Series Firewalls do not support kmd
process.
IPsec VPN Features Not Supported
This section provides you a summary of IPsec VPN features and configurations that are not supported of SRX5000 line with SRX5K-SPC3 and on vSRX Virtual Firewall instances.
To determine if a feature is supported by a specific platform or Junos OS release, refer Feature Explorer.
Table 7 summarizes the non-supported IPsec VPN features on SRX Series Firewalls and vSRX Virtual Firewall running iked process:
Features |
Support on SRX5000 line with SRX5K-SPC3 and vSRX Virtual Firewall Instances |
---|---|
AutoVPN Protocol Independent Multicast (PIM) point-to-multipoint mode. |
No. But support is available on vSRX 3.0 |
Configuring forwarding class on IPsec VPNs. |
No |
Group VPN. |
No |
Packet size configuration for IPsec datapath verification. |
No |
Policy-based IPsec VPN. |
No |
Routing Protocols Support on IPsec VPN Tunnels
We support routing protocols like, OSPF, BGP, PIM, RIP, and BFD to run on IPsec
tunnels on SRX Series Firewalls and MX Series routers running
kmd
or iked
process. The protocol support
varies based on the IP addressing scheme or the type of the st0 interface,
point-to-point (P2P) or point-to-multipoint (P2MP).
Table 8 summarizes OSPF protocol support on SRX Series Firewalls and MX routers.
OSPF | ||||
---|---|---|---|---|
Devices | P2P | P2MP | ||
IPv4 | IPv6 | IPv4 | IPv6 | |
SRX100, SRX110, SRX210, SRX220, SRX240, SRX300, SRX320, SRX340, SRX345, SRX380, SRX550, SRX550 HM, SRX650, SRX1400, SRX1500, SRX3400, SRX3600, SRX4100, SRX4200, SRX4600, and SRX5K-SPC2 | Yes | No | Yes | No |
SRX5K-SPC3 | Yes | No | Yes | No |
SRX5K in mixed-mode (SPC3 + SPC2) | Yes | No | Yes | No |
vSRX Virtual Firewall 3.0 | Yes | No | Yes | No |
MX-SPC3 | Yes | No | No | No |
Table 9 summarizes OSPFv3 protocol support on SRX Series Firewalls and MX routers.
OSPFv3 | ||||
---|---|---|---|---|
Devices | P2P | P2MP | ||
IPv4 | IPv6 | IPv4 | IPv6 | |
SRX100, SRX110, SRX210, SRX220, SRX240, SRX300, SRX320, SRX340, SRX345, SRX380, SRX550, SRX550 HM, SRX650, SRX1400, SRX1500, SRX3400, SRX3600, SRX4100, SRX4200, SRX4600, and SRX5K-SPC2 | No | Yes | No | Yes |
SRX5K-SPC3 | No | Yes | No | Yes |
SRX5K in mixed-mode (SPC3 + SPC2) | No | Yes | No | Yes |
vSRX Virtual Firewall 3.0 | No | Yes | No | Yes |
MX-SPC3 | No | Yes | No | No |
Table 10 summarizes BGP protocol support on SRX Series Firewalls and MX routers.
BGP | ||||
---|---|---|---|---|
Devices | P2P | P2MP | ||
IPv4 | IPv6 | IPv4 | IPv6 | |
SRX100, SRX110, SRX210, SRX220, SRX240, SRX300, SRX320, SRX340, SRX345, SRX380, SRX550, SRX550 HM, SRX650, SRX1400, SRX1500, SRX3400, SRX3600, SRX4100, SRX4200, SRX4600, and SRX5K-SPC2 | Yes | Yes | Yes | Yes |
SRX5K-SPC3 | Yes | Yes | Yes | Yes |
SRX5K in mixed-mode (SPC3 + SPC2) | Yes | Yes | Yes | Yes |
vSRX Virtual Firewall 3.0 | Yes | Yes | Yes | Yes |
MX-SPC3 | Yes | Yes | No | No |
Table 11 summarizes PIM protocol support on SRX Series Firewalls and MX routers.
PIM | ||||
---|---|---|---|---|
Devices | P2P | P2MP | ||
IPv4 | IPv6 | IPv4 | IPv6 | |
SRX100, SRX110, SRX210, SRX220, SRX240, SRX550, SRX550 HM, SRX650, SRX1400, SRX3400, SRX3600, SRX4100, SRX4200, SRX4600, and SRX5K-SPC2 | Yes | No | No | No |
SRX300, SRX320, SRX340, SRX345, SRX380, and SRX1500 | Yes | No | Yes | No |
SRX5K-SPC3 | Yes | No | No | No |
SRX5K in mixed-mode (SPC3 + SPC2) | Yes | No | No | No |
vSRX Virtual Firewall | Yes | No | Yes Note:
Multithread is not supported. |
No |
MX-SPC3 | Yes | No | No | No |
Table 12 summarizes RIP protocol support on SRX Series Firewalls and MX routers.
RIP | ||||
---|---|---|---|---|
Devices | P2P | P2MP | ||
IPv4 | IPv6 | IPv4 | IPv6 | |
SRX100, SRX110, SRX210, SRX220, SRX240, SRX300, SRX320, SRX340, SRX345, SRX380, SRX550, SRX550 HM, SRX650, SRX1400, SRX1500, SRX3400, SRX3600, SRX4100, SRX4200, SRX4600, and SRX5K-SPC2 | Yes | Yes | No | No |
SRX5K-SPC3 | Yes | Yes | No | No |
SRX5K in mixed-mode (SPC3 + SPC2) | Yes | Yes | No | No |
vSRX Virtual Firewall 3.0 | Yes | Yes | No | No |
MX-SPC3 | Yes | Yes | No | No |
Table 13 summarizes BFP protocol support on SRX Series Firewalls and MX routers.
BFD | ||||
---|---|---|---|---|
Devices | P2P | P2MP | ||
IPv4 | IPv6 | IPv4 | IPv6 | |
SRX100, SRX110, SRX210, SRX220, SRX240, SRX300, SRX320, SRX340, SRX345, SRX380, SRX550, SRX550 HM, SRX650, SRX1400, SRX1500, SRX3400, SRX3600, SRX4100, SRX4200, SRX4600, and SRX5K-SPC2 | Yes | Yes | Yes | Yes |
SRX5K-SPC3 | Yes | Yes | Yes | Yes |
SRX5K in mixed-mode (SPC3 + SPC2) | Yes | Yes | Yes | Yes |
vSRX Virtual Firewall 3.0 | Yes | Yes | Yes | Yes |
MX-SPC3 | Yes | Yes | No | No |
Anti-Replay Window
On SRX Series Firewalls, anti-replay-window
is enabled by default with a
window size value of 64.
On the SRX Series 5000 line 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:
[edit security ipsec] user@host# set anti-replay-window-size <64..8192>;
-
VPN object—Configured at the [
edit security ipsec vpn vpn-name ike
] hierarchy level.For example:
[edit security ipsec vpn vpn-name ike] user@host# set anti-replay-window-size <64..8192>;
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.
See Also
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 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.
See Also
Change History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.
junos-ike
package is installed in Junos
OS Releases 20.1R2, 20.2R2, 20.3R2, 20.4R1, and later for SRX5000 line with RE3.
As a result iked and ikemd process
runs on the routing engine by default instead of IPsec key management daemon
(kmd).