Juniper SRX Series

Chapter 10. IPsec VPN

The SRX product suite combines the robust IP Security virtual private network (IPsec VPN) features from ScreenOS into the legendary networking platform of Junos. IPsec VPNs have become a central component of modern computer networks for securing the data between different sites and remote users. As more critical applications and sensitive information have been transferred into electronic format, the demand to secure this information has grown. IPsec VPNs are sometimes confused with Layer 2 or Layer 3 VPNs, which do not actually encrypt the data, but rather tunnel the traffic that flows through the VPNs; however, IPsec VPNs are VPNs that provide encryption and authentication to secure traffic.

There are two high-level uses for IPsec VPNs: to secure data between two or more computer networks and to secure data between a remote user and a computer network. This chapter details the technologies behind both site-to-site and remote access VPNs and how these technologies are implemented on the SRX. There has also been a great deal of development when it comes to new IPsec features since Junos Security, so we examine some of these new features and how they can improve the functionality that the SRX has to offer when it comes to IPsec. After a thorough discussion of the technology and the implementation of the IPsec VPNs on the SRX, we examine verification and troubleshooting features and conclude with some case studies to provide you with a few real-world implementation examples.

VPN Architecture Overview

VPNs not only secure communication between two devices, but they also create a virtual channel that data can traverse. In this section, we examine two primary VPN architectures: site-to-site and remote access. Although the underlying technologies are essentially the same, the manner in which the VPNs interconnect varies between the different models.

Site-to-Site IPsec VPNs

Site-to-site IPsec VPNs connect two sites together to allow for secure communication between those sites, as shown in Figure 10-1. Site-to-site VPNs are most often deployed to secure data between sites in an organization, or between an organization and a partner organization. Site-to-site VPNs are more common over the Internet than across private networks; however, many organizations are encrypting data between sites on private networks to secure the communication. Internet site-to-site VPNs also offer a cost and availability benefit over private site-to-site links, making them a good choice for securing data, especially when performance is not a major concern. The Internet site-to-site VPNs can also serve as a backup link to private links, in the event the private link should fail. There are a couple of variations of site-to-site VPNs besides the direct site-to-site architecture; these include hub and spoke, full mesh, and multipoint VPNs.

Figure 10-1. Sample site-to-site VPN

Hub and Spoke IPsec VPNs

Many enterprise networks have one or more large offices with multiple branch offices. In some cases, branch offices need to access resources in all other branches; in other cases, they might only need to access resources in the central sites. In the latter case, hub and spoke VPN networks provide a simple method of accomplishing this goal, as illustrated in Figure 10-2. Each remote site connects into the central site, but they do not connect into each other directly; rather, they connect through the central site, hence the hub and spoke moniker.

Figure 10-2. Sample hub and spoke VPN

From a management perspective, hub and spoke networks are straightforward to administer because all spokes connect to the hub. They are easy to scale because there is a minimum amount of state that must be maintained. (Only N VPNs must be maintained, where N is the number of VPNs, or remote sites; full mesh VPNs, which we will discuss next, require N(N − 1)/2 VPNs. This means that with 10 remote sites, only 10 VPNs would need to be maintained in a hub and spoke network, whereas 25 would need to be maintained in a full mesh network.) Finally, it is much easier to secure hub and spoke networks, as well as provide services for each connected network, because the security and services can be administered centrally at the hub rather than occurring at all of the spokes (this, as you can imagine, equates to cost savings).

Full Mesh VPNs

Although hub and spoke VPNs might be commonplace because of their simplicity, there are a few factors that could make this model undesirable for your particular network. First, all traffic must go from the spoke to the hub and then to the other spoke when trying to send traffic between spokes. This can result in a lag in performance and can cause latency issues, as the hub site must process all of the traffic. This is a common issue in modern networks that run real-time applications such as VoIP and video conferencing, which are sensitive to bandwidth and latency issues and generally work better when the sites can communicate directly with each other. Therefore, full mesh is most typically implemented for connecting remote offices within an organization (and is not so common between separate organizations) because it allows each site to communicate directly with all other sites, as shown in Figure 10-3. The disadvantages of full mesh VPNs are the complexity of implementation (because all sites must be interconnected), the inability to scale, and the management overhead associated with maintaining all of the VPNs.

Figure 10-3. Sample full mesh VPN

Partial Mesh VPNs

Partial mesh VPNs are a hybrid of hub and spoke and full mesh, and they attempt to combine the advantages of each model, as depicted in Figure 10-4. In partial mesh VPNs, some spokes also have direct connections between each other to improve bandwidth and latency without constricting the hub site. Suffice it to say that multipoint VPNs do have some different mechanisms to establish themselves dynamically; they are typically implemented to connect remote offices with the hub, and in some cases with each other, within an organization.

The obvious advantage of partial mesh VPNs is that the remote offices still connect to the hub but also can connect to each other. This is common in environments with some real-time applications that might need to connect to each other for performance reasons. When a VPN must be established between spokes, the spokes negotiate the connections dynamically and shut the VPNs down after the communication has ceased.

Note

As of Junos 12.1X44, the SRX supports AutoVPN, which allows the SRX to make automatic hub and spoke connections, perfect for the hub and spoke model. At the time of writing this book, the automatic spoke-to-spoke functionality is still in development, but you can look at deploying such VPNs leveraging Junos Space Security Design to establish the remote VPNs.

Figure 10-4. Sample multipoint VPN

Remote Access VPNs

Site-to-site VPNs commonly connect sites together, and another form of IPsec VPN allows a remote user to connect to a true site for remote access. The underlying technologies of site-to-site and remote access IPsec VPNs are essentially the same; the main difference is that a site-to-site VPN is typically terminated between two VPN gateways, such as two SRX platforms. There is no requirement for software on any of the end systems. In fact, the end systems do not have to be aware that there is a VPN at all; the VPN is completely transparent to the end systems, the applications, and the users. The problem is that site-to-site VPNs are not always possible to implement because of the additional hardware requirement. To help alleviate this requirement, and empower remote users to be able to access corporate resources, remote access VPNs are used to provide this functionality.

Remote access VPNs are created by running software on the end systems that will establish a VPN to the central site VPN gateway such as an SRX, as shown in Figure 10-5.

Remote access VPNs are commonly available in two forms: IPsec VPNs and SSL VPNs. Although the functionality is essentially transparent to the user, there are differences between IPsec VPNs and SSL VPNs.

IPsec VPNs

IPsec VPNs use underlying Layer 3 encryption to establish secure VPNs between a host and VPN gateway. The user traffic might or might not be tunneled, and IPsec processing is optimized for processing network traffic. IPsec VPNs also are considered to have the strongest security of any kind of remote access.

SSL VPNs

SSL VPNs are widely deployed for their simplicity, in part because they often utilize the Secure Sockets Layer of a web browser (although SSL VPNs can also use separate applications to process this traffic as well). SSL VPNs (including the Juniper Networks Secure Access SSL VPN Gateway) gained popularity because of their interoperability with end systems and their ability to function within most networks.

Figure 10-5. Sample remote access VPN

Branch SRX devices support both the Dynamic VPN and the Pulse client, but they only support termination via IPsec today for performance reasons. If you truly need to use SSL as a protocol over IPsec, then it is best to look at the Juniper Secure Access platforms (including the VMWare version), which can provide this functionality at the time of writing this book.

IPsec VPN Concepts Overview

IPsec VPNs come in many different flavors and support a multitude of configuration options to adapt to the needs of various networks while securing the data that travel in the VPN. This adaptive variation, and the fact that IPsec VPNs are popularly deployed, demand that we take a little time to demystify these options and provide you with some insight into how the different features can be used.

IPsec Encryption Algorithms

Encryption serves VPNs by obfuscating unencrypted traffic into a form that only the two sides of the VPN can understand. The SRX supports the use of the following standards-based encryption algorithms for this purpose. (For the sake of brevity, we have condensed our explanation of how the different encryption algorithms actually function, and instead we examine the strength and performance impact.)

Data Encryption Standard (DES)

DES was one of the first widely deployed encryption algorithms for IPsec. It is lightweight in terms of processing power; thus, this algorithm is more susceptible to brute force attacks because there is not as large of a key space to encrypt the traffic. It’s largely been replaced with the newer encryption algorithms of 3DES and AES. Best security practices tend for DES not to be used unless security is not a concern and only basic encryption is desired.

Triple Data Encryption Standard (3DES)

3DES is a more powerful version of DES and subjects the data to additional rounds of encryption, making it more difficult to identify clear-text traffic. Although 3DES does require more processing power than DES, it is considered to be a safe algorithm to implement for data that is of medium sensitivity.

Advanced Encryption Standard (AES)

AES is an encryption algorithm developed by the National Institute of Standards and Technology (NIST) to provide secure and efficient encryption for very sensitive data. AES comes in different key bit lengths, most commonly 128, 256, and 384—the longer the key length, the more secure the data. Note also that the longer the key length, the more processing power is required to encrypt the data. AES should be used to encrypt the most sensitive traffic.

IPsec Authentication Algorithms

IPsec authentication, also known as hashing, protects the authenticity of the source of the encryption traffic. Without authentication, the two VPN endpoints would be unable to ensure that the traffic arrived unmodified, or even that it came from its original source. IPsec authentication performs this task by using a hashing algorithm. A hashing algorithm essentially calculates a special value based on the data it hashes. Even a change of a single bit of data results in a completely different hash result. Also, a hash algorithm is meant to be nonreversible, so if an attacker had the result of the hash algorithm, it would still be difficult for him to determine the original contents. Although there is a possibility that two or more data sets could produce the same hash result, this is very unlikely, and even if there is a collision whereby two values create the same hash, it is unlikely that the two data sets would be interchangeable in clear-text form.

The SRX supports three different hash algorithms to provide IPsec authentication:

Message-Digest Algorithm 5

MD5 is a widely deployed hash algorithm that consists of a 128-bit hash space. Although acceptable as a hashing algorithm, it is not recommended for the most sensitive applications.

Secure Hash Algorithm 1

SHA-1 is an improvement over MD5, using a more robust algorithm with a larger key space (168-bit) to provide more security over MD5. SHA-1 is recommended for sensitive data that need more powerful security than MD5. SHA-1 is slowly being replaced with the new SHA-2 algorithm, although deployment of SHA-2, at the time of this writing, is not common.

Secure Hash Algorithm 2

SHA-2 is a very powerful secure hash algorithm which is supported on the SRX. It uses a larger key space than both MD5 and SHA-1 to provide maximum security (now 256- and 384-bit key lengths) and has some modifications to help maximize performance and security.

IKE Version 1 Overview

IPsec can establish a VPN in one of two ways: via the Internet Key Exchange protocol or via manual key exchange. Manual key exchange is exactly that: both sides exchange the keys in some manual fashion (e.g., phone or email), and once everything is configured, the VPN can be established. IKE is a more involved process that negotiates the VPN between both VPN endpoints. It should be strongly noted that using IKE to negotiate VPNs between two endpoints is much more common and much more secure than manual key exchange. IKE allows both sides to renegotiate VPNs on the fly so that the encryption keys are constantly changing, making it more difficult for an eavesdropper to compromise the security of the network. Manual keys do not change (or at least not automatically), so if the keys are somehow determined, administrative intervention must take place to change the keys.

Two versions of the IKE standard are available: IKE version 1 and IKE version 2, not to be confused with the different phases of IKE negotiation.

Further, IKE negotiation takes place in two phases, known as Phase 1 and Phase 2. The purpose of Phase 1 is to authenticate the identities of both sides of the VPN and to establish a secure communication channel between both sides for further negotiation. In Phase 2, the remainder of the VPN negotiation process completes, and the encryption keys are exchanged to be used to secure the data that traverses the VPN.

Let’s drill down just a little into Phase 1 and Phase 2 of IKE version 1 negotiations just to ensure that you understand the process. Numerous options could be implemented, and those options are examined further next.

Phase 1 IKE negotiation modes

IPsec VPNs can use two different modes when negotiating the IKE in Phase 1. The two modes of negotiation of Phase 1 are called Main mode and Aggressive mode. Only one mode is used for negotiation of Phase 1 of the VPN tunnel, and the mode must be configured the same on both sides of the tunnel; otherwise, Phase 1 is not able to complete.

Main mode

When building site-to-site VPNs, Main mode is the most common and secure way to establish the VPN because it provides additional security during the setup phase of the VPN tunnel and requires that six messages be exchanged during the negotiation. The advantage in security of Main mode over Aggressive mode is that the IKE identities are encrypted and cannot be determined by eavesdroppers. Main mode does require additional processing and it is typically used when the IP address of the client is not fixed or known in advance.

The following sequence of message exchange occurs during Main mode:

1. Initiator proposes the encryption and authentication algorithms to be used to establish the VPN.

2. Responder must accept the proposal and provide the other VPN gateway with a proposal of the encryption and authentication algorithm.

3. Initiator starts the Diffie-Hellman key exchange process by presenting a generated public key, along with a pseudorandom number.

4. Responder responds to the initiator with its public key as part of the Diffie-Hellman key exchange. After this message, both parties communicate via an encrypted channel.

5. Initiator sends the responder its IKE identity to authenticate itself.

6. Responder sends the initiator its IKE identity. Message 6 completes Phase 1 of the IKE negotiation.

Aggressive mode

Aggressive mode is an alternative to Main mode IPsec negotiation and it is most common when building VPNs from client workstations to VPN gateways, where the client’s IP address is neither known in advance nor fixed. Aggressive mode requires half of the messages that Main mode does when establishing Phase 1, but it does so at the cost of disclosing the IKE identities in clear text; thus, it is a little aggressive in its security negotiations.

Aggressive mode uses the following sequence of messages:

1. Initiator proposes the encryption and authentication algorithms to be used, begins the Diffie-Hellman key exchange, and sends its IKE identity and pseudorandom number.

2. Responder must accept the proposal, and will provide the initiator with a pseudo-random number and the IKE identity of the responder. The responder will have also authenticated the initiator in this stage.

3. Initiator authenticates the responder and confirms the exchange. At this point, both parties have established a secure channel for negotiating the IPsec VPN in Phase 2 and Phase 1 is now complete.

During these initial Phase 1 IKE negotiations, a secure channel must be established between the two VPN peers; however, a question might arise: how do you form a secure communication channel that can be negotiated over an insecure network? The answer is to use the Diffie-Hellman key exchange method. The intimate details of this exchange are beyond the scope of this book and are not necessary to understand VPN configuration. Suffice it to say that essentially, the Diffie-Hellman key exchange uses public key encryption whereby each party shares each other’s public keys while retaining the private keys. They then encrypt the authentication parameter (e.g., password) and send it to the other peer, which decrypts it with their private key. This happens in both directions. If both peers cannot successfully authenticate the other peer, Phase 1 cannot be established.

Diffie-Hellman groups refer to the size of the key length used for negotiating the VPN. There are several different groups, not all of which are supported by all vendors. When setting up a VPN with another party, the Diffie-Hellman groups must match on both peers; otherwise, the VPN connection will not establish, and error messages should detail the failure. The larger the key length, the stronger it is considered to be, because there are more possibilities for bit combinations. For instance, a 1-bit key would have two values, 0 and 1. A 2-bit key would have four values, 0, 1, 2, and 3, which in binary is 00, 01, 10, and 11. Therefore, the larger the key, the more possibilities for different keys and the more difficult it is to guess the correct key used for encryption. Consider these three groups and their escalating strength:

Group 1: 768-bit strength

Group 2: 1,024-bit strength

Group 5: 1,536-bit strength

Note

Starting in Junos 12.1X45 as part of the Suite B support, the SRX supports these additional Diffie-Hellman groups, which are considerably stronger than groups 1, 2, and 5: 14, 19, 20, and 24.

Phase 2 IKE negotiation modes

IKE Phase 2 is responsible for generating the encryption keys used to encrypt the data traffic within the VPN. Just like in Phase 1, messages are exchanged between the two VPN gateways, and there are some similarities. Unlike Phase 1, however, there is only one negotiation mode, called Quick mode. In Quick mode, the following events always occur during Phase 2:

1. The encryption and authentication algorithms to be used to encrypt the data traffic are negotiated.

2. The method to be used to encrypt the data traffic is negotiated: either Encapsulating Security Payload or Authentication Header (AH).

3. Proxy IDs that identify the traffic to be encrypted are negotiated.

4. Phase 2 optional processing, including Perfect Forward Secrecy (PFS), is negotiated.

Note

Additional processing might optionally take place either in Phase 2 or between Phase 1 and Phase 2. XAuth is an authentication mechanism that is commonly used for remote client IPsec VPNs, and it takes place between Phase 1 and Phase 2. We cover XAuth later in this chapter.

Perfect Forward Secrecy

PFS renegotiates Phase 1 before proceeding to negotiate Phase 2. The purpose of PFS is because in Phase 1, the exchange of keys and other encryption components can present a risk, particularly in Aggressive mode, where IKE identities are sent in the clear.

PFS mitigates those concerns by renegotiating Phase 1 in the same secure channel that Phase 1 previously built. The new Phase 1 channel is used to renegotiate Phase 2. In terms of properties, PFS essentially allows the user to suggest a different Diffie-Hellman group; however, the encryption and authentication algorithms are the same as the ones used for the original Phase 1 negotiation.

Quick mode

The only mode of negotiating Phase 2 in IPsec, known as Quick mode, exchanges three messages:

Encryption and authentication algorithms

The encryption and authentication algorithms that are used as part of the IPsec VPN.

Proxy IDs

The proxy IDs that identify what traffic is part of the VPN.

Mode and encapsulation

The VPN protocol and mode the VPN uses (ESP/AH and Tunnel/Transport).

There are some additional parameters that can be configured as part of Phase 2, and they might or might not be negotiated as part of the Quick mode process.

Proxy ID negotiation

A proxy ID is a mechanism for identifying the traffic carried within the VPN, and it contains two components: the local and remote IP prefix, and the service. Within IKE version 1, only a single prefix can be defined per local and remote IP value, along with a single service.

Strictly speaking, the proxy IDs do not really need to match the traffic at all, but both parties must match what they are negotiating in the VPN. Proxy IDs have long been considered a nuisance when configuring VPNs because they are not really needed, and in large part because different vendors have determined the proxy IDs differently. There is an exception to this that was supported in ScreenOS (multiple proxy IDs), but this isn’t supported today in the SRX.

The issue is that the proxy IDs are defined within the IKE RFC, which strictly defines how they are formatted and what they contain. However, the RFC doesn’t exactly state how the proxy IDs should be derived, and therefore vendors have interpreted this differently. Ultimately, this has caused interoperability issues when trying to establish VPN tunnels, so be advised that some tuning might be required.

IKE Version 2

IKE version 2 is the successor to the IKEv1 method. There are some challenges with the IKEv1 protocol, particularly when it comes to interoperability, in large part because it evolved over a long period of time with so many different parties. There is a plethora of different RFCs that make up aspects of IKEv1, and anyone who has done large-scale VPN concentrator projects with multiple vendors can speak of the horrors of getting these implementations up and running properly.

There is not technically Phase 1 and Phase 2 of IKEv2 like there is for IKEv1, but rather there are four exchanges (in a request/response format) that occur to negotiate an IPsec tunnel with IKEv2. In reality, only the first two are necessary, and the second two can happen to extend the IPsec relationship.

IKE-SA-INIT

This exchange negotiates the security attributes that will be used to establish the IPsec tunnel. This includes exchanging the protocols/parameters used, NONCE values, and Diffie-Hellman groups.

IKE-AUTH

Each peer establishes or authenticates their identities. At this stage, the IPsec tunnel is established.

CREATE_CHILD_SA

This allows the peers to create additional security associations between each other, similar to how multiple proxy IDs function in IKEv1.

INFORMATIONAL

Allows the peers to perform some housekeeping functions, including peer liveliness detection, removing SA relationships, and reporting error messages.

It’s important to understand that IKEv2 just defines the method by which the IPsec tunnels are negotiated; it doesn’t directly impact the type of encryption or authentication that is used to secure the actual transit traffic itself. In fact, from a configuration perspective on the SRX, there are virtually no differences between configuring an IKEv1 versus IKEv2 tunnel other than the explicit configuration of the IKE version that is defined in the gateway configuration.

IKEv1 versus IKEv2

So what are some of the challenges with IKEv1 that spurred the introduction of IKEv2? As we mentioned, there are many RFCs for IKEv1-related functionality like NAT-T, DPD, route-based VPNs, certificate support, proxy ID support, and a lack of any ability to extend IKEv1 without crafting entire new mechanisms. In addition, IKEv2 has a much more streamlined negotiation process that is much less prone to DoS attacks, which are well known in IKE negotiations. For instance, an attacker can attack an IKEv1 gateway by spoofing the first IKE packet and consuming resources on the IKE gateway without IKE having a good way to validate that the incoming message is authentic. IKEv2 builds in a cookie negotiation similar in ways to a SYN Cookie to ensure that the peer is a valid peer before wasting resources on the negotiation until the host is validated. Also, there are some ambiguous aspects of IKEv1 that different vendors have implemented differently and this has led to incompatibility issues.

Additionally, in many cases with IKEv1, negotiations would fail because of a lack of exact match. IKEv2 goes a long way to support flexibility in the negotiations to allow gateways to propose certain attributes or values. IKEv2 can also be much more proactive and require much less state than IKEv1 to be maintained.

So why not always use IKEv2? If you can, it’s certainly not a bad thing. IKEv2 hasn’t seen quite as widespread of a deployment as IKEv1, including for IPv6, so you might be limited to falling back to IKEv1 unless you control all of the IPsec hosts or can mandate IKEv2 support. IKEv2 is also preferred in large environments with numerous spoke sites because it is faster to negotiate than IKEv1, although the actual encryption itself doesn’t become any easier; just the setup phases occur with less overhead on the peers.

Note

The full implementation details of IKEv1 and IKEv2 can be viewed in their respective RFCs online (IKEv1 has several, but primarily 2407, 2408, and 2409; IKEv2 is RFC 4306).

IPsec VPN Protocol

Two different VPN protocols can be used for IPsec VPNs, regardless of what IKE parameters are used to establish the VPN. The two protocols are ESP and AH.

ESP

This performs encryption and authentication on the traffic within the VPN, thus protecting the confidentiality of the traffic within the VPN. It also authenticates the data within the VPN, ensuring that it has not been modified and that it originated from the correct source.

AH

This protocol does not encrypt the traffic within the VPN, but simply authenticates the traffic to ensure that it came from the correct source and has not been modified.

ESP is much more widely deployed than AH, because typically, organizations want to ensure that data originated from the correct location and that it wasn’t modified (they might also want to ensure that the data is confidential). Because additional effort is not required to configure the encryption on the VPN gateway, most network administrators or organizations simply encrypt and authenticate. Note that additional processing must take place to perform both the encryption and the authentication, so ESP might not perform as well as AH, but the security benefits of ESP far outweigh any performance impact it might have.

IPsec VPN Mode

In addition to the choice of VPN protocol, there are two different modes that determine how the traffic is exchanged in the VPN.

Tunnel mode

Tunnel mode encapsulates the original IP packet within another packet in the VPN tunnel. This is most commonly used when hosts within separate private networks want to communicate over a public network. Both VPN gateways establish the VPN tunnel to each other, and all traffic between the two gateways appears to be from the two gateways, with the original packet embedded within the exterior IPsec packet. Note that whether the original packet is encrypted depends on whether ESP or AH mode has been selected. ESP encapsulates, encrypts, and authenticates the original Layer 3 through Layer 7 IP traffic, whereas AH only encapsulates and authenticates the original Layer 3 through Layer 7 IP traffic.

Transport mode

Transport mode does not encapsulate the original packet in a new packet, like Tunnel mode does; rather, it sends the packet directly between the two hosts that have established the IPsec tunnel. Depending on whether ESP or AH mode is used, the data is either encrypted and authenticated, or just authenticated. This includes encryption and authentication for Layer 4 through Layer 7 in ESP mode, or just authentication for AH for Layer 4 through Layer 7 of the original IP packet.

Tunnel mode is the most common VPN mode on the Internet because it easily allows entire networks (particularly those with private address space) to communicate over public IP networks. Transport mode is primarily used when encrypting traffic between two hosts to secure communication where IP address overlap is not an issue (e.g., between a host and a server on a private network). Today, the SRX only supports Tunnel mode and does not support Transport mode.

IPsec Manual Keys

In certain situations, IKE negotiations are not preferable. Although an individual IKE negotiation might not require too many resources to establish, setting up hundreds or thousands of VPNs per second can be very difficult due to the key generation that must take place for each VPN. Another non-IKE-preferred scenario is when an organization does not want the keys to expire.

Manual keys aren’t that popular these days except in very narrow situations, so they are outside the scope of this book, but are supported by the SRX.

IPv6 and IPsec on the SRX

At the time of writing this book, IPv6 support for IPsec on the SRX is still a bit lacking, even compared to the legacy ScreenOS platforms. This has largely been due to a slower than expected transition of features from ScreenOS to Junos, so IPv6 was delayed while other mission-critical IPv4 features were implemented. The good news is that this is all changing, and quickly. In fact, at the time of writing this book, the first major phase of IPv6 support for IPsec is in beta testing (well, technically, IPv6 IPsec support does already exist on the branch SRX for policy-based VPNs, but it’s a very narrow use case). Moving forward, you should start to see the widespread implementation of these features, so keep current on the release notes.

The good news when it comes to IPv6 versus IPv4 in IPsec is that they are nearly identical from an implementation standpoint. For the most part, it’s simply a matter of plugging in an IPv6 address for an IPv4 address and you should be good to go, so all of the concepts that we are covering here still apply.

IKE Negotiations

Now that you know a little more about how the VPN negotiation takes place, let’s drill down into a detailed discussion and break down the individual components of Phase 1 IKE negotiation.

IKE Authentication

A few pages back you learned about Phase 1 IKE negotiations for IKEv1 and IKE_INIT_SA for IKEv2. These negotiations only provide the ability to establish a secure channel over which two parties can communicate—you still need to define how they should authenticate each other. This is where IKE authentication is used to ensure that the other party is authorized to establish the VPN.

IKE authentication comes in two forms: preshared key (password) and certificate authentication.

Preshared key authentication

The most common way to establish a VPN connection is to use preshared keys, which is essentially a password that is the same for both parties. This password must be exchanged in advance in some out-of-band mechanism, such as over the phone, via a verbal exchange, or via less secure mechanisms, even email. The parties then authenticate each other by encrypting the preshared key with the peer’s public key, which was obtained in the Diffie-Hellman exchange.

Preshared keys are commonly deployed for site-to-site IPsec VPNs, either within a single organization or between different organizations. Preshared key authentication is popular because the keys do not require the overhead of certificates, and many administrators are much more familiar with passwords than they are with certificates. To ensure that preshared keys are used in the most secure fashion, a preshared key must consist of at least 8 characters (12 or more is recommended) using a combination of letters, numbers, and nonalphanumeric characters, along with different cases for the letters (i.e., the preshared key should not use a dictionary word). An example of a complex password is H7bK1Mc2$#cNa.

When using nonalphanumeric characters, make sure they are not special characters which could be mistaken by some OSs. A common example is the question mark (?), which can typically trigger a CLI to think the user is requesting context-sensitive help. Although most OSs support the use of a control sequence, some do not, so you might want to avoid using a control sequence if you are unsure whether the peer supports it.

Certificate authentication

Certificate-based authentication is considered more secure than preshared key authentication because the certificate key cannot be compromised easily (as can a weak preshared key). Certificates are also far more ideal in larger scale environments with numerous peer sites that should not all share a preshared key. In addition, optional mechanisms can be used within certificate authentication to ensure that a certificate is still valid. Finally, certificates are not easily vulnerable to visual eavesdropping, like a preshared key might be, although certificates can still be compromised if access to the filesystem on which they are stored is obtained.

Certificates are composed of a public and private key, and can be “signed” by a master certificate known as a certificate authority (CA). In this way, certificates can be checked to see if they are signed with a CA that is trusted. Certificates can also be revoked should they be compromised, or if they expire (as certificates are generated with an expiration date, although there is no standard time frame for generated certificates).

The many aspects of certificate-based authentication could fill an entire book, so all the intricate details of this form of authentication are not covered here. For the purposes of this chapter, we expect you to have a working understanding of Public Key Infrastructure (PKI), including certificates, CAs, and the technologies that deliver these capabilities. Later in this chapter we discuss the configuration specifics on the SRX to get you working with this technology.

IKE Identities

You can think of the IKE identity as the username that is associated with the authentication method (preshared key or certificate). Although that isn’t exactly the purpose of this feature, IKE identity performs a similar functionality.

The SRX platform supports a few different types of IKE identities, and you can use them to verify the identity (along with other attributes such as the preshared key or certificate) of the remote party.

IP address

The most common form of IKE identity for site-to-site VPNs is the IP address. Typically, this is automatically derived from the configuration of a peer gateway, by using the IP address. IP addresses are not commonly used for remote access VPNs because the client IP address is typically not static, but there is nothing technically wrong with using an IP address for the client IKE identity. This can be either an IPv4 or IPv6 address.

Hostname

The hostname, or fully qualified domain name, is essentially a string that identifies the end system. This does not strictly have to match the actual FQDN of the end system; however, this is recommended for ease of management.

User FQDN

A user FQDN (UFQDN) is also known as a user-at-hostname. It is a simple string that follows the same format as an email address: [e-mail]. Note that this doesn’t have to match the user’s actual hostname; however, it is recommended that you use the same email address as the user’s actual email address for ease of management.

Distinguished name

The distinguished name (DN) is the full name that is used in certificates to identify a unique user in a certificate. An example of a DN is “CN=user, DC=company, DC=com,” the ASN.1 encoding standard.

IKE-ID

This supports either a shared or group IKE ID that can be used among many different peers. These are common when using Auto-VPN and Remote Access scenarios.

When using site-to-site VPNs, the most common type of IKE identity is the IP address, assuming that the host has a static IP address. If the host does not have a static IP address, a hostname can be used. When a dial-up remote access client (rather than a gateway) is used, a UFQDN is the most common IKE identity. If certificates are used, the DN or a subset of the name can be used to identify the users of an organization or a unit of the organization.

Flow Processing and IPsec VPNs

It is important to understand where IPsec processing of traffic happens in the traffic processing chain. When a session is created on the SRX (as discussed in Chapter 8), we perform all of the flow processing steps, which includes services at the end of the processing chain. If a flow is destined for a VPN (whether it is route- or policy-based) the traffic will be sent into the VPN as one of the last steps in the processing chain (just before actually sending the traffic out of the physical media itself). Placing the VPN at the end of the processing chain allows other services to take place on the plain-text traffic (e.g., UTM, IPS, NAT, ALG, etc.) and the reverse operation can happen after the traffic is decrypted, returning from another IPsec peer. If the VPN is not already established when the traffic is destined for a VPN peer, the SRX will queue the traffic while it establishes the VPN and then will send it out as soon as the VPN is established—or drop it if the VPN cannot be established. Just like clear-text traffic, VPN-bound traffic is fully flow-aware (and is enforced by flow processing). The IPsec tunnel is just an abstraction layer on top of the standard flow processing itself.

SRX VPN Types

Two types of VPNs can be configured on the SRX—policy-based VPNs and route-based VPNs—and their underlying IPsec functionality is essentially the same in terms of traffic being encrypted. It’s the implementation that’s different and that can be used to leverage administrative functionality.

Note

Not all vendors provide both policy- and route-based VPNs. However, there are no compatibility issues with running a policy-based VPN to a route-based VPN. There is one exception: when running dynamic routing protocols such as Routing Information Protocol (RIP), OSPF, IS-IS, or PIM on the VPN, only route-based VPNs can be used.

Policy-Based VPNs

Policy-based VPNs utilize the power of a firewall security policy to define what traffic should be passed through a VPN. Policy-based VPNs allow traffic to be directed to a VPN on a policy-by-policy basis, including the ability to match traffic based on the source IP, destination IP, application, and respective to- and from-zones. When using policy-based VPNs, the action of “Tunnel” is used, which implies that the traffic is permitted along with defining the VPN to be used in that policy. Additional policy processing such as application services (IPS, URL filtering, antivirus, logging, etc.) can be used in policy-based VPNs.

When using policy-based VPNs, the proxy IDs are derived from the firewall policy that is used. The policy’s source address maps to the proxy ID’s local ID, the destination address maps to the remote ID, and the service maps to the application for traffic that is destined for the tunnel (to be encrypted; e.g., Trust to Untrust). In the case where traffic is arriving encrypted from the VPN (to be decrypted; e.g., Untrust to Trust) the proxy ID source address will be the remote ID, the destination address is the local ID, and the service is the application.

Determining the Proxy IDs on Policy-Based VPNs

When address object sets, or multicelled source or destination addresses, are used, the respective IDs will be negotiated as 0.0.0.0/0. In the case of service, when either an application set or multicelled applications are used, the service will be negotiated as Any. Although the same proxy ID can be used multiple times on the platform, it can only be defined once per VPN endpoint. For instance, if three different VPNs negotiate the proxy IDs as Local: 0.0.0.0/0, Remote 0.0.0.0/0, and Service Any, that is fine; however, the same VPN can only have this once. If it is defined multiple times for a single VPN, the SRX will issue a commit error due to the overlapping proxy IDs. Proxy IDs can be manually hardcoded by the administrator for the VPN rather than being derived automatically from the policies. The main thing to take away is how the proxy IDs can be derived, as the proxy IDs must match on both sides for VPN negotiation to be successful.

With policy-based VPNs, you can override the proxy IDs that are derived from the policy by defining them (like you would with route-based VPNs) in the Phase 2 configuration. We discuss the configuration for defining the proxy IDs later in this chapter.

Policy-based VPNs are primarily used for simple site-to-site VPNs and for remote access VPNs. For more advanced needs, route-based VPNs should be considered.

Route-Based VPNs

The alternative to policy-based VPNs is route-based VPNs. Route-based VPNs use a virtual interface known as a secure tunnel interface (st0 interface) in which all traffic routed into the interface will be sent into a VPN. The traffic is directed into the interface just like any other traffic decision through the use of routing, hence the term route-based VPN. Route-based VPNs still have a secure policy applied to them; however, the security policy does not use the action of Tunnel, but rather the action of Permit. The routing decision causes the traffic to be sent into the VPN. The interesting part of route-based VPNs is that they can be used to leverage advanced features such as use of dynamic routing protocols. Dynamic routing protocols allow easier administration and the ability to fail traffic over to different links. Note that dynamic routing is not required for route-based VPNs; static routes will work just fine as well.

The negotiation of proxy IDs for route-based VPNs is relatively simple. Because they must be manually defined for each VPN, they are not derived from a policy or other source. Just like policy-based VPNs, only a single proxy ID combination can be used per VPN; however, proxy IDs from different VPNs can overlap.

The st0 interface must be configured within a security zone just like any other logical interface. Versions older than 11.1 had limitations of what VR the IPsec VPN could be terminated in, and what VR the st0 interface could be placed in, but these are no longer limitations with contemporary versions of Junos.

Numbered versus unnumbered st0 interfaces

In a point-to-point VPN configuration, the st0 interface can function similarly to a Point-to-Point Protocol (PPP) interface in that it doesn’t have to be numbered (configured with an IP address) because there are only two hosts on the communication channel (the IPsec VPN). If you use an unnumbered interface, you will essentially borrow the IP address of another interface rather than using an explicit IP address for the interface itself. Typically, it is a good idea to just configure IP addresses on the interface rather than using unnumbered interfaces. You can always use private IP addressing within the IPsec VPN because, as the name implies, it is private. Not only is it encrypted, but also the actual network within the IPsec tunnel is not impacted by the IP addressing of the network it is running over.

Point-to-point versus point-to-multipoint VPNs

Route-based VPNs offer two different types of architectures: point-to-point and point-to-multipoint. Point-to-point VPNs map a single VPN to a single logical interface unit, so the SRX connects directly to a single peer VPN gateway on the interface. Point-to-multipoint VPNs allow the device to connect to multiple peer gateways on a single logical interface.

An important design consideration to make when building a VPN infrastructure is when to use point-to-point and when to use point-to-multipoint. Point-to-point VPNs are an obvious design decision when only a single peer needs to be connected; when multiple peers need to be connected, point-to-multipoint should be considered.

Point-to-multipoint also has the advantage of conserving IP subnets along with the number of logical interfaces that are used. For example, in the case of point-to-point VPNs, an IP subnet and logical interface must be used for each VPN. When only a few VPNs are used, the consumption of IP subnets and logical interfaces might not be much of a concern. However, when thousands of VPNs are used, platform limits could occur with point-to-point VPNs.

On the other hand, point-to-point VPNs have the advantage of being able to define each logical interface to a separate zone, whereas point-to-multipoint VPNs are all part of the same zone. Note that even when point-to-multipoint is used, each VPN can still be segmented by security policies, as intrazone blocking is hardcoded into each zone.

Note

Typically, when connecting to other trading partners that are not part of your organization, point-to-point rather than point-to-multipoint VPNs should be used.

Special point-to-multipoint attributes

It is important to understand that point-to-multipoint VPNs require additional configuration to be supported. First, on the hub’s st0 interface, you must also specify that it is a multipoint interface, as shown in the following output:

[edit]
root@SRX5800-1# show interfaces st0
unit 0 {
    multipoint;
    family inet {
        address 192.168.100.5/24;
    }
}

Also, if you are using auto Next-Hop Tunnel Binding (NHTB), no additional configuration is required; if your peer device doesn’t support auto NHTB, you must manually specify these entries, as shown in the following output. If you do not specify this information, your point-to-multipoint VPN will not be able to properly establish and route traffic accordingly.

[edit]
root@SRX5800-1# show interfaces st0
unit 0 {
   multipoint;
   family inet {
      next-hop-tunnel 192.168.100.1 ipsec-vpn East-Branch;
      next-hop-tunnel 192.168.100.2 ipsec-vpn West-Branch;
      next-hop-tunnel 192.168.100.3 ipsec-vpn South-Branch;
      address 192.168.100.5/24;
    }
}

Point-to-multipoint NHTB

Point-to-multipoint VPNs allow you to bind multiple VPNs to a single interface on the hub. For this to work properly, the SRX must know not only which VPN to send the traffic into on the st0 interface to which it is bound, but also which next-hop will be used for routing that traffic on the interface. To accomplish this, the SRX uses a mechanism called an NHTB table on the interface to map all of this information.

On the SRX, if you are going to another SRX or ScreenOS device and you are using static routing, the SRX can automatically exchange the next-hop tunnel information with the peer as part of the optional vendor attribute exchanges in Phase 2 (also known as auto NHTB). If you are not using an SRX or ScreenOS device, and the peer doesn’t support these attributes (it should just ignore them), you will need to manually enter the table mappings to show what the next-hop should be (also known as manual NHTB). Alternatively, if you are using a dynamic routing protocol (e.g., RIP, OSPF, or BGP), you will not need to make a manual mapping entry because the SRX can build the table automatically from the routing updates matching the next-hop to the tunnel it came out of.

Which should you use: Policy- or route-based VPN?

This is an obvious question that probably came up as you read through the last section. In general, route-based VPNs are the way to go because they have better feature support with the SRX, including NAT and enhanced Level 7 support. Policy-based VPNs should only be used in some dial-up VPN scenarios (which have largely been alleviated with Junos 12.1X45+) and for some vendor compatibility purposes. If you don’t have an explicit reason to use policy-based VPNs, we suggest that you default to route-based VPNs.

Other SRX VPN Components

There are several other VPN components of the SRX platform, many of which are optional enhancements, although some happen automatically and can be altered manually if desired. It is important to have a thorough understanding of the individual features before enabling them, because enabling the features incorrectly could lead to undesirable effects. Knowledge is power, especially with a powerful device such as the SRX.

Dead Peer Detection

One particular issue that IKE does not account for is sudden failure of the VPN peer during communication. Because the VPN gateway is not typically initiating traffic (except in the case of dynamic routing protocols), it typically doesn’t notice if or when the VPN has failed, at least not until the IPsec keys expire and the VPN needs to be renegotiated.

To help improve the detection of such failures, the standards-based feature DPD can be implemented. DPD essentially sends a UDP message at defined intervals, and if messages are not responded to, the peer is considered to be down. Using DPD, a gateway can perform some alternative action such as defaulting to another VPN whenever a failure is detected.

Note

DPD is primarily used with VPNs where dynamic routing is not used (e.g., OSPF), because dynamic routing protocols can both detect a failure and default over to another path without the need for DPD.

VPN Monitoring

One issue with DPD is that it doesn’t necessarily mean the underlying VPN is up and running, just that the peer is up and responding. VPN monitoring is not an IPsec standard feature, but it utilizes ICMP to determine if the VPN is up. VPN monitoring allows the SRX to send ICMP traffic either to the peer gateway or to another destination on the other end of the tunnel (e.g., a server), along with specifying the source IP address of the ICMP traffic. If the ICMP traffic fails, the VPN is considered down.

An SRX VPN monitoring option, called Optimized, sends only the ICMP traffic through the tunnel when there is an absence of user traffic. If user traffic is traversing the tunnel, the SRX assumes it to be up and does not send the ICMP messages. If the traffic ceases, the SRX starts sending the ICMP messages until user traffic begins again.

Note

Even though VPN monitoring is not an IPsec standard feature like DPD, it can be used with other vendors’ devices and does not require the VPN peer gateway. You can think of VPN monitoring as Track IP specifically designed for VPNs.

XAuth

XAuth is an SRX feature that allows extensible authentication to IPsec VPN negotiation. XAuth actually takes place between Phase 1 and Phase 2 processing, and is a standards-based feature. Typically, XAuth is used with client remote access VPNs to provide further authentication, such as authentication to a corporate directory service such as Active Directory, which IKE does not allow. However, it can also be used for advanced IPsec authentication between two gateways, such as Zero Touch Hub/Spoke style deployments. XAuth is used in addition to the authentication that takes place in IKE Phase 1.

NAT Traversal

One issue with terminating IPsec remote access clients on VPN gateways in contemporary networks is that often the users are located behind a device that performs source NAT. When performing source NAT on IPsec traffic, a device can modify the source address and UDP port in the packet and therefore make the hash (which was calculated on the original packet) invalid. To help resolve this common scenario, NAT Traversal (NAT-T) was created.

NAT-T encapsulates the original ESP or AH traffic in an additional UDP packet. When the VPN gateway receives the UDP traffic, it will simply decapsulate the ESP or AH packet from the UDP layer.

NAT-T also uses UDP port 4500 (by default) rather than the standard UDP port 500 (which is only used for IKE negotiations, not ESP or AH), because the VPN gateway might try to process the traffic as IKE rather than as actual data traffic that is to be processed. NAT-T works with either ESP or AH and with either Tunnel or Transport mode.

On the SRX, NAT-T support is enabled by default and must be explicitly disabled on a VPN-by-VPN basis. It’s recommended that you enable NAT-T whenever remote access VPNs are deployed.

Note

The SRX has greatly extended the NAT-T support starting with Junos 11.4r4+. In the past, there used to be many aspects of NAT-T that weren’t supported depending on where the peer was set up and how it was connecting to the SRX. If you are using NAT-T, it is best to use Junos 11.4r4+ for maximum interoperability.

Anti-Replay Protection

One liability of IPsec VPNs is that an attacker can capture valid packets and replay them into the network to try to confuse the VPN gateway or remote host. Although the attacker cannot determine the contents of the IPsec message, he might be able to cause a DoS attack by injecting the traffic.

IPsec protects against this method of attack by using a sequence of numbers that are built into the IPsec packet—the system does not accept a packet for which it has already seen the same sequence number. Each sequence number is unique and is not based on the original data packet itself, but is maintained by the gateway; even in the case of TCP retransmissions, the sequence number is different. If the remote gateway sees a packet with a duplicate sequence number, it is considered to be replayed.

If Anti-Replay protection is enabled, and a duplicate is seen, the packet is dropped and a log message is generated. If Anti-Replay protection is not enabled, the traffic is processed (decrypted), although other security features such as stateful firewall, ALGs, and IDP might drop the decrypted packet later in the processing chain.

Note

Anti-Replay protection can be enabled independently on each side of the VPN. Because the IPsec messages always contain the sequence number, the option for Anti-Replay is essentially whether or not the VPN gateway monitors the connection to determine the existence of a replayed packet.

Fragmentation

Data networks enforce maximum sizes for frames and packets. Originally, on multiaccess networks that shared a collision domain (e.g., systems connected by an Ethernet hub), use of data sizes that were too large greatly increased the likelihood of collisions, so limits were placed on packet size to optimize packet processing.

Collisions weren’t the only issue with regulating frame size, because when packets were too large, small packets could be delayed for processing behind larger packets, and systems couldn’t be optimized for efficient packet processing.

Maximum Transmission Unit (MTU) and Maximum Segment Size (MSS)

MTU can refer to the size of a Layer 2 frame or the size of a Layer 3 packet (depending on the vendor). Juniper refers to the MTU as the complete Layer 2 frame, including the header. Standard Ethernet uses an MTU of 1,500 bytes of Layer 3 (including the IP header, Layer 4 header, and data), along with the 14-byte Ethernet header, for a total of 1,514 bytes. The IP header takes up 20 bytes, and the Layer 4 header (either TCP or UDP) will take up 20 bytes. This means that with a 1,514-byte Layer 2 MTU, and 54 bytes of Layer 2 through Layer 4 headers, there can be 1,460 bytes of user data. Note that different media can employ different MTU sizes; for example, the SRX can support Ethernet jumbo frames of up to 9,192 bytes.

Fragmentation comes into play when a packet is sent that is too large to meet the constraints of the underlying transmission medium’s MTU. When a network device receives a packet that is too large to be transmitted on the egress transmission medium, it has a choice of either fragmenting the packet (chopping the packet into smaller messages) or dropping the packet.

It is common to employ fragmentation in VPN processing because there is additional overhead in the messages sent over the VPN, including the ESP or AH header, and in Tunnel mode the original packet is encapsulated in another IP packet. Furthermore, in remote access VPNs with NAT-T, the packet is encapsulated yet again in a UDP packet. So, when a gateway receives the original packet, if it is 1,500 bytes, all of the additional overhead of the IPsec headers will make it too big to be sent over a standard 1,514-byte Ethernet network. In this case, the gateway must fragment the packet or drop it.

When configuring an SRX VPN, it is important to be cognizant of the underlying MTU and the MSS that is derived from the MTU (MTU – Layer 4 header overhead = MSS).

There is also an option for processing the Don’t Fragment (DF) bit in IP messages—the bit can be ignored, set, or cleared when processing the original packet.

Differentiated Services Code Point

Differentiated Services Code Point is an eight-bit field in an IP header that helps to classify the packet from a QoS perspective so that network devices can properly provide the appropriate precedence when processing the packet. DSCP bits don’t force the network devices to provide a certain level of service, but they can be leveraged to do so.

The SRX automatically copies the DSCP bits from the original packet to the IPsec packet so that the network devices between the two VPN gateways can provide the appropriate processing on the encrypted traffic.

IKEv1 Key Lifetimes

Keys are generated in both Phase 1 and Phase 2 IPsec. The keys in Phase 1 are generated to create a secure channel for the Phase 2 keys to be negotiated. The Phase 2 keys are the keys that are used to negotiate the user traffic. In both Phase 1 and Phase 2, the keys are considered active for a certain period of time, known as the key lifetime. Phase 1 is always negotiated as a period of time, but Phase 2 can be either a period of time or a certain amount of data that is transmitted in kilobytes. Key lifetimes are important because the longer that keys are active, the more potential there is for compromised security. That isn’t to say that IPsec is insecure—quite the opposite; however, the longer the same keys are used, the more potential there is to determine what those keys are and decrypt the content that is transmitted. Again, when properly configured, this is not a major concern, but something to keep in mind when selecting key lifetime.

Note

Each phase allows the ability to configure the key lifetime for that individual phase. The shorter the lifetime, the more often the keys are renegotiated. Although renegotiating often provides some security advantage, it can be costly from a performance perspective on the VPN gateways when operating on a large scale. IKEv2 doesn’t require key lifetimes to be set, as the peers can alter the state of the VPNs at any time.

IPsec does not have any official default timers for IPsec key negotiation but uses default key lifetimes (if not explicitly defined) of 86,400 seconds for Phase 1 and 3,600 seconds for Phase 2. This means Phase 2 times out before the Phase 1 key lifetime, which is an ideal event because only the keys in Phase 2 are used to encrypt the actual data, whereas the Phase 1 keys are only used to create a secure channel to negotiate the Phase 2 keys.

Note

It’s important to understand that different vendors’ devices might choose different key lifetimes, and that sometimes a mismatch in key lifetimes could cause VPN establishment issues and even stability issues, so it’s important to match the values wherever possible.

Network Time Protocol

Network Time Protocol is not a strict requirement for IPsec VPNs, but there is good cause for enabling it. First, the obvious need is to have the time properly synchronized for many reasons related to management (timestamps, schedulers, etc.), so this is just a best practice in general. But also, for IPsec with certificates, it is especially important because certificates are dependent on accurate time to ensure that they have not expired. If the time is not synchronized, this could make the SRX think the certificate has expired (or has been generated for a future time) when in reality it hasn’t. Finally, the less obvious reason pertains to the high-end SRX. The high-end SRX is a distributed processing system with SPUs that operate independently. This also means they might not maintain the same time, and this can create some issues, particularly with VPNs and retrieving information from the SPUs. To ensure no issues, you should always enable NTP on the platform to ensure that the SPUs are synchronized (because the route engine will sync the time down to the SPUs when NTP is enabled).

Certificate Validation

One of the strengths of certificate-based IPsec authentication is that the certificate can be revoked should it be compromised in any way, in addition to the SRX being able to validate the certificate itself to ensure that it has been signed by the correct CA certificate. By default, if you only upload the CA certificate to the SRX, the SRX can only determine whether the proposed certificate is signed by the CA certificate; it cannot determine whether the certificate had been revoked or is on hold. A certificate on hold is not permanently revoked, but in this state it cannot be used for authentication. To determine if the certificate has been revoked, the SRX must poll the CA itself to determine which certificates have been revoked. Typically, there are two ways to do this: via certificate revocation lists (CRLs) or via Online Certificate Status Protocol (OCSP).

CRL

With this method, the SRX will poll the CA for a list of all of the serial numbers of the revoked or on-hold certificates. Typically, this is done either manually or on a periodic basis. When the SRX needs to validate a certificate, it will then check to make sure the certificate is signed by the CA, and if that succeeds, it will check the CRL to see if it includes the proposed certificate’s serial number. If the serial number is not on the CRL, the certificate will be considered valid; if it is on the CRL, the certificate will be considered revoked and the authentication will fail. Also note that a certificate that is expiring will not be on the CRL, although it will be considered invalid if it has expired. Furthermore, the CRL itself has a lifetime that can be used to ensure that the CRL is not valid after a long period of time.

At the time of this writing, the SRX supports CRL collection via HTTP or Lightweight Directory Access Protocol (LDAP). If configured to use CRL checking, the SRX will try to download the CRL that is specified in the CA certificate itself, and if that fails, the SRX will follow the configuration, which specifies the CRL path.

OCSP

OSCP is currently in beta at the time of writing this book. It is primarily used to authenticate X.509 certificates similar to CRL checking, but is slightly different in a few ways. First, it doesn’t need to download the entire CRL (which is good when the CRL grows very large), but instead queries the OCSP server to determine if an individual certificate is valid, revoked, or on hold. Next, OCSP can query for certificate status in real time, on an as-needed basis. This also helps to ensure that certificates have not expired between CRL polling periods. Finally, OCSP can cache individual certificate authentication responses rather than having to poll for each certificate every time (within a timeout; e.g., 10 minutes).

Simple Certificate Enrollment Protocol

When using large-scale certificate deployments, the simple task of deploying and managing certificates can become a nightmare very quickly. To help alleviate the management needs of large-scale certificate environments, the SRX supports the use of Simple Certificate Enrollment Protocol (SCEP). SCEP is used on SRX devices to reach out to the CA for certificate-related management tasks. These include initial certificate enrollment (get the initial client certificate on the SRX), client certificate renewal, CA certificate renewal, and the ability to get new certificates before the old ones expire. The CA is typically software that runs on a server such as Microsoft Certificate Authority or INSTA-CA; other CAs are maintained by certificate signing organizations. When using SCEP, the SRX simply acts as a client to update its own certificates and CA certificates; it is not used to authenticate other certificates in the way that CRL or OCSP checking is.

Group VPN

Starting in version 10.2, the branch SRX Series devices support a VPN technology called Group VPN (also known by the Cisco implementation GETVPN), based on RFC 3547. Group VPN is intended to solve the issue of large-scale IPsec implementations that connect branch locations to central hub sites in a scalable and automated fashion over a private network such as MPLS/VPLS. The Juniper Group VPN solution is largely compatible with the Cisco GETVPN solution, because they are based on the same RFC. Covering Group VPN is outside the scope of this book (in part because thorough coverage of the feature is enough to fill a book in itself) but there are AppNotes and other available materials that cover this content.

Dynamic VPN

Dynamic VPN is a feature that is specific to branch SRX Series devices that allows client systems to create remote access VPNs that are terminated on the branch SRX Series gateways. Essentially, this provides a streamlined way to provision and connect users to an SRX over the Internet or other private network. The client that is installed on the user machine is downloaded from the SRX gateway’s web interface and is automatically installed. Then, when the user wishes to connect to the SRX, he simply does so by logging in to the SRX’s Dynamic VPN web interface, which triggers the VPN session on the user’s PC. The administrator does not need to provision any software or configuration, as this is automatically installed on the user’s system. Additionally, if upgrades to the client are required, this is automatically performed without the need for administrative intervention.

It is important to understand a few things when it comes to Dynamic VPNs. The following limitations exist at the time of this writing:

• To use the Dynamic VPN feature, you must purchase and install licenses for the clients. This isn’t a limitation on the number of clients, but rather the number of clients that can connect at the same time. See the datasheets for more information on platform-specific limits.

• The Dynamic VPN client can only use IPsec to create a secure connection to the SRX. SSL support may come at a later point in time.

• Only Windows is supported by Dynamic VPN at the time of writing this book. The SRX can also provide the Junos Pulse package for the clients, and it is likely that it will be extended for other OSs in the near future, so stay posted to the release notes.

Selecting the Appropriate VPN Configuration

The previous sections of this chapter gave you a lot of information—some generalized, some SRX-specific. It’s time to make use of that information and provide you with some real-world guidance on how to select the appropriate properties for your SRX VPN configuration.

As you’ve come to realize by now, there are many different VPN configuration options. However, deciding which options to select is quite easy once you understand them. Here we’ll detail 12 key configuration options with recommendations and tips on when and where you might use them.

AutoKey IKE versus manual keys

The first decision you should make when determining how to deploy your VPNs is whether IKE will be used to negotiate the VPN keys or whether to use manual keys. For just about every scenario, AutoKey IKE should be used over manual key encryption because AutoKey IKE is dynamic and renegotiates the keys used rather than using the same key indefinitely. The only exception to this rule is if security isn’t much of a concern, due to the impact that AutoKey negotiation would put on your system. Although individual IKE negotiation might not put much load on the system, negotiating lots of VPN tunnels simultaneously can be very computationally intensive, making manual keys preferable.

IKEv1 versus IKEv2

We discussed the benefits of IKEv2 compared with IKEv1 earlier in the chapter. If both gateways support IKEv2 without any issues, then this would probably be the preferred version to select.

ESP versus AH

ESP is the most widely deployed VPN protocol because it not only performs authentication, but also provides security by encrypting the data. Although encrypting the data is a computationally intensive process, it typically can be offloaded by using some hardware acceleration. Therefore, unless there is a specific reason to only provide authentication, ESP should be used to provide both encryption and authentication.

Main mode versus Aggressive mode (IKEv1 only)

The rule of thumb when it comes to Main mode versus Aggressive mode is that if both nodes have a static IP address (or an address that can be resolved via DNS), Main mode should be used. However, if a gateway or host has a dynamic IP address, typically Aggressive mode should be used for the best interoperability (although depending on the implementation of the VPN gateways, Main mode might be able to be used).

Diffie-Hellman group number

Diffie-Hellman key exchange is used to negotiate Phase 1 and PFS aspects of IPsec. The larger the key, the more difficult it will be to compromise the security of the negotiation, but the more computationally intensive the negotiation will be. Typically, Diffie-Hellman Group 2 is considered secure at the time of this writing, although larger key lengths (e.g., Group 5, 14, etc.) are more secure, but might be unnecessary. Remember that Diffie-Hellman is used to negotiate the secure channel to negotiate the Phase 2 keys, but does not actually encrypt the data itself.

Preshared keys versus certificate authentication

As previously discussed, you can authenticate IPsec peers in two ways: via preshared keys and via certificates. Preshared keys are easier to deploy, and are the most common form of authentication. Certificates are a very powerful form of authentication, as you can scale them to large implementations and you can revoke certificates and authenticate certificates dynamically. Certificates do have a certain amount of overhead when it comes to generation, signing, checking status, and renewing, however, and therefore they are most commonly used for large implementations. When just using simple site-to-site VPNs, or VPNs between other organizations, preshared keys are easier to use. If you are deploying site-to-site or client VPNs within an organization on the scale of several hundred or several thousand, certificates should be examined, as they provide some scaling advantages.

If you are using certificates, you also need to determine what format or algorithm will be used to authenticate them. In the past, only DSA and RSA certificates were supported, but now with Suite B support the SRX also supports ECDSA certificates.

IKE identity

IKE identity is commonly overlooked as a major component of a VPN; however, it is important to select the appropriate IKE identity. The IKE identity essentially acts as the username for the IKE authentication in a roundabout way. Typically, when both sides of a site-to-site VPN have static IP addresses, the IKE identity is the IP address for both nodes. When a single node is using a dynamic IP address, that node typically uses the Hostname attribute, which can be a simple name to identify the peer. But when a user is connecting to a gateway, that user should use the UFQDN. It is important to make sure both sides can properly authenticate the other peer with the method that the other side is expecting, as a mismatch or improper IKE identity causes failure.

Note

Configure remote identity when you do not know the remote peer’s IP address. Configure local identity if you do not have a static IP address (e.g., your gateway uses DHCP).

VPN encryption algorithm

When selecting the VPN encryption algorithm, the important things to remember are the sensitivity of the data within the VPN, the amount of data sent over the VPN in terms of throughput, and whether the algorithm that is used will be accelerated by hardware. DES is largely considered to be an obsolete encryption algorithm by today’s standards because the key space is only 56 bits and it can be broken with modern computers in a few months’ time. 3DES and AES are widely considered to be much better algorithms and are secure against attacks with modern computer hardware. If the data is extremely sensitive and needs to be protected against attacks under extremely powerful computing power, both now and in the future, you should use an algorithm such as AES-256.

VPN authentication algorithm

The VPN authentication algorithm is used to create a hash of the traffic to ensure that it has not been modified or forged. Two hash algorithms are implemented in the SRX at the time of this writing: MD5 and SHA-1. SHA-1 is considered to be a stronger hash algorithm than MD5, and because both are implemented in hardware, it is recommended that you use SHA-1 rather than MD5, although MD5 isn’t necessarily an obsolete algorithm. The SRX now supports stronger authentication algorithms like SHA-256 and SHA-384.

Perfect Forward Secrecy

PFS is a mechanism used to renegotiate the Phase 1 keys over an established Phase 1 channel. It is primarily meant to help provide additional security to Aggressive mode authentication where the IKE identities are negotiated in clear text, but it can also be used to renegotiate Phase 1 for additional security. It is recommended that you use PFS when using Aggressive mode, or in the most sensitive of security environments, and it is very important to choose the correct preshared key (if you’re using preshared keys) along with the proper encryption and authentication algorithms.

Policy-based VPNs versus route-based VPNs

Policy-based VPNs are common when configuring simple site-to-site VPNs or remote access VPNs, especially when interoperating with VPN products from other vendors. When only a few VPNs are needed, or if the VPNs are simple, it might make sense to use policy-based VPNs because they are easier to set up and have fewer components (from a configuration perspective) than route-based VPNs. When you’re setting up a VPN infrastructure with a large number of remote access tunnels, or when multicast or dynamic routing protocols are used, you should use route-based VPNs. In general, route-based VPNs are more powerful than policy-based VPNs, so they are generally preferred over policy-based VPNs, but simple implementations can still use policy-based VPNs.

Predefined proposal sets versus custom proposal sets

To help ease configuration, the SRX has predefined proposal sets for both Phase 1 and Phase 2 IKE negotiations. You can choose to use these predefined sets or create your own. It is really just a matter of preference. There are three predefined proposals: basic, standard, and compatible. Typically, it is best to just define your own, as it takes the guesswork out of configuring the VPNs, especially if you are establishing a VPN to another vendor (which might not use the same terminology). Additionally, if you use predefined sets, you might have to go through several proposals with the peer before finding a match (which would leave a log trail as well), so it is best to just configure identical proposals as the peer.

IPsec VPN Configuration

Now that we have broken down the individual components of IPsec VPNs, let’s examine how to put these features into practice on the SRX with the configuration of a hub and spoke VPN.

Because certain aspects of VPNs can only have single attributes (e.g., preshared key or certificates, but not both), we cover some configuration elements that do not apply to our actual VPN infrastructure. Figure 10-6 shows a network diagram of the IPsec VPN infrastructure that is being implemented. We cover the various configuration elements in the order in which they should be configured, because certain elements reference other aspects of the configuration.

Figure 10-6. IPsec VPN infrastructure

Configuring NTP

Although we covered NTP configuration earlier in the book, it is a very important function of VPN, so we will reiterate how to configure it here. The following configuration assumes that you already have network connectivity and routing set up (you can also use domain names as your NTP servers, as long as you have DNS configured; also, note that the SRX will resolve the name and place it into the final configuration).

[edit]
root@SRX3600-1# set system name-server 4.2.2.2

[edit]
root@SRX3600-1# set system ntp server pool.ntp.org

[edit]
root@SRX3600-1# show system
host-name SRX3600-1;
domain-name jnpr.net;
name-server {
    4.2.2.2;
}
ntp {
    server 74.207.249.60;
}

Certificate Preconfiguration Tasks

When configuring your SRX for certificate authentication for Phase 1, you need to do several things before you can use certificate authentication to its fullest advantage (if you are using preshared keys only, this section does not apply).

In this example, we do the following to prepare our SRX for certificate authentication. Not all of these are strictly required, but to cover all of the common scenarios we include them in a single example.

• Generate a locally generated certificate called IPSEC.

• Create a CA profile called CAPROFILE. The CA profile should be configured to use CRL checking and to download the CRL from http://172.31.100.50 every two hours. The name of the CA server identifier is CASERVER.

• Configure SCEP to enroll a certificate to an SCEP server. SCEP should also be configured to automatically grab the CA certificate, reenroll the certificate before it expires, and download the new CA certificate before it expires. The SRX should retry every 3,600 seconds to download a new certificate.

• Use HTTP-based CRL checking to ensure that certificates proposed by the client are valid certificates that have not been revoked. This should be polled every two hours for an updated CRL.

root@SRX3600-1> request security pki generate-key-pair certificate-id IPSEC
Generated key pair IPSEC, key size 1024 bits

root@SRX3600-1> edit

[edit]
root@SRX3600-1# edit security pki ca-profile CAPROFILE

[edit security pki ca-profile CAPROFILE]
root@SRX3600-1# set ca-identity CASERVER revocation-check crl refresh-interval 2
url http://172.31.100.50

[edit security pki ca-profile CAPROFILE]
root@SRX3600-1# set enrollment retry-interval 3600

[edit security pki ca-profile CAPROFILE]
root@SRX3600-1# up

[edit security pki]
root@SRX3600-1# set auto-re-enrollment certificate-id CAPROFILE ca-profile-name
qqq challenge-password aaa re-enroll-trigger-time-percentage 10
re-generate-keypair

[edit security pki ca-profile CAPROFILE]
root@SRX3600-1# run request pki ca-certificate enroll ca-profile CAPROFILE

Fingerprint:
75:1b:2f:a7:95:bc:2e:3b:54:d0:71:ae:86:42:09:e2:cc:75:34:d1 (sha1)
C1:4d:cc:fc:8f:10:d2:04:e9:80:09:68:4c:01:bd:42 (md5)
Do you want to load the above CA certificate ? [yes,no]
## Enroll the Local Certificate to Microsoft SCEP Server##

[edit security pki ca-profile CAPROFILE]
root@SRX3600-1# set enrollment url http://172.31.100.50/certsrv/mscep/mscep.dll

[edit security pki ca-profile CAPROFILE]
root@SRX3600-1# run request security pki local-certificate enroll ca-profile
CAPROFILE
certificate-id qqq challenge-password aaa domain-name my.company.com
email [e-mail] ip-address 10.10.10.10 subject DC=company,
CN=SRX, OU=IT, O=my, L=sunnyvale, ST=california, C=us

Note

At the time of writing this book, only the Microsoft CA is fully qualified as a CA Server for functionalities like SCEP, but Juniper is working on extending this support including for other server types and OSCP. Stay tuned to the release notes and the documentation for a full set of CAs supported in the future.

Phase 1 IKE Configuration

Let’s begin with the Phase 1 configuration, which has several different configuration elements—some optional, some required—for proper IPsec establishment. The important thing to remember as part of the Phase 1 configuration is that Phase 1 is not actually used to encrypt the data within the VPN, but rather to establish the secure channel to negotiate the Phase 2 keys that will be used to establish the IPsec VPN.

One great thing about configuring VPNs in the SRX compared to ScreenOS is that the configuration is not immediately applied and can be altered without removing all instances of the configuration to edit elements. This means that as long as you don’t commit the configuration, these settings can be made in any particular order—an enormous advantage over ScreenOS and many other vendors’ products. Another major advantage is that Junos separates the Phase 1 elements into three areas: proposal, policy, and gateway. This is advantageous when multiple gateways use the same policy, proposals, or both, and allows for template-like functionality for VPNs.

Our Phase 1 IKE configuration follows this process:

1. Configure the elements of the Phase 1 proposal, which defines the encryption and authentication policies.

2. Define the Phase 1 mode, preshared key or certificate, and proposal.

3. Configure the actual Phase 1 gateway properties.

Configuring Phase 1 proposals

The Phase 1 proposal provides the framework for the encryption and authentication parameters that are used in policy and gateway functionality. All Phase 1 proposals are configured under the [security ike proposal <proposal-name>] level in the configuration hierarchy. In our example, we configure the following elements (they can be configured in any order within the Phase 1 proposal):

Authentication method

The authentication method defines whether preshared keys or certificates are used for Phase 1 authentication. Note that the rsa-signatures attribute signifies certificates using RSA key generation. This step does not refer to the authentication algorithm of Phase 1, but rather to how Phase 1 peers can authenticate each other.

Diffie-Hellman group

The Diffie-Hellman group defines which group or key length will be used for the Phase 1 keys. The larger the key, the more secure it is, but also the more computationally complex it is to establish.

Encryption algorithm

The encryption algorithm determines which algorithm will be used to encrypt the data within the Phase 1 secure channel. The SRX supports DES, 3DES, AES-128, AES-192, and AES-256, which are the most powerful (in that order) and the most demanding, although hardware acceleration makes this less of a concern. (Note that CBC stands for Cipher Block Chaining and it has to do with the fact that these algorithms are using block encryption rather than stream encryption, but it is not a detail that you need to be concerned with.)

Authentication parameter

The authentication parameter defines what authentication algorithm is used to ensure that data have been received from the correct VPN peer and that they haven’t been modified.

Key lifetimes

Key lifetimes determine how long the VPN keys are active until they expire, and then the VPN Keys must be renegotiated when Phase 1 needs to be renegotiated.

Configuration for Remote-Office1 proposal with preshared keys

Configure the following properties for the Remote-Office-PSK proposal:

• Preshared key authentication

• Diffie-Hellman Group 2

• 3DES-CBC encryption algorithm

• SHA-1 authentication algorithm

• Key lifetime of 86,400 seconds

[edit]
root@SRX5800#edit security ike proposal Remote-Office-PSK

[edit security ike proposal Remote-Office-PSK]
root@SRX5800#set authentication-method pre-shared-keys

[edit security ike proposal Remote-Office-PSK]
root@SRX5800#set dh-group group2

[edit security ike proposal Remote-Office-PSK]
root@SRX5800#encryption-algorithm 3des-cbc

[edit security ike proposal Remote-Office-PSK]
root@SRX5800#set authentication algorithm sha1

[edit security ike proposal Remote-Office-PSK]
root@SRX5800#set lifetime-seconds 86400

[edit security ike proposal Remote-Office-PSK]
root@SRX5800# show
authentication-method pre-shared-keys;
dh-group group2;
authentication-algorithm sha1;
encryption-algorithm 3des-cbc;
lifetime-seconds 86400;

[edit security ike proposal Remote-Office-PSK]
root@SRX5800#top commit

Configuration for Remote-Office1 proposal with certificates

Alternatively, configure the following properties for the Remote-Office-Cert proposal:

• Certificate authentication

• Diffie-Hellman Group 2

• 3DES-CBC encryption algorithm

• SHA-1 authentication algorithm

• Key lifetime of 86,400 seconds

[edit]
root@SRX5800#edit security ike proposal Remote-Office-Cert

[edit security ike proposal Remote-Office-Cert]
root@SRX5800#set authentication-method certificates

[edit security ike proposal Remote-Office-Cert]
root@SRX5800#set dh-group group2

[edit security ike proposal Remote-Office-Cert]
root@SRX5800#encryption-algorithm 3des-cbc

[edit security ike proposal Remote-Office-Cert]
root@SRX5800#set authentication algorithm sha1

[edit security ike proposal Remote-Office-Cert]
root@SRX5800#set lifetime-seconds 86400

[edit security ike proposal Remote-Office-Cert]
root@SRX5800# show
authentication-method certificates;
dh-group group2;
authentication-algorithm sha1;
encryption-algorithm 3des-cbc;
lifetime-seconds 86400;

[edit security ike proposal Remote-Office-Cert]
root@SRX5800#top commit

Configuring IKEv1 Phase 1 policies

Phase 1 policies define the actual criteria of the VPN tunnel as well as which proposals can be used as part of the Phase 1 negotiation. Note that Junos supports up to four Phase 1 proposals in a single policy. Basically, if the peer initiates the VPN, the SRX will allow any of the listed proposals. If the SRX is initiating the VPN, it will try the different proposals in the order in which they are listed until either a proposal is accepted by the peer or negotiations fail. Keep in mind that for Phase 1, preshared keys or certificates can be used with any combination of the parameters and proposals, but they are exclusive in that only one method can be used, not both.

Configuring Phase 1 mode

Main mode or Aggressive mode should be selected, depending on the configuration of the tunnel.

Configuring preshared keys

Preshared keys are used for each peer to authenticate each other during Phase 1. Preshared keys can be entered as either a clear-text string (ASCII text) or hexadecimal text. This must be specified when entering the preshared key. Typically, ASCII text will be used to specify the password, because it can support human-readable strings, whereas hexadecimal is 0–9, a–f text.

Configuring certificates

Certificates can be used as an alternative to preshared keys because they offer more dynamic support for strong authentication than preshared keys. You need to specify a few parameters, including the local certificate to use, the trusted CA with which to authenticate the peer certificate (it must be loaded on the SRX), and the peer certificate type that defines the peer’s certificate format.

Configuring the local certificate

This is the certificate to be presented to the IPsec peer.

Configuring the trusted CA

This is used to authenticate the peer’s certificate.

Configuring the peer certificate type

The SRX supports negotiation with either PKCS7 or X.509 signature encoding. A peer certificate type must be defined for the certificates that are being negotiated. The type of certificate depends on which encoding process the certificate is generated with and must be negotiated with the peer gateway.

Configuring proposals

A proposal or set of proposals must be chosen for the IKE policy to define which encryption or authentication algorithms are used when negotiating the peer IPsec VPN. Up to four proposals can be selected, although only a single proposal is required. There are also some predefined proposals that can be used.

Configuring IKEv1 Phase 1 IKE policy with preshared key, Main mode

Configure the Remote-Office-Static Phase 1 IKE policy using the following values:

• IKE Phase 1 Main mode

• A preshared key of $up3r$ecReT

• The Remote-Office-PSK proposal

[edit]
root@SRX5800#edit security ike policy Remote-Office-Static

[edit security ike policy Remote-Office-Static]
root@SRX5800#set mode main

[edit security ike policy Remote-Office-Static]
root@SRX5800#set pre-shared-key ascii-text $up3r$ecReT

[edit security ike policy Remote-Office-Static]
root@SRX5800#set proposals Remote-Office-PSK

[edit security ike policy Remote-Office-Static]
root@SRX5800#show
mode main;
proposals Remote-Office-PSK;
pre-shared-key ascii-text "$9$JTUHq5Tz9tO5QhSlex7bsYgoGiHm5zns2Q3";
## SECRET-DATA

[edit security ike policy Remote-Office-Static]
root@SRX5800#top commit

Configuring IKEv1 Phase 1 IKE policy with preshared key, Aggressive mode

Configure the Remote-Office-Dynamic Phase 1 IKE policy for gateways with dynamic IP addresses using the following values:

• IKE Phase 1 Aggressive mode

• A preshared key of $up3r$ecReT

• The Remote-Office1 proposal

[edit]
root@SRX5800#edit security ike policy Remote-Office-Dynamic

[edit security ike policy Remote-Office-Dynamic]
root@SRX5800#set mode aggressive

[edit security ike policy Remote-Office-Dynamic]
root@SRX5800#set pre-shared-key ascii-text $up3r$ecReT

[edit security ike policy Remote-Office-Dynamic]
root@SRX5800#set proposals Remote-Office-PSK

[edit security ike policy Remote-Office-Dynamic]
root@SRX5800#show
mode aggressive;
proposals Remote-Office-PSK;
pre-shared-key ascii-text "$9$JTUHq5Tz9tO5QhSlex7bsYgoGiHm5zns2Q3";
## SECRET-DATA

Configuring IKEv1 Phase 1 IKE policy with certificates

For this example, we create a Phase 1 IKE policy using certificates that builds on our previous work creating a local certificate and setting up the CA profile:

• Create an IKE policy called Remote-Office-Static-Cert that uses certificate authentication rather than preshared key authentication.

• This policy should use Main mode for the Phase 1 IKE mode.

• You should trust any valid certificate signed by a CA that you have configured to trust.

• Use the local-certificate IPSEC that we generated earlier for authentication to your peer. This certificate should be in the PKCS7 format.

• Use Remote-Office1 for the proposal.

[edit]
root@SRX5800#edit security ike policy Remote-Office-Static-Cert

[edit security ike policy Remote-Office-Static-Cert]
root@SRX5800#set mode main

[edit security ike policy Remote-Office-Static-Cert]
root@SRX5800#set certificate local-certificate IPSEC

[edit security ike policy Remote-Office-Static-Cert]
root@SRX5800#set certificate trusted-ca use-all

[edit security ike policy Remote-Office-Static-Cert]
root@SRX5800#set certificate peer-certificate-type pkcs7

[edit security ike policy Remote-Office-Static-Cert]
root@SRX5800#set Office1 proposals Remote-Office1

[edit security ike policy Remote-Office-Static-Cert]
root@SRX5800# show
mode main;
proposals Remote-Office1;
certificate {
    local-certificate IPSEC;
    trusted-ca use-all;
    peer-certificate-type pkcs7;
}

root@SRX5800#top commit

Configuring IKEv1 Phase 1 gateways

The last aspect of Phase 1 that must be configured is the actual gateway itself. The gateway identifies the remote peer the IPsec VPN peers with and defines the appropriate parameters for that IPsec VPN. As we discussed earlier in this chapter, there are two types of gateways: those with static IP addresses and those with dynamic IP addresses (including remote clients).

The SRX allows you to define multiple gateways with the same policies, which is a feature that can greatly simplify configuration, particularly if multiple gateways have the same proposal and policy. Here we cover the aspects of configuring both static and dynamic IP gateways and the various properties for IPsec VPN gateways.

Configuring remote gateways with a static IP address

The optimal setup for two VPN gateways is to have both of them use static IP addresses. This simplifies the Phase 1 setup between the two gateways, as well as potential troubleshooting because the IP address of the gateway is always known.

Note

In addition to the primary IP address defined in the gateway definition, up to four backup gateways can also be defined should the primary gateway fail.

Configuring remote gateways with a dynamic IP address

When the remote IPsec gateway does not have a static IP address, but rather is assigned via DHCP, or is perhaps a gateway that moves between different locations, dynamic IKE identities are used rather than configuring a fixed IP address. A few properties might have to be defined as part of this configuration:

Configuring local identities

Local identities are required when a device is using a dynamic IP address to identify itself to the other gateway. This can be a DN, an FQDN, an IP address, or a UFQDN. Typically, for site-to-site VPNs, the FQDN or hostname is used to define the local identity and the DN is used for certificate-based authentication. UFQDN is typically used for remote client VPNs.

Configuring remote identities

Remote identities are required when the remote party does not have a static IP address and therefore must use a dynamic IKE identity. The identity types are the same for the remote identities as they are for the local identities.

Configuring the external interface

The external interface is the interface on which the SRX terminates the IPsec VPN. The interface that the traffic terminates on must match the interface defined for that gateway or Phase 1 negotiations will fail. This is often overlooked in the configuration and is a source of confusion when experiencing issues establishing the VPN. Note that the interface must also include the IPsec unit number; if it is not defined, it is set as unit 0, but if the unit is not correct, establishment issues will occur. Note that prior to version 10.4, termination of IPsec VPNs on non-inet.0 VRs is not supported.

Configuring interfaces and zones to allow IKE traffic

On top of configuring the external interface on which the IPsec VPN is terminated, you must also make sure that IKE traffic is allowed on the interface or zone on the SRX; otherwise, the SRX will drop the traffic before the IKE daemon can process it. This is a security precaution to prevent DoS attacks against IKE gateways on interfaces that shouldn’t be allowed to accept the IKE traffic. Additionally, further restrictions can be made through the use of interface access lists that can prevent IKE traffic based on stateless firewall filters, so it is important to make sure such filters are not interfering with the traffic.

Configuring IKE policy

The IPsec VPN gateway must define the IKE policy previously configured. The IKE policy defines the preshared key or certificates used, along with the other properties of the IPsec tunnel such as the encryption and authentication algorithms. The name of the IKE policy does not have to match the name of the gateway, but this is often done for simplicity. Also, IKE policies can be reused by other gateways, assuming that the properties are the same.

Configuring NAT-T

NAT-T is required when the remote IPsec gateway or client is behind a device performing NAT. By default, NAT-T is enabled on the SRX, so it must be explicitly disabled to turn it off on a gateway-by-gateway basis.

Configuring NAT keepalives

NAT keepalives (also known as session keepalives) might be required when the remote client or gateway is behind a device performing NAT. The NAT device maintains a table that maps the translations of each session (including that of the IPsec VPN session). The sessions and their corresponding translations typically time out after a certain period of time if no traffic is received (known as an idle timeout). If the VPN is expected to have large periods of inactivity during which the session and translation might time out, NAT keepalives should be enabled to generate “artificial” traffic to keep the session active on the NAT device.

Configuring DPD

DPD allows the two gateways to determine if the peer gateway is up and responding to the DPD messages that are negotiated during IPsec establishment.

Configuring an IKEv1 gateway with static IP address and DPD

Configure the Remote-Office1 IKE gateway with the following parameters:

• IP address of 198.18.1.254.

• External interface of ge-0/0/0.0.

• Accept inbound IKE traffic on host ge-0/0/0.0 in the untrust zone.

• Remote-Office1 IKE policy.

• Enable DPD with an interval of every 10 seconds and a threshold of 3.

• Don’t have DPD always send keepalives; only send them in the absence of traffic.

[edit]
root@SRX5800#edit security ike gateway Remote-Office1

[edit security ike gateway Remote-Office1]
root@SRX5800#set address 198.18.1.254

[edit security ike gateway Remote-Office1]
root@SRX5800#set external-interface ge-0/0/0.0

[edit security ike gateway Remote-Office1]
root@SRX5800#set ike-policy Remote-Office1

[edit security ike gateway Remote-Office1]
root@SRX5800#set dead-peer-detection interval 10

[edit security ike gateway Remote-Office1]
root@SRX5800#set dead-peer-detection threshold 3

[edit security ike gateway Remote-Office1]
root@SRX5800# show
ike-policy Remote-Office1;
address 198.18.1.254;
dead-peer-detection {
    interval 10;
    threshold 3;
}
external-interface ge-0/0/0.0;

[edit security ike gateway Remote-Office1]
root@SRX5800#top edit security zones security-zone untrust
interfaces ge-0/0/0.0 host-inbound-traffic system-services

[edit security zones security-zone untrust interfaces ge-0/0/0.0
host-inbound-traffic system-services]
root@SRX5800#set ike

[edit security zones security-zone untrust interfaces ge-0/0/0.0
host-inbound-traffic system-services]
root@SRX5800#show
ike;

[edit security zones security-zone untrust interfaces ge-0/0/0.0
host-inbound-traffic system-services]
root@SRX5800#top commit

Configuring dynamic gateways and remote access clients

Some properties of IKE Phase 1 apply only to remote clients connecting to the SRX. These are primarily centered on XAuth and IKE IDs.

Configuring XAuth

XAuth negotiation technically takes place between Phase 1 and Phase 2 of the VPN establishment, but is herewith discussed as part of the Phase 1 negotiation. The SRX only supports authenticating clients with XAuth and not authenticating itself to another XAuth-capable peer. Also, the SRX must use RADIUS to authenticate remote users, and cannot use local XAuth users like ScreenOS can (at the time of this writing). A few things must be configured as part of the XAuth configuration, including the XAuth access profile, the XAuth RADIUS server configuration, and the XAuth configuration within IKE. Also, when configuring remote users, an IKE gateway must be configured to define the IKE identity of the user.

Configuring IKE connection sharing

IKE connection sharing allows an administrator to define a single IKE gateway object that allows multiple users to connect to it with the same properties. This is most commonly performed when using multiple remote clients that are also using XAuth to authenticate; however, this is not a requirement. It is primarily used as a matter of convenience for administrators so that they don’t have to configure multiple gateways as well as remote clients with separate configuration files, but rather can use a single remote configuration and single gateway configuration. This is known as a shared-IKE ID.

Configuring an IKE gateway with a dynamic IP address

Configure the Remote-Office3 gateway that uses a dynamic IP address with the following properties:

• Remote-Office-Dynamic IKE policy

• Remote-Office3.company.com used as identity of Remote-Office3

• External interface of ge-0/0/0.0

• IKE processing enabled on interface ge-0/0/0.0

[edit]
root@SRX5800#edit security ike gateway Remote-Office3

[edit security ike gateway Remote-Office3]
root@SRX5800#set dynamic hostname Remote-Office3.company.com

[edit security ike gateway Remote-Office3]
root@SRX5800#set external-interface ge-0/0/0.0

set security zones security-zone untrust interfaces ge-0/0/0.0
host-inbound-traffic system-services ike

[edit security ike gateway Remote-Office3]
root@SRX5800#set ike-policy Remote-Office-Dynamic

[edit security ike gateway Remote-Office3
root@5800# show
ike-policy Remote-Office-Dynamic;
dynamic hostname Remote-Office3.company.com;
external-interface ge-0/0/0.0;

[edit security ike gateway Remote-Office3]
root@SRX5800#top edit security zones security-zone untrust interfaces
ge-0/0/0.0 host-inbound-traffic system-services

[edit security zones security-zone untrust interfaces ge-0/0/0.0
host-inbound-traffic system-services]
root@SRX5800#set ike

[edit security zones security-zone untrust interfaces ge-0/0/0.0
host-inbound-traffic system-services]
root@SRX5800#show
ike;

[edit security zones security-zone untrust interfaces ge-0/0/0.0
host-inbound-traffic system-services]
root@SRX5800#top commit

Configuring an IKEv1 remote access client

Configure the following properties for a remote client connection:

• The remote client’s identity should be a shared IKE ID type, with up to 25 simultaneous connections.

• The user should use the UFQDN [e-mail].

• The VPNs should be terminated on the ge-0/0/0.0 interface and ensure that IKE traffic can be processed on this interface.

• The Remote-Office-Dynamic IKE policy should be selected.

• XAuth will be used for this connection with an access profile of Remote-Client, via RADIUS server 10.3.1.50, with a secret of RadiU$Secr3+.

[edit]
root@SRX5800# edit security ike gateway Remote-Client

[edit security ike gateway Remote-Client]
root@SRX5800# set dynamic user-at-hostname [e-mail]

[edit security ike gateway Remote-Client]
root@SRX5800# set external-interface ge-0/0/0.0

[edit security ike gateway Remote-Client]
root@SRX5800# set ike-policy Remote-Office-Dynamic

[edit security ike gateway Remote-Client]
root@SRX5800# set xauth access-profile Remote-Client

[edit security ike gateway Remote-Client]
root@SRX5800# set dynamic connection-limit 25

[edit security ike gateway Remote-Client]
root@SRX5800# set Dynamic dynamic ike-user-type shared-ike-id

[edit security ike gateway Remote-Client
root@SRX5800# show
ike-policy Remote-Office-Dynamic;
dynamic {
    user-at-hostname [e-mail];
    connections-limit 25;
    ike-user-type shared-ike-id;
}
local-identity hostname HQ.company.com;
external-interface ge-0/0/0.0;
xauth access-profile Remote-Client;

[edit security ike gateway Remote-Client]
root@SRX5800#top edit security zones security-zone untrust interfaces
ge-0/0/0.0 host-inbound-traffic system-services

[edit security zones security-zone untrust interfaces ge-0/0/0.0
host-inbound-traffic system-services
root@SRX5800#set ike

[edit security zones security-zone untrust interfaces ge-0/0/0.0
host-inbound-traffic system-services
root@SRX5800#show
ike;

[edit security zones security-zone untrust interfaces ge-0/0/0.0
host-inbound-traffic system-services
root@SRX5800# top edit access profile Remote-Client

[edit access profile Remote-Client]
root@SRX5800# set authentication-order radius

[edit access profile Remote-Client]
root@SRX5800# set radius-server 10.3.1.50 secret RaDiU$Secr3+

[edit access profile Remote-Client]
root@SRX5800# show
authentication-order radius;
radius-server {
        10.3.1.50 secret "$9$PTn9AtOEhyQFrKvWXxjik.PQn6AuBE/9Ec";
## SECRET-DATA
    }

[edit access profile Remote-Client]
root@SRX5800#top commit

Phase 2 IKE Configuration

Phase 2 IKE configuration requires several parameters to be defined for the IPsec VPN to be established. Phase 2 primarily deals with securing the data traffic located within the IPsec VPN tunnel. This communication takes place on top of the secure communication channel formed in Phase 1.

In this section, we cover the following regarding Phase 2 configuration: Phase 2 proposal, Phase 2 policy, and common VPN components.

Configuring IKEv1 Phase 2 proposals

Phase 2 IKE proposals are similar to Phase 1 IKE proposals in that encryption and authentication algorithms are selected, along with key lifetimes. As mentioned before, the purpose of the Phase 2 encryption and authentication algorithms differs from that of Phase 1 encryption and authentication algorithms, but the actual components of the proposals are essentially the same. It is important to note that the names of the proposals, policies, and VPNs do not have to match those of the Phase 1 policies used, as they will be referenced accordingly, but name matching is often done for simplicity of management.

Configuring the encryption algorithm

The encryption algorithm defines which encryption algorithm is used to encrypt the data within the IPsec VPN. This is only applicable when using ESP, as AH does not encrypt the actual content of the VPN.

Configuring the authentication algorithm

The authentication algorithm is used to ensure that the data have arrived from the correct source and have not been modified.

Configuring the IPsec protocol

ESP or AH must be selected for determining the type of VPN. ESP provides both encryption and authentication, whereas AH provides only authentication.

Configuring the key lifetimes

Key lifetimes for Phase 2 can be configured in seconds or as kilobytes. If the goal is to ensure that Phase 2 keys are active for only a certain period of time, seconds is the appropriate choice; if the goal is to keep keys active until a certain amount of data has been sent (based on VPN usage), kilobytes is preferred. If you do not specify the value, by default 3,600 seconds (or one hour) will be used for the Phase 2 key lifetime.

Configuring an IKEv1 Phase 2 proposal for remote offices and client connections

Configure the following properties for the Remote-Office Phase 2 proposal that will be used for all remote offices and client connections:

• Use AES-256 for the encryption algorithm.

• Use SHA-1 for the authentication algorithm.

• Use ESP as the IPsec protocol.

• Set a lifetime of one hour for the Phase 2 keys.

[edit]
root@SRX5800# edit security ipsec proposal Remote-Office-Client

[edit security ipsec proposal Remote-Office-Client]
root@SRX5800# set encryption-algorithm aes-256-cbc

[edit security ipsec proposal Remote-Office-Client]
root@SRX5800# set authentication-algorithm hmac-sha1-96

[edit security ipsec proposal Remote-Office-Client]
root@SRX5800# set protocol esp

[edit security ipsec proposal Remote-Office-Client]
root@SRX5800# set lifetime-seconds 3600

[edit security ipsec proposal Remote-Office-Client]
root@SRX5800# show
protocol esp;
authentication-algorithm hmac-sha1-96;
encryption-algorithm aes-256-cbc;
lifetime-seconds 3600;

[edit security ipsec proposal Remote-Office-Client]
root@SRX5800#top commit

Configuring Phase 2 IPsec policy

The Phase 2 IPsec policy defines how the VPN is established. A few properties are defined in the IPsec policy, including which proposals are to be used, as well as whether PFS is to be used on the VPN.

Configuring the IPsec proposals

Up to four proposals can be negotiated for the IPsec tunnel, although only one is used for the actual IPsec traffic encryption and authentication. Essentially, the initiator tries to negotiate each IPsec tunnel until a proposal is accepted by the peer or there are no other IPsec proposals left to negotiate.

Configuring PFS

If PFS is to be used, it is configured in the IPsec policy, and actually takes effect after Phase 1 but before Phase 2 is negotiated. As part of the configuration, the Diffie-Hellman group must be defined to be negotiated for the PFS. It does not have to match the Diffie-Hellman group negotiated in Phase 1.

Configuring an IPsec policy defining the Phase 2 proposal

You must configure an IPsec policy that defines which Phase 2 proposal will be selected and if PSK will be used for the VPN, if applicable. Configure the Remote-Office-Client Phase 2 IPsec policy, which will be used for all remote office and client connections with the following properties:

• Use the Remote-Office-Client proposal.

• Use PFS with Diffie-Hellman Group 5 for additional security.

[edit]
root@SRX5800# edit security ipsec policy Remote-Office-Client

[edit security ipsec policy Remote-Office-Client]
root@SRX5800# set proposals Remote-Office-Client

[edit security ipsec policy Remote-Office-Client]
root@SRX5800# set perfect-forward-secrecy keys group5

[edit security ipsec policy Remote-Office-Client]
root@SRX5800# show
perfect-forward-secrecy {
    keys group5;
}
proposals Remote-Office-Client;

[edit security ipsec policy Remote-Office-Client]
root@SRX5800#top commit

Configuring common IPsec VPN components

Now that the IPsec proposal and the policy have been configured, the VPN object can be completed with the final configuration of Phase 2. This information includes the proxy IDs, the IPsec policy, the tunnel binding (if route-based VPNs are used), and other properties of the VPN tunnel including replay detection, fragmentation, and VPN monitoring. We begin with the VPN configuration components that are common to both policy-based and route-based VPNs, and then cover the components specific to policy- and route-based VPNs, respectively. Some of the components covered in this section are optional and are noted as such.

Configuring the IPsec VPN gateway

The IPsec VPN gateway must be configured in Phase 2. This references the IKE VPN gateway object configured in Phase 1.

Configuring the IPsec policy

The IPsec policy defines the proposal and PFS configuration for the VPN.

Configuring VPN establishment

The VPN can be established immediately when the configuration is applied (and subsequently whenever the VPN expires), or it can be established on-traffic when there is user data traffic. By default, VPNs are established on-traffic.

Configuring fragmentation

Fragmentation might be required on VPN traffic because of the overhead associated with IPsec VPNs (either ESP/AH overhead or overhead associated with Tunnel mode) and the underlying MTU of the physical data links. A few options can be selected for the fragmentation. You can alternatively clear the DF bit, set the DF bit, and copy the DF bit. If fragmentation is required but the DF bit is set (and honored by the SRX), that traffic will be dropped.

Configuring Anti-Replay detection

By default, Anti-Replay detection is enabled. It essentially consists of checking the sequence numbers and enforcing the check, rather than just ignoring the sequence numbers. Anti-Replay detection can be disabled manually if desired on a VPN-by-VPN basis.

Configuring VPN monitoring

VPN monitoring is a proprietary method of ensuring that the VPN is actually established (which goes beyond the VPN gateway availability of DPD to actually ensure that the VPN itself is up). A few parameters must be configured as part of VPN monitoring, including what device to ping, what source interface is used, and whether the traffic is optimized. The optimized setting omits sending the pings when user data is present.

Configuring a common site-to-site VPN component

Configure a VPN called East-Branch, which will serve as the site-to-site VPN for the East Branch to Campus site.

• Use an IKE gateway called East-Branch.

• Use an IPsec policy called Remote-Office-Client.

• Establish the VPNs immediately and automatically rekey.

• Disable Anti-Replay detection.

• Always clear the DF bit.

• Monitor the VPN by pinging the IP address 192.168.1.50 using a method in which the pings are only sent in the absence of traffic every three seconds with a failure threshold of three.

[edit]
root@SRX5800# edit security ipsec vpn East-Branch

[edit security ipsec vpn East-Branch]
root@SRX5800# set ike gateway East-Branch

[edit security ipsec vpn East-Branch]
root@SRX5800# set ike ipsec-policy Remote-Office-Client

[edit security ipsec vpn East-Branch]
root@SRX5800# set establish-tunnels immediately

[edit security ipsec vpn East-Branch]
root@SRX5800# set df-bit clear

[edit security ipsec vpn East-Branch]
root@SRX5800# set ike no-anti-replay

[edit security ipsec vpn East-Branch]
root@SRX5800# set vpn-monitor optimized source-interface st0.0
destination-ip 192.168.1.50

[edit security ipsec vpn East-Branch]
root@SRX5800# show
df-bit clear;
vpn-monitor {
    optimized;
    destination-ip 192.168.1.50;
}
ike {
    gateway East-Branch;
    no-anti-replay;
}
ipsec-policy Remote-Office-Client;

[edit security ipsec vpn East-Branch]
root@SRX5800# up

[edit security ipsec]
root@SRX5800# set vpn-monitor-options inverval 3 threshold 3


[edit security ipsec]
root@SRX5800# show
vpn-monitor-options {
    interval 3;
    threshold 3;
}

[edit security ipsec]
root@SRX5800#top commit

IKEv1 Versus IKEv2 Configuration

Before we wrap up route-based VPNs, let’s take a look at how IKEv2 VPNs are configured on the SRX. First, only route-based VPNs are supported today, so that excludes policy-based VPNs. But how does the SRX know whether or not to use IKEv1 or IKEv2 for negotiation?

Simple: it is defined in the gateway configuration. In fact, a gateway configuration can only be IKEv1 or IKEv2. You cannot configure the VPN to fall back to IKEv1 from IKEv2 or upgrade to IKEv2 if available, so you’ll need to sort this out in advance. The configuration is really quite simple and is done under the gateway configuration as follows:

[edit]
root@srx3600n0# set security ike gateway V2-Gateway version ?
Possible completions:
  v1-only              The connection must be initiated using IKE version 1
  v2-only              The connection must be initiated using IKE version 2
[edit]
root@srx3600n0# set security ike gateway V2-Gateway version v2-only

The default configuration is v1-only, so if you want to use v2, you need to explicitly define this to be the case.

Configuring policy-based VPNs

The main thing that needs to be configured as part of policy-based VPNs is the tunnel action of the appropriate security policy rule. One thing that is often forgotten when it comes to configuring policy-based VPNs is that a route might still be needed to force the traffic to go to the correct destination zone. This is not special to the VPN configuration, as it also applies to standard traffic to determine the egress interface and egress zone.

Configuring a policy-based VPN for the East Branch to the Central site VPN

In this example, we configure a policy-based VPN for the East Branch to the Central site VPN. Use the following properties for creating this policy-based VPN:

• Allow any HTTP traffic to or from the 10.0.0.0/8 network to 192.168.1.0/24 for the East-Branch VPN created in the previous steps.

• Log the connections on session close.

[edit]
root@SRX5800# set security zones security-zones trust address-book
address 10.0.0.0/8 10.0.0.0/8

[edit]
root@SRX5800# show security zones security-zone trust address-book
address 10.0.0.0/8 10.0.0.0/8


[edit]
root@SRX5800# set security zones security-zones untrust address-book
address 192.168.1.0/24 192.168.1.0/24

[edit]
root@SRX5800# show security zones security-zone untrust address-book
address 192.168.1.0/24 192.168.1.0/24

[edit]
root@SRX5800# edit security policies from-zone trust to-zone untrust policy
East-Branch-Outbound

[edit security policies from-zone trust to-zone untrust policy
East-Branch-Outbound]
root@SRX5800# set match source-address 10.0.0.0/8 destination-address
192.168.1.0/24 application junos-http

[edit security policies from-zone trust to-zone untrust policy
East-Branch-Outbound]
root@SRX5800# set then permit tunnel ipsec-vpn East-Branch pair-policy
East-Branch-Inbound

[edit security policies from-zone trust to-zone untrust policy
East-Branch-Outbound]
root@SRX5800# set then log session-close

[edit security policies from-zone trust to-zone untrust policy
East-Branch-Outbound]
root@SRX5800# show
match {
        source-address 10.0.0.0/8;
        destination-address 192.168.1.0/24;
        application junos-http;
        }
 then {
        permit {
               tunnel {
                 ipsec-vpn East-Branch;
                 pair-policy East-Branch-Inbound;
                }
         }
            log {
                session-close;
            }
  }

[edit security policies from-zone trust to-zone untrust policy
East-Branch-Outbound]
root@SRX5800#top edit security policies from-zone untrust to-zone
trust policy East-Branch-Inbound

[edit security policies from-zone trust to-zone untrust policy
East-Branch-Inbound]
root@SRX5800# show
match {
        source-address 192.168.1.0/24;
        destination-address 10.0.0.0/8;
        application junos-http;
        }
 then {
        permit {
               tunnel {
                 ipsec-vpn East-Branch;
                 pair-policy East-Branch-Outbound;
                }
         }
            log {
                session-close;
            }
  }

[edit security policies from-zone trust to-zone untrust policy
East-Branch-Inbound]
root@SRX5800#top commit

Configuring route-based VPNs

Route-based VPNs require a few extra components over policy-based VPNs, as outlined here:

Configuring secure tunnel interfaces

Secure tunnel interfaces are virtual interfaces that place all of the traffic that arrives in them into VPNs that are bound to the tunnel interface. They are required for route-based VPNs, where the traffic destined to the VPN is routed into the secure tunnel interface. It is important to understand that just like standard logical interfaces, the units can be in different zones from each other, so they can be separate.

Configuring interface binding

Once the st0.x interface has been created, the VPN must be bound to the appropriate secure tunnel interface. This is done within the Phase 2 configuration.

Configuring proxy IDs

Proxy IDs must be configured for route-based VPNs because they cannot be derived from anything like policy-based VPNs can. Policy-based VPNs can also be overwritten by defining the proxy IDs manually. At the time of this writing, only a single proxy ID can be defined per VPN on the SRX.

Configuring routing

The SRX must know how to reach the destination networks. This can be done through the use of static routing or dynamic routing. In this example configuration, static routing is used.

Although route-based VPNs do not require a policy with the Tunnel action, security policies to allow the traffic are still required. The policy is a regular policy, with the standard Permit action. The following syntax shows the Then action of the policy, followed by a complete example of a match policy:

[edit]
root@SRX5800# set interfaces st0 unit 0 family inet address 192.168.100.1/24

root@SRX5800# show interfaces st0
unit 0 {
    family inet {
        address 192.168.100.1/24;
    }
}

[edit]
root@SRX5800# edit security ipsec vpn East-Branch

[edit security ipsec vpn East-Branch]
root@SRX5800# set bind-interface st0.0

[edit security ipsec vpn East-Branch]
root@SRX5800# set ike proxy-identity local 10.0.0.0/8 remote 192.168.1.0/24
service junos-http

[edit security ipsec vpn East-Branch]
root@SRX5800# set ike gateway East-Branch

[edit security ipsec vpn East-Branch]
root@SRX5800# set ipsec-policy Remote-Office-Client


[edit security ipsec vpn East-Branch]
root@SRX5800# show
bind-interface st0.0;
ike {
    gateway East-Branch;
    proxy-identity {
        local 10.0.0.0/8;
        remote 192.168.1.0/24;
        service junos-http;
    }
    ipsec-policy Remote-Office-Client;
}

[edit security ipsec vpn East-Branch]
root@SRX5800# top


[edit]
root@SRX5800# set routing-options static route 192.168.1.0/24
next-hop 192.168.100.254

[edit]
root@SRX5800# show routing-options static route 192.168.1.0/24
next-hop 192.168.100.254

[edit]
root@SRX5800# set security zones security-zones trust address-book
address 10.0.0.0/8 10.0.0.0/8

[edit]
root@SRX5800# show security zones security-zone trust address-book
address 10.0.0.0/8 10.0.0.0/8

[edit]
root@SRX5800# set security zones security-zones untrust address-book
address 192.168.1.0/24 192.168.1.0/24[edit]
root@SRX5800# show security zones security-zone untrust address-book
address 192.168.1.0/24 192.168.1.0/24

[edit]
root@SRX5800# edit security policies from-zone trust to-zone untrust policy
East-Branch-Outbound

[edit security policies from-zone trust to-zone untrust policy
East-Branch-Outbound]
root@SRX5800# set match source-address 10.0.0.0/8 destination-address
192.168.1.0/24 application junos-http

[edit security policies from-zone trust to-zone untrust policy
East-Branch-Outbound]
root@SRX5800# set then permit

[edit security policies from-zone trust to-zone untrust policy
East-Branch-Outbound]
root@SRX5800# set then log session-close

[edit security policies from-zone trust to-zone untrust policy
East-Branch-Outbound]
root@SRX5800# show
match {
        source-address 10.0.0.0/8;
        destination-address 192.168.1.0/24;
        application junos-http;
        }
 then {
        permit
        log {
                session-close;
            }
  }

[edit security policies from-zone trust to-zone untrust policy
East-Branch-Outbound]
root@SRX5800#top edit security policies from-zone untrust to-zone trust policy
East-Branch-Inbound

[edit security policies from-zone untrust to-zone trust policy
East-Branch-Inbound]
root@SRX5800# set match source-address 192.168.1.0/24 destination-address
192.168.1.0/24 application junos-http

[edit security policies from-zone untrust to-zone trust policy
East-Branch-Inbound]
root@SRX5800# set then permit

[edit security policies from-zone untrust to-zone trust policy
East-Branch-Inbound]
root@SRX5800# set then log session-close


[edit security policies from-zone untrust to-zone trust policy
East-Branch-Inbound]
root@SRX5800# show
match {
        source-address 192.168.1.0/24;
        destination-address 10.0.0.0/8;
        application junos-http;
        }
 then {
        permit
        log {
                session-close;
            }
  }

[edit security policies from-zone untrust to-zone trust policy
East-Branch-Inbound]
root@SRX5800#top commit

IPsec and SRX HA

When it comes to HA, there are a few pertinent items to discuss with IPsec on the SRX.

IPsec termination in HA

When using HA, terminating IPsec tunnels is a bit more complex because there is technically more than one place on the SRX that the IPsec tunnel can be terminated (particularly with active/active HA infrastructure). It is possible to terminate a VPN on a local interface, a reth interface, or, as of Junos 12.1X44, a loopback interface. Typically, you should not terminate a VPN on a local interface when using HA, and in fact this isn’t supported for active/active HA clusters. In terms of whether or not to terminate on a reth interface or loopback interface in the case of 12.1X44+, that just depends on how your SRX connects to the network. If you only have one upstream/downstream path, then it makes sense to terminate the VPN simply on the reth interface that faces the peer because the reth interface will automatically handle the failover between different nodes. You’d want to use a loopback interface rather than a reth interface if you have multiple upstream/downstream connections (e.g., multihomed Internet connections) and you don’t want to terminate multiple VPNs on your device, one for each segment (which would rely on dynamic routing to fail over between VPNs). In this case, you simply terminate the VPN to the loopback interface, so regardless of what the underlying routing dictates for reaching the peer, the endpoints will remain the same.

ISSU for VPN

ISSU is a feature that today is supported on the high-end SRX. As of Junos 12.1X44, the high-end SRX supports ISSU with IPsec configurations. This means that you can perform a hitless upgrade where the secondary device will be upgraded first, then once it is upgraded and back up and in the cluster, the primary will fail over to the upgraded device including all VPNs. Then the original primary will upgrade itself. This all happens with only a single command to be issued that will upgrade the entire cluster.

At the time of writing this book, the branch SRX only supports partial ISSU support in that it does not statefully fail over firewall sessions, but rather fails over the devices and upgrades them with the use of a single command. The expansion of ISSU and synchronization of the feature sets between the branch and high-end SRX will likely come very soon so stay posted to the release notes.

Dynamic VPN

In this example, we demonstrate how to leverage the built-in Dynamic VPN client on the branch SRX Series devices to connect remote clients to the corporate network.

Phase 1 proposal

Create a proposal called Dynamic-VPN that uses 3DES-SHA1, preshared keys, Diffie-Hellman Group 2, and a lifetime of four hours, and set a description.

Phase 1 policy

Create a policy called Dynamic-VPN-Policy that uses aggressive mode, the preshared key DialUp4123, and the Dynamic-VPN proposal, and set a description.

Phase 1 gateway

Create an IKE gateway called Dynamic-VPN-Gateway. You will use the XAuth parameters that we defined earlier in the chapter for our XAuth profile called XAuth. Limit the number of connections to five using a shared IKE ID of [e-mail]. This VPN should be terminated on interface ge-0/0/0.0 using the IKE policy Dynamic-VPN-Policy. Ensure that the ge-0/0/0.0 interface allows inbound IKE and HTTP/HTTPS connections so that the user can access the web interface and make sure VPNs can establish properly.

Phase 2 proposal

Create a proposal called Dynamic-VPN using AES256-SHA1 with ESP as the IPsec protocol, set the lifetime to 3,600 seconds, and provide a description for the proposal.

Phase 2 policy

Create a policy called Dynamic-VPN-Policy that uses the Dynamic-VPN Phase 2 proposal with PDF Diffie-Hellman Group 2.

Phase 2 VPN

Create a Phase 2 VPN called Dynamic-VPN that uses Dynamic-VPN-Gateway as the gateway and Dynamic-VPN-Policy as the Phase 2 policy.

Dynamic VPN client configuration

Create a Dynamic VPN client configuration called Dynamic-VPN-Clients that uses the Dynamic-VPN configuration we defined for user dynvpn. This profile should allow users to access the resource 10.0.0.0/8 behind the firewall when they are connected. Use the XAuth profile XAuth, and also force the client to upgrade if an upgrade to the client is necessary on login.

Local certificate

Finally, generate a local certificate that can be used to host HTTPS on the web server on the ge-0/0/0.0 interface. This is needed so that we can allow users to log in securely. You must also ensure that the ge-0/0/0.0 interface allows the HTTPS connection inbound.

[edit]
root@SRX210# edit security ike proposal Dynamic-VPN

[edit security ike proposal Dynamic-VPN]
root@SRX210# set authentication-method pre-shared-keys dh-group group2
authentication-algorithm sha1 encryption algorithm 3des-cbc lifetime-seconds
12000 description "Dynamic VPN Proposal"

[edit security ike proposal Dynamic-VPN]
root@SRX210# show
description "Dynamic VPN Proposal";
authentication-method pre-shared-keys;
dh-group group2;
authentication-algorithm sha1;
encryption-algorithm 3des-cbc;
lifetime-seconds 12000;

[edit security ike proposal Dynamic-VPN]
root@SRX210#up

[edit security ike]
root@SRX210# edit policy Dynamic-VPN-Policy

[edit security ike policy Dynamic-VPN-Policy]
root@SRX210# set mode aggressive description "Dynamic-VPN IKE Policy" proposals
Dynamic-VPN pre-shared-key ascii-text DialUp4123

[edit security ike policy Dynamic-VPN-Policy]
root@SRX210# show
mode aggressive;
description "Dynamic-VPN IKE Policy";
proposals Dynamic-VPN;
pre-shared-key ascii-text "$9$K8zvWXY2aZGi7-.f5T9CM8LxVw24aUik"; ## SECRET-DATA

[edit security ike policy Dynamic-VPN-Policy]
root@SRX210# up

[edit security ike]
root@SRX210# edit gateway Dynamic-VPN-Gateway

[edit security ike gateway Dynamic-VPN-Gateway]
root@SRX210# set external-interface ge-0/0/0.0 ike-policy Dynamic-VPN-Policy
xauth access-profile XAuth

[edit security ike gateway Dynamic-VPN-Gateway]
root@SRX210# set dynamic connection-limit 5 user-at-hostname [e-mail]
ike-user-type shared-ike-id

[edit security ike gateway Dynamic-VPN-Gateway]
root@SRX210# show
ike-policy Dynamic-VPN-Policy;
dynamic {
    user-at-hostname "[e-mail]";
    connections-limit 5;
    ike-user-type shared-ike-id;
}
external-interface ge-0/0/0;
xauth access-profile XAuth;

[edit security ike gateway Dynamic-VPN-Gateway]
root@SRX210# top

[edit]
root@SRX210# show access-profile
XAuth;

[edit]
root@SRX210# show access profile XAuth
authentication-order radius;
radius-server {
    192.168.224.60 {
        port 1812;
        secret "$9$pf5hB1hrev7dbgoJDk.zFIEclMX"; ## SECRET-DATA
        source-address 192.168.224.3;
    }
}

[edit]
root@SRX210# show security zones security-zone trust
interfaces {
    ge-0/0/0.0 {
        host-inbound-traffic {
            system-services {
                http;
                https;
                ping;
                ike;
            }
            protocols {
                ospf;
            }
        }
    }
}

[edit]
root@SRX210# edit security ipsec proposal Dynamic-VPN

[edit security ipsec proposal Dynamic-VPN]
root@SRX210# set description "Dynamic VPN Proposal" authentication-algorithm
hmac-sha1-96 encryption-algorithm aes-256-cbc lifetime-seconds 3600 protocol esp

[edit security ipsec proposal Dynamic-VPN]
root@SRX210# show
description "Dynamic VPN Proposal";
protocol esp;
authentication-algorithm hmac-sha1-96;
encryption-algorithm aes-256-cbc;
lifetime-seconds 3600;

[edit security ipsec proposal Dynamic-VPN]
root@SRX210# up

[edit security ipsec]
root@SRX210# edit policy Dynamic-VPN-Policy

[edit security ipsec policy Dynamic-VPN-Policy]
root@SRX210# set description "Dynamic VPN Phase 2 Policy" proposals Dynamic-VPN
perfect-forward-secrecy keys group2

[edit security ipsec policy Dynamic-VPN-Policy]
root@SRX210# show
description "Dynamic VPN Phase 2 Policy";
perfect-forward-secrecy {
    keys group2;
}
proposals Dynamic-VPN;

[edit security ipsec policy Dynamic-VPN-Policy]
root@SRX210 up

[edit security ipsec]
root@SRX210# edit vpn Dynamic-VPN

[edit security ipsec vpn Dynamic-VPN]
root@SRX210# set ike gateway Dynamic-VPN-Gateway ipsec-policy Dynamic-VPN-Policy

[edit security ipsec vpn Dynamic-VPN]
root@SRX210# show
ike {
    gateway Dynamic-VPN-Gateway;
    ipsec-policy Dynamic-VPN-Policy;
}

[edit security ipsec vpn Dynamic-VPN]
root@SRX210# up 2

[edit security]
root@SRX210# edit dynamic-vpn

[edit security dynamic-vpn
root@SRX210# set clients Dynamic-VPN-Clients remote-protected-resources
10.0.0.0/8

[edit security dynamic-vpn]
root@SRX210# set clients Dynamic-VPN-Clients user dynvpn

[edit security dynamic-vpn]
root@SRX210# set clients Dynamic-VPN-Clients ipsec-vpn Dynamic-VPN

[edit security dynamic-vpn]
root@SRX210# set force-upgrade

[edit security dynamic-vpn]
root@SRX210# set access-profile XAuth

[edit security dynamic-vpn]
root@SRX210# show
force-upgrade;
access-profile XAuth;
clients {
    Dynamic-VPN-Clients {
        remote-protected-resources {
            10.0.0.0/8;
        }
        ipsec-vpn Dynamic-VPN;
        user {
            dynvpn;
        }
    }
}

[edit security dynamic-vpn]
root@SRX210# top

[edit]
root@SRX210# run request security pki generate-key-pair certificate-id HTTPS
Generated key pair HTTPS, key size 1024 bits

[edit]
root@SRX210# set system services web-management https
system-generated-certificate interface ge-0/0/0.0

[edit]
root@SRX210# show system services web-management
https {
    system-generated-certificate;
    interface ge-0/0/0.0;
}

Best Practices

There are plenty of best practices when it comes to operating IPsec VPNs on the SRX. We review some of the more notable ones here for your convenience.

1. You should always use NTP when managing the SRX, but this is particularly true for devices running IPsec VPNs, the high-end SRX platforms, and HA clusters. Running NTP will help to keep the clocks in sync across all of the components in the system and ensure that log messages and system state timing are accurate.

2. It’s typically a best practice to use route-based VPNs on the SRX unless you have a special vendor interoperability scenario or legacy support for dial-up VPNs where you might be better off running policy-based VPNs. Going forward, both of these will likely change as Juniper looks to introduce Multi-Proxy-ID and enhancements to the remote access products, so keep current with the release notes.

3. In almost all cases, you will want to use IKE over manual key encryption. It is far more secure and easier to set up. The only scenarios where you would want manual key is if the other peer didn’t support IKE; you wanted the keys to never expire, perhaps in a proof-of-concept scenario; or you were trying to do something evasive by skipping IKE and just encrypting traffic (something that an evasive application might do).

4. Regarding choosing between IKEv1 and IKEv2, IKE v2 is definitely a better protocol. From a configuration perspective, it’s trivial to configure a VPN to use IKEv2 instead of IKEv1 (or allow it to use either). The main question is whether the other peer accepts it.

5. If using IKEv1, Main mode is a better choice when you have an established identity for the peer such as a site-to-site VPN. Although there are six messages rather than three, it keeps the identity information in the clear. If you are dealing with dial-up users, Aggressive mode might be your only option. IKEv2 doesn’t support the concept of Main versus Aggressive mode.

6. When deciding whether to use preshared keys or certificates, typical guidance is that if you only have a handful of sites, particularly if they are run by third-party peers, preshared keys are best because they are easy to exchange and don’t have the overhead of certificates + signing + loading CAs, CRL, OSCP, and so on. On the other hand, if you are doing a large deployment either with numerous remote hub and spoke sites or with numerous remote access users, then certificates are likely the way to go. Certificates are unique to each site and user, however they can be independently authenticated, easily generated, revoked on demand, and not act as a single point of failure (e.g., 100 users using the same preshared keys).

7. It is typically a best practice to use ESP as your IPsec protocol rather than AH. The difference is that ESP actually encrypts the data rather than just putting a signed header that authenticates the data has not been altered. Most organizations want the additional security of encrypting the traffic itself. AH might make more sense when the intention isn’t at all to keep the data secret, just to ensure that the data is authentic and has not been altered. Needless to say, these use cases are few and far between, so you’ll likely be working with ESP in all of your implementations.

8. Transport versus Tunnel mode is an easy one. The SRX doesn’t currently support Transport mode (which merely leverages the original packets and puts another header on for ESP or AH to secure the communication). Only Tunnel mode is supported at the time of writing this book. Tunnel mode encapsulates the original packet into a new packet between the two gateways. This is so popular because often you can’t have internal hosts communicating together due to private IP ranges as discussed in Transport mode.

9. For environments that want additional security insurance around their VPN setup and don’t have a major concern for the number of new tunnels per second, it’s a good idea to use PFS to provide another layer of negotiation to ensure that keys aren’t compromised.

10. In terms of choosing the DH group, encryption strength, and authentication algorithm, there are a few factors. You can obviously select the most powerful encryption and authentication algorithms and the highest bit lengths, but this might not be ideal because they are extremely computationally intensive, and in some cases the hardware encryption engines can’t support them so they are done in hardware. The other factor is to determine what protocols your other peers support because they might not support the latest and greatest. Juniper also provides predefined proposal sets that can help to make this process easier if you are unsure. The Standard protocol sets seem adequate, whereas the Suite B are more advanced.

11. It is a best practice to run Dynamic VPN on a different interface than the web management interface (e.g., reserve web managed to only fxp0 but allow Dynamic VPN to take place on other interfaces as well). This is much more secure and provides some additional flexibility for control. If you can’t distinguish the interfaces for management, you should at least use different URLs for management versus Dynamic VPNs, leverage access lists if possible, and use different nonstandard ports.

12. If you are dealing with a hub and spoke site and all of the spokes can share the same virtual router and zone (e.g., they all are considered to be in the security framework, there is no overlapping routing information), it can be advantageous to run them off of a point-to-multiple interface rather than making them all point-to-point. It is much easier from an administrative perspective on the hub side to do this, particularly when you are leveraging a dynamic routing protocol.

13. It is best practice to leverage VPN monitoring on mission-critical sites because VPN monitoring can make active checks to see if the VPN is still up and running on both sides rather than just relying on the gateways responding to messages like DPD. VPN monitoring and DPD do have scale limits when dealing with thousands of VPNs, however.

14. Perform CRL checks when using certificates because it allows you to ensure not only that the certificate is valid, but also that it is not revoked. In the future, when the SRX supports OCSP, that will be an even more preferred method, which can provide real-time status checking, whereas CRL is only updated periodically (which is still very effective).

15. If you are dealing with a large-scale VPN infrastructure with hundreds or thousands of sites, it is a good idea to run SCEP to ensure that when the endpoint’s certificate expires, it can dynamically get a new cert.

16. When selecting the IKE identity, there are different strategies that can be used depending on the type of connection. For instance, for a standard site-to-site with static IP addresses, the IP address is usually good enough. For site-to-site where the spoke uses dynamic IP addresses, you can use an FQDN for a user@hostname with shared IKE if you have multiple users sharing the same IKE identity. Finally, if you are using an Auto-VPN or larger scale certificate-based model, you would leverage DN and Group-IKE-ID to support limiting the appropriate certificates. Auto-VPN is outside of the scope of this book, but it’s a good thing to keep in mind for future support.

17. It is typically a best practice to use numbered st0 interfaces rather than unnumbered interfaces because they offer much more interoperability and feature support, particularly for NAT and routing.

Troubleshooting and Operation

Once the configuration of the VPN is complete and committed, you should take some additional steps to ensure that the VPN is operational. You can also use these steps whenever there appears to be an issue with VPN establishment or connectivity. This section details the useful commands that can help provide information on the status of VPNs, as well as troubleshooting steps and available facilities that can provide advanced diagnostics for resolving VPN issues.

Useful VPN Commands

The SRX has several useful commands when it comes to determining the state of VPNs, including commands that identify specific aspects of VPNs.

show security ike security-associations

The show security ike security-associations command shows any VPNs that have passed Phase 1 and have an active IKE security association for Phase 1.

This command is important because if IKE fails to complete Phase 1, it can’t proceed to Phase 2. (An exception is that if the IKE Phase 1 lifetime expires before the Phase 2 lifetime expires, there might not be a listing for the IKE security association, although there will be one for Phase 2. However, when the Phase 2 security association expires, the Phase 1 IKE security association will need to be renegotiated first.)

The following output shows an actively established Phase 1 security association, first without the detail argument and then with the detail argument. There are lots of useful reasons for using the detail command to show the properties of the tunnel itself. It’s often most useful to define the peer gateway before the detail to only show a specific gateway’s status. When troubleshooting VPN establishment, you must first verify that Phase 1 is completed successfully before moving on to Phase 2, and this command helps provide that information.

 {primary:node1}
root@SRX100HM> show security ike active-peer
node1:
--------------------------------------------------------------------------
Remote Address       Port     Peer IKE-ID          XAUTH username     Assigned IP
99.18.0.11                           500      99.18.0.11

{primary:node1}
root@SRX100HM> show security ike security-associations detail
node1:
--------------------------------------------------------------------------
IKE peer 99.18.0.11, Index 13000261, Gateway Name: SFLD
  Role: Initiator, State: UP
  Initiator cookie: 4af4dbc0477fa2eb, Responder cookie: a9698c65f2417867
  Exchange type: Main, Authentication method: Pre-shared-keys
  Local: 173.167.1.14:500, Remote: 99.18.0.11:500
  Lifetime: Expires in 81973 seconds
  Peer ike-id: 99.18.0.11
  Xauth assigned IP: 0.0.0.0
  Algorithms:
   Authentication        : hmac-sha1-96
   Encryption            : aes128-cbc
   Pseudo random function: hmac-sha1
   Diffie-Hellman group  : DH-group-2
  Traffic statistics:
   Input  bytes  :                 1268
   Output bytes  :                 2340
   Input  packets:                    7
   Output packets:                   10
  Flags: IKE SA is created
  IPSec security associations: 2 created, 1 deleted
  Phase 2 negotiations in progress: 0

    Negotiation type: Quick mode, Role: Initiator, Message ID: 0
    Local: 173.167.1.14:500, Remote: 99.18.0.11:500
    Local identity: 173.167.224.13
    Remote identity: 99.182.0.14
    Flags: IKE SA is created

show security ipsec security-associations

Once Phase 1 has been established, you might need to determine whether Phase 2 has been successfully completed. A very useful command is the show security ipsec security-associations command. It will show the established Phase 2 security associations and applicable properties. The detail command provides much more information regarding the state of the VPN.

{primary:node1}
root@SRX100HM> show security ipsec security-associations
node1:
--------------------------------------------------------------------------
  Total active tunnels: 1
  ID    Algorithm       SPI      Life:sec/kb  Mon lsys Port  Gateway
  <131073 ESP:aes-128/sha1 56068996 792/ unlim -   root 500   99.182.0.14
  >131073 ESP:aes-128/sha1 31ac37d 792/ unlim  -   root 500   99.182.0.14
  <131073 ESP:aes-128/sha1 aac3e068 795/ unlim -   root 500   99.182.0.14
  >131073 ESP:aes-128/sha1 31ac37e 795/ unlim  -   root 500   99.182.0.14

{primary:node1}
root@SRX100HM> show security ipsec security-associations detail
node1:
--------------------------------------------------------------------------
  ID: 131073 Virtual-system: root, VPN Name: Southfield
  Local Gateway: 173.167.224.13, Remote Gateway: 99.182.0.14
  Local Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
  Remote Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
  Version: IKEv1
    DF-bit: copy
    Bind-interface: st0.0

  Port: 500, Nego#: 467, Fail#: 0, Def-Del#: 0 Flag: 600a29
  Tunnel Down Reason: Lifetime expired
    Direction: inbound, SPI: 56068996, AUX-SPI: 0
                              , VPN Monitoring: -
    Hard lifetime: Expires in 784 seconds
    Lifesize Remaining:  Unlimited
    Soft lifetime: Expires in 202 seconds
    Mode: Tunnel(0 0), Type: dynamic, State: installed
    Protocol: ESP, Authentication: hmac-sha1-96, Encryption: aes-cbc (128 bits)
    Anti-replay service: counter-based enabled, Replay window size: 64

    Direction: outbound, SPI: 31ac37d, AUX-SPI: 0
                              , VPN Monitoring: -
    Hard lifetime: Expires in 784 seconds
    Lifesize Remaining:  Unlimited
    Soft lifetime: Expires in 202 seconds
    Mode: Tunnel(0 0), Type: dynamic, State: installed
    Protocol: ESP, Authentication: hmac-sha1-96, Encryption: aes-cbc (128 bits)
    Anti-replay service: counter-based enabled, Replay window size: 64

    Direction: inbound, SPI: aac3e068, AUX-SPI: 0
                              , VPN Monitoring: -
    Hard lifetime: Expires in 787 seconds
    Lifesize Remaining:  Unlimited
    Soft lifetime: Expires in 176 seconds
    Mode: Tunnel(0 0), Type: dynamic, State: installed
    Protocol: ESP, Authentication: hmac-sha1-96, Encryption: aes-cbc (128 bits)
    Anti-replay service: counter-based enabled, Replay window size: 64

    Direction: outbound, SPI: 31ac37e, AUX-SPI: 0
                              , VPN Monitoring: -
    Hard lifetime: Expires in 787 seconds
    Lifesize Remaining:  Unlimited
    Soft lifetime: Expires in 176 seconds
    Mode: Tunnel(0 0), Type: dynamic, State: installed
    Protocol: ESP, Authentication: hmac-sha1-96, Encryption: aes-cbc (128 bits)
    Anti-replay service: counter-based enabled, Replay window size: 64

show security ipsec inactive-tunnels

This command shows you any tunnels that aren’t active. Especially when you are dealing with a large VPN infrastructure, it can be more important to view the tunnels that are not up and running to determine if there is an issue rather than trying to search for every tunnel that should be up and running. That’s exactly what this command does.

{primary:node1}
root@SRX100HM> show security ipsec inactive-tunnels
node1:
--------------------------------------------------------------------------
  Total inactive tunnels: 1
  Total inactive tunnels with establish immediately: 0
  ID     Port  Nego#  Fail#  Flag      Gateway          Tunnel Down Reason
  131073 500   469    0      600a29    99.182.0.14      Cleared via CLI

show security ipsec statistics

It’s always useful to gather high-level information regarding how the platform is processing security information, including issues with encryption and decryption. The command show security ipsec statistics provides such useful information, including the number of encrypted and decrypted ESP and AH packets, as well as the different types of failures. You can check this command multiple times when trying to determine if the number of failures and errors is increasing.

 {primary:node1}
root@SRX100HM> show security ipsec statistics
node0:
--------------------------------------------------------------------------

ESP Statistics:
  Encrypted bytes:                0
  Decrypted bytes:                0
  Encrypted packets:              0
  Decrypted packets:              0
AH Statistics:
  Input bytes:                    0
  Output bytes:                   0
  Input packets:                  0
  Output packets:                 0
Errors:
  AH authentication failures: 0, Replay errors: 0
  ESP authentication failures: 0, ESP decryption failures: 0
  Bad headers: 0, Bad trailers: 0

node1:
--------------------------------------------------------------------------

ESP Statistics:
  Encrypted bytes:       1739394688
  Decrypted bytes:       2837890889
  Encrypted packets:        7337056
  Decrypted packets:        9923867
AH Statistics:
  Input bytes:                    0
  Output bytes:                   0
  Input packets:                  0
  Output packets:                 0
Errors:
  AH authentication failures: 0, Replay errors: 0
  ESP authentication failures: 0, ESP decryption failures: 0
  Bad headers: 0, Bad trailers: 0

Note

You can clear the information with the clear security ipsec statistics command.

Checking interface statistics

It can be helpful to check the interface statistics of the interface where the VPN is terminating because there can be some very good information there. In this example, we look at the reth0.0 interface.

{primary:node1}
root@SRX100HM> show interfaces reth0.0 extensive
  Logical interface reth0.0 (Index 69) (SNMP ifIndex 531) (Generation 134)
    Flags: SNMP-Traps 0x0 Encapsulation: ENET2
    Statistics        Packets        pps         Bytes          bps
    Bundle:
        Input :      59888370         49   18111686816        68000
        Output:     167667336        106  196744917958       939632
    Link:
      fe-1/0/1.0
        Input :      59888370         49   18111686816        68000
        Output:     167667336        106  196744917958       939632
      fe-0/0/1.0
        Input :             0          0             0            0
        Output:             0          0             0            0
    Marker Statistics:   Marker Rx     Resp Tx   Unknown Rx   Illegal Rx
      fe-1/0/1.0                 0           0            0            0
      fe-0/0/1.0                 0           0            0            0
    Security: Zone: Danger
    Allowed host-inbound traffic : ike ping
    Flow Statistics :
    Flow Input statistics :
      Self packets :                     742416
      ICMP packets :                     255719
      VPN packets :                      9926999
      Multicast packets :                0
      Bytes permitted by policy :        14558953261
      Connections established :          13929614
    Flow Output statistics:
      Multicast packets :                0
      Bytes permitted by policy :        140828777920
    Flow error statistics (Packets dropped due to):
      Address spoofing:                  0
      Authentication failed:             0
      Incoming NAT errors:               0
      Invalid zone received packet:      0
      Multiple user authentications:     0
      Multiple incoming NAT:             0
      No parent for a gate:              0
      No one interested in self packets: 0
      No minor session:                  0
      No more sessions:                  0
      No NAT gate:                       0
      No route present:                  74280
      No SA for incoming SPI:            117
      No tunnel found:                   0
      No session for a gate:             0
      No zone or NULL zone binding       0
      Policy denied:                     237
      Security association not active:   12480
      TCP sequence number out of window: 24
      Syn-attack protection:             0
      User authentication errors:        0
    Protocol inet, MTU: 1500, Generation: 148, Route table: 4
      Flags: Sendbcast-pkt-to-re, Is-Primary
      Input Filters: Inbound-QoS
      Addresses, Flags: Is-Default Is-Preferred Is-Primary
        Destination: 173.167.224.0/28, Local: 173.167.224.13, Broadcast: 173.167.224.15, Generation: 145

You can see in the preceding output there are some useful counters that are tracked on the interface-by-interface basis. These self-explanatory counters can help you identify a potential issue with IPsec setup.

VPN Tracing and Debugging

When the information contained within the output of the show commands is not enough to determine the root cause of VPN negotiation failures, more detailed information is required to determine where the message breakdown occurs. The SRX offers detailed breakdowns of the debugging of VPN establishment, even down to the individual IPsec messages that are sent and received by the SRX. Let’s cover the individual troubleshooting steps that you can use to help troubleshoot a VPN issue. Then we discuss how to perform tracing and, finally, what to look for in the output.

{primary:node1}
root@SRX100HM> request security ike debug-enable local 173.167.224.13 remote 99.182.0.14 level 15

{primary:node1}
root@SRX100HM> show log kmd
Feb 17 18:55:20 SRX100HM clear-log[53078]: logfile cleared

{primary:node1}
root@SRX100HM> clear security ike security-associations

{primary:node1}
root@SRX100HM> show log kmd
Feb 17 18:55:20 SRX100HM clear-log[53078]: logfile cleared
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  iked_ha_check_ike_sa_activeness_by_rg_id:RG 1 is active on this chassiss
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  iked_ha_check_ike_sa_activeness_by_rg_id:RG 1 is active on this chassiss
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  Initiate IKE P1 SA 13000278 delete. curr ref count 1, del flags 0x2
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  iked_pm_ike_sa_delete_notify_done_cb: For p1 sa index 13000278, ref cnt 1, status: Error ok
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  ssh_set_debug_gw_info: ssh_set_debug_gw_info: set gw debug info - local 173.167.224.13 remote 99.182.0.14
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  ike_expire_callback: Start, expire SA = { e749e216 6d85b041 - 720b8a27 af119af8}, nego = −1
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  iked_ha_check_ike_sa_activeness_by_rg_id:RG 1 is active on this chassiss
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  ike_alloc_negotiation: Start, SA = { e749e216 6d85b041 - 720b8a27 af119af8}
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  ike_alloc_negotiation: Found slot 1, max 2
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  ike_init_info_exchange: New informational negotiation message_id = a524ef42 initialized using slot 1
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  ike_init_info_exchange: Created random message id = a524ef42
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  ike_init_info_exchange: Phase 1 done, use HASH and N or D payload
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  ike_encode_packet: Start, SA = { 0xe749e216 6d85b041 - 720b8a27 af119af8 } / a524ef42, nego = 1
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  ike_encode_packet: Payload length = 24
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  ike_encode_packet: Payload length = 28
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  ike_encode_packet: Packet length = 92
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  ike_encode_packet: Calling finalizing function for payload[0].type = 8
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  ike_encode_packet: Encrypting packet
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  ike_encode_packet: Final length = 92
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  ike_expire_callback: Sending notification to 99.182.0.14:500
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  ike_send_packet: Start, send SA = { e749e216 6d85b041 - 720b8a27 af119af8}, nego = 1, dst = 99.182.0.14:500,  routing table id = 4
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  ike_free_packet: Start
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  ike_delete_negotiation: Start, SA = { e749e216 6d85b041 - 720b8a27 af119af8}, nego = 1
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  ike_free_negotiation_info: Start, nego = 1
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  ike_free_negotiation: Start, nego = 1
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  ikev2_fb_phase_ii_sa_freed: Phase-II free Entered
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  ssh_set_debug_gw_info: ssh_set_debug_gw_info: set gw debug info - local 173.167.224.13 remote 99.182.0.14
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  ike_remove_callback: Start, delete SA = { e749e216 6d85b041 - 720b8a27 af119af8}, nego = −1
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  ike_delete_negotiation: Start, SA = { e749e216 6d85b041 - 720b8a27 af119af8}, nego = −1
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  ssh_ike_tunnel_table_entry_delete: Deleting tunnel_id: 0 from IKE tunnel table
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  ssh_ike_tunnel_table_entry_delete: The tunnel id: 0 doesn't exist in IKE tunnel table
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  ike_sa_delete: Start, SA = { e749e216 6d85b041 - 720b8a27 af119af8 }
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  ike_free_negotiation_qm: Start, nego = 0
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  ike_free_negotiation: Start, nego = 0
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  ike_free_packet: Start
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  ike_free_packet: Start
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  ike_free_packet: Start
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  ikev2_fb_qm_sa_freed: QM free Entered
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  ike_free_id_payload: Start, id type = 4
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  ike_free_id_payload: Start, id type = 4
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  ike_free_id_payload: Start, id type = 4
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  ike_free_id_payload: Start, id type = 4
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  ike_free_negotiation_isakmp: Start, nego = −1
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  ike_free_negotiation: Start, nego = −1
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  ikev2_fb_isakmp_sa_freed: Received notification from the ISAKMP library that the IKE SA dfe400 is freed
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  ikev2_fb_isakmp_sa_freed: FB; Calling v2 policy function ike_sa_delete
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  IKE SA delete called for p1 sa 13000278 (ref cnt 1) local:173.167.224.13, remote:99.182.0.14, IKEv1
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  P1 SA 13000278 stop timer. timer duration 30, reason 0.
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  iked_ha_check_ike_sa_activeness_by_rg_id:RG 1 is active on this chassiss
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  iked_del_ha_blob: Error deleting blob with type = phase1 mod, tunnel id 0.  Error: No such file or directory
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  Deleted the blob requested
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  Freeing reference to P1 SA 13000278 to ref count 0
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  iked_pm_p1_sa_destroy:  p1 sa 13000278 (ref cnt 0), waiting_for_del 0x0
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  iked_peer_remove_p1sa_entry: Remove p1 sa 13000278 from peer entry 0xdeb400
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  Deleting p1 sa (13000278) node from IKE p1 SA P-tree
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  ikev2_udp_window_uninit: Freeing transmission windows for SA dfe400
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  ike_free_id_payload: Start, id type = 1
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  ike_free_id_payload: Start, id type = 1
[Feb 17 18:59:57][173.167.224.13 <-> 99.182.0.14]  ike_free_sa: Start

It’s not possible to review every message that is discussed here, but the key is that by running this debug, if you are familiar with the general nomenclature of the SRX debug information, it should provide you with a very good breakdown of what’s happening step by step and any potential errors that you might see along the way. This can be used in conjunction with the VPN troubleshooting process, discussed next.

VPN troubleshooting process

Follow these steps when troubleshooting a VPN issue:

1. Verify that the peer gateway is reachable. If there is an issue with routing to the remote gateway, or if a device is limiting access (e.g., IKE traffic, ESP/AH traffic, NAT-T tunneled traffic), VPN establishment will fail. Basic tests could include ping and traceroute (assuming that these services are available on the remote device) to ensure that routing is functioning properly and there are no ISP issues. The following services should not be blocked by any device between the SRX and the remote peer.

   1. UDP port 500 (default port for IKE negotiation). If this is blocked, IKE negotiation will fail, with messages on the initiating gateway indicating that the connection limit has been reached. On the responder device, there will be no messages at all because the IKE traffic will not have reached the gateway.

   2. IP Protocol 50 (ESP) if using ESP. If this is blocked, IKE negotiation might complete successfully, but VPN traffic will not be able to communicate when using ESP.

   3. IP Protocol 51 (AH) if using AH. If this is blocked, IKE negotiation might complete successfully, but VPN traffic will not be able to communicate when using AH.

   4. UDP port 4500 (default port for NAT-T). If this is blocked, IKE negotiation might complete successfully, but VPN traffic will not be able to communicate when using NAT-T.

2. Check the access lists and zone settings. On the SRX, if an access list is enabled on the external interface terminating the VPN or the lo0 interface that blocks any of the services mentioned in Step 1, the VPN will not be able to establish. Additionally, the SRX requires IKE to be enabled on the interface, or in the zone of the external interface as a host-inbound-traffic system service (it can be at the zone or interface level, with the interface level overriding the zone level). Make sure this is enabled; otherwise, the VPN will fail to establish.

3. Check whether hostnames are used for the gateway. You can optionally define the gateway address as a DNS address rather than an IP address. In this case, DNS must be enabled and functioning properly to be able to identify the remote gateway. Configuring multiple DNS servers often helps in case of a DNS server failure.

4. Check whether the VPN is terminating on the correct interface. In Phase 1 of the VPN, you must define on which interface the VPN will terminate. If the VPN is trying to terminate on a different interface (even if the logical unit is wrong), the VPN will fail to establish.

5. Check whether both nodes are trying to use the same IKE version.

6. Check whether the Phase 1 modes match on both gateways. Both gateways must use the same Phase 1 mode, either Main mode or Aggressive mode. If the modes don’t match, the VPN establishment will fail.

7. Check whether the Phase 1 proposals match. The Phase 1 proposals must match on both VPN gateways. If they do not match, negotiations will fail. The SRX supports up to four proposals, so if the first proposal negotiation fails, it will try the other proposals if available, but if there are no matches the negotiations will fail in Phase 1. Check the proper combination of certificate versus PSK, encryption and authentication algorithms, along with the proper Diffie-Hellman groups.

8. Check whether the IKE identities are configured correctly. As mentioned, there are a few different types of IKE identities, namely IP address, FQDN, and UFQDN. You can define the local identity (to be presented to the peer) and the peer identity (to be presented by the peer). The local and peer must match on the respective systems or else Phase 1 will fail.

9. Check whether the Phase 1 authentication is properly configured. There are two types of Phase 1 authentication: preshared keys and certificates. In the case of preshared keys, the preshared keys must match on both VPN gateways for the VPN to complete Phase 1. In the case of certificates, the certificate presented must be signed by a trusted CA (configured to work for the VPN). Next, if certificate revocation checking is enabled, the certificate must not be revoked for the authentication to pass.

10. If XAuth is used, check whether authentication is succeeding. XAuth occurs between Phase 1 and Phase 2 of the VPN establishment process. At the time of this writing, XAuth is only supported for authentication of RADIUS users and not local users on the firewall. If XAuth authentication does not succeed, authentication will fail before Phase 2.

11. Check whether PFS is configured. If PFS is configured, it must be configured on both gateways. Additionally, the same Diffie-Hellman groups must be used between the peers for PFS. Note that the Diffie-Hellman groups do not need to be the same as what is used in Phase 1; however, both peers must use the same group in the PFS configuration.

12. Check whether Phase 2 proposals match. Just like Phase 1, the Phase 2 proposals must match on both ends (including encryption and authentication algorithms). If they don’t match, Phase 2 negotiations will fail. Up to four proposals may be defined and will be negotiated in order of definition if the previous proposal fails, but if no proposal matches, the Phase 2 proposals will fail.

13. Check whether the proxy IDs match. This is probably the most common reason for VPN negotiations to fail, especially when trying to establish VPNs between different vendors. Proxy IDs can be manually defined in the Phase 2 IPsec VPN configuration, or they can be derived from the respective policies that are used for the VPN in the case of policy-based VPNs. Doing a trace will show whether the VPN is failing due to proxy ID mismatch, but this is something to be aware of.

14. Check whether the key lifetimes match. This isn’t an explicitly required parameter, but sometimes this could matter with other vendors’ implementations of IPsec VPNs, so it is best to set the VPNs to support the same key lifetimes to ensure proper interoperability.

15. If policy-based VPNs are enabled, check whether the correct policy is being matched. With policy-based VPNs, the traffic should match the correct policy. If it is not matching the correct policy, this might be a result of the incorrect policy configuration, or a routing issue or misconfiguration. Remember that even in the case of policy-based VPNs, the SRX must know what the egress interface and, thus, the egress zone is to match the correct from-to-zone pair. It doesn’t matter whether static or dynamic routing is used; the routing must be properly configured. Doing a simple flow trace will identify whether the traffic is being matched to the correct policy along with the correct routing information. Also, make sure the policy is configured to tunnel the traffic to the correct VPN.

16. If route-based VPNs are configured, check whether proper routing and security policies are configured. With a route-based VPN, you still need to define the correct security policy to permit the traffic. If the traffic is not being permitted by policy, it cannot enter the VPN. You can determine this by doing a flow debug to enable logging on the policies to ensure that the traffic is being permitted. Additionally, with route-based VPNs, the appropriate routing must be configured to route the traffic into the correct tunnel interface. Both static and dynamic routing can be used, but in the case of dynamic routing, you must make sure the applicable protocols are enabled on the tunnel interface (from the protocol configuration, along with the host-inbound-traffic protocol configuration).

17. If route-based VPNs are configured, check whether the VPN is bound to the correct interface. Route-based VPNs must be bound to the correct interface. If they are bound to the wrong interface, VPN negotiation might establish, but the traffic will not go through the right VPN.

18. Check whether NAT is occurring between the two VPN gateways. If so, NAT-T must be enabled (primarily for remote access VPNs and not site-to-site VPNs) because the ESP/AH packets will be modified, which will invalidate the hash for integrity checking.

19. If all else fails, check the release notes to see if there are any known issues for the release of Junos you are running, and check the Knowledge Base. If you still cannot find an answer, contact JTAC for additional assistance in troubleshooting.

Configuring and analyzing VPN tracing

Troubleshooting IPsec has come a long way since the last edition of the Junos Security book. You still can set up VPN tracing under the IKE/IPsec traceoptions and have them log to the box, but that’s not the best way to go about things. One challenge of that solution was that it did not work well when you had numerous VPNs because the output was far too verbose, particularly across all of the sites. Instead Juniper has developed a targeted VPN debugging facility where you specify the local and remote IP addresses and enable the debug accordingly. The benefit of this model is that you can hone in on the specific VPN that you want to debug, and it works for both site-to-site and remote VPNs.

Sample Deployments

Although there are truly limitless combinations of VPN configurations that we could discuss, most often VPN configurations will be quite similar. This section discusses the two main types of VPNs: a site-to-site VPN (with multiple remote sites) and a VPN that connects a remote IPsec client.

Site-to-Site VPN

The goal of this case study is to establish site-to-site VPNs between the Campus Core and the three remote offices (East, West, and South Branches). The following properties should be present for this configuration, as shown in Figure 10-7:

Figure 10-7. Case study network diagram

• VPNs should use Main mode in a point-to-multipoint configuration.

• OSPF should be used as a dynamic routing protocol for this example on the tunnel interfaces, with all st0 interfaces in Area 0. Because this isn’t true broadcast, define neighbors in the configuration.

• The architecture will be hub and spoke (utilizing point-to-multipoint VPNs).

• The st0 interface should be in the VPN zone. Use the following IP addressing for the st0 interfaces on the Campus Core and the remote offices:

  • Campus Core: 192.168.100.5/24

  • East Branch: 192.168.100.1/24

  • West Branch: 192.168.100.2/24

  • South Branch: 192.168.100.3/24

• Only the respective networks for each side should be allowed through the VPN, with any service allowed between the networks.

• The Phase 1 proposal should use 3DES SHA-1 with preshared keys. The key will be 8aifMhau%% using Diffie-Hellman Group 2.

• Phase 2 of the VPN should use AES128-SHA1 as the proposal, and no PFS.

• Branch VPN gateways should use 198.18.5.254 as the primary VPN connection and 198.18.4.254 as the backup.

• Ensure that IKE can be terminated on the external interfaces in the untrust zone.

• IKEv2 should be used for the West and South Branch, and use only IKEv1 on the East Branch.

• For the proxy ID, just use local-id 0.0.0.0/0, remote-id 0.0.0.0, and service Any to simplify the IKE configuration to the respective gateways, and demonstrate that proxy IDs only impact negotiation by making sure both sides match, but not what traffic can pass through the VPN.

/*This Phase 1 Proposal is Applied to Campus and Remote Offices*/
[edit security ike proposal Remote-Office-PSK]
root@SRX5800# show
authentication-method pre-shared-keys;
dh-group group2;
authentication-algorithm sha1;
encryption-algorithm 3des-cbc;
/*This Phase 1 Policy is Applied to Campus and East Branch*/
[edit security ike policy Remote-Office-Static]
root@SRX5800#show
mode main;
proposals Remote-Office-PSK;
pre-shared-key ascii-text "$9$hA7cvWLX-VwgEc7dVsJZUjHqT3AtuREc"; ## SECRET-DATA

/*This Policy is Applied to South and West Branches*/
[edit security ike policy Remote-Office-Static]
root@SRX5800#show
proposals Remote-Office-PSK;
pre-shared-key ascii-text "$9$hA7cvWLX-VwgEc7dVsJZUjHqT3AtuREc"; ## SECRET-DATA


/*Getway Configuration on the Campus Core SRX*/
[edit security ike gateway Eastbranch-Remote-Office]
root@SRX5800# show
ike-policy Remote-Office-Static;
address 198.18.1.254;
dead-peer-detection {
    interval 10;
    threshold 3;
}
no-nat-traversal;
external-interface ge-0/0/0.0;
version v1-only

[edit security ike gateway Westbranch-Remote-Office]
root@SRX5800# show
ike-policy Remote-Office-Static;
address 198.18.2.254;
dead-peer-detection {
    interval 10;
    threshold 3;
}
no-nat-traversal;
external-interface ge-0/0/0.0;
version v2-only

[edit security ike gateway Southbranch-Remote-Office]
root@SRX5800# show
ike-policy Remote-Office-Static;
address 198.18.3.254;
dead-peer-detection {
    interval 10;
    threshold 3;
}
no-nat-traversal;
external-interface ge-0/0/0.0;
version v2-only

/*Gateway Configuration on the South and West Offices*/
[edit security ike gateway Eastbranch-Remote-Office]
root@SRX650# show
ike-policy Remote-Office-Static;
address [ 198.18.5.254 198.18.4.254 ];
dead-peer-detection {
    interval 10;
    threshold 3;
}
no-nat-traversal;
external-interface ge-0/0/0.0;
version v2-only

/*Gateway Configuration on the East Offices*/
[edit security ike gateway Eastbranch-Remote-Office]
root@SRX650# show
ike-policy Remote-Office-Static;
address [ 198.18.5.254 198.18.4.254 ];
dead-peer-detection {
    interval 10;
    threshold 3;
}
no-nat-traversal;
external-interface ge-0/0/0.0;
version v2-only



/*This Zone Configuration is applied to Campus and Remote Offices*/
[edit security zones security-zone untrust host-inbound-traffic system-services]
root@SRX5800#show
ike;
/*Phase 2 Proposal is applied to Campus and Remote Offices*/
[edit security ipsec proposal Remote-Offices]
root@SRX5800# show
protocol esp;
authentication-algorithm hmac-sha1-96;
encryption-algorithm aes-128-cbc;
/*Phase 2 Proposal is applied to Campus and Remote Offices*/
[edit security ipsec policy Remote-Offices]
root@SRX5800# show
proposals Remote-Offices
/*Phase 2 VPN Configuration for Campus Core*/
[edit security ipsec vpn East-Branch]
root@SRX5800# show
bind-interface st0.0;
ike {
    gateway East-Branch;
    proxy-identity {
        local 0.0.0.0/0;
        remote 0.0.0.0/0;
        service any;
    }
    ipsec-policy Remote-Offices;
}

[edit security ipsec vpn West-Branch]
root@SRX5800# show
bind-interface st0.0;
ike {
    gateway West-Branch;
    proxy-identity {
        local 0.0.0.0/0;
        remote 0.0.0.0/0;
        service any;
    }
    ipsec-policy Remote-Offices;
}

[edit security ipsec vpn South-Branch]
root@SRX5800# show
bind-interface st0.0;
ike {
    gateway South-Branch;
    proxy-identity {
        local 0.0.0.0/0;
        remote 0.0.0.0/0;
        service any;
    }
    ipsec-policy Remote-Offices;
}
/*Phase 2 VPN Configuration for Remote Gateways*/
[edit security ipsec vpn Campus-Core]
root@SRX650# show
bind-interface st0.0;
ike {
    gateway Campus-Core;
    proxy-identity {
        local 0.0.0.0/0;
        remote 0.0.0.0/0;
        service any;
    }
    ipsec-policy Remote-Offices;
}


/*ST0 Configuration for Campus Core*/
[edit interfaces st0]
root@SRX5800#
unit 0 {
    multpoint;
    family inet {
        address 192.168.100.5/24;
    }
}
/*ST0 Configuration for East-Branch*/
[edit interfaces st0]
root@SRX650#
unit 0 {
    family inet {
        address 192.168.100.1/24;
    }
}
/*ST0 Configuration for West-Branch*/
[edit interfaces st0]
root@SRX240#
unit 0 {
    family inet {
        address 192.168.100.2/24;
    }
}
/*ST0 Configuration for South-Branch*/
[edit interfaces st0]
root@SRX210#
unit 0 {
    family inet {
        address 192.168.100.3/24;
    }
}
/*ST0 Zone Configuration for Campus Core and Remote Offices*/
[edit security zones security-zones vpn]
root@SRX5800#show
interfaces {
        st0.0 {
            host-inbound-traffic {
                system-services {
                    ike;
                }
                protocols {
                    ospf;
                }
}
/*OSPF Protocol Configuration for Campus Core*/
[edit protocols]
root@SRX5800#show
ospf {
    area 0.0.0.0 {
        interface st0.0 {
            neighbor 192.168.100.1;
           neighbor 192.168.100.2;
           neighbor 192.168.100.3;
        interface-type p2mp;
        dynamic-neighbor
        }
    }
}
/*OSPF Protocol Configuration for Remote Offices*/
[edit protocols]
root@SRX5800#show
ospf {
    area 0.0.0.0 {
        interface st0.0 {
            neighbor 192.168.100.5;
          dynamic-neighbor;
        }
    }
}
/*Security Policies for Route-Based VPN Campus Core*/


[edit]
root@SRX5800# show security zones security-zone trust address-book
address 10.0.0.0/8 10.0.0.0/8;


[edit]
root@SRX5800# show security zones security-zone vpn address-book
address 192.168.1.0/24 192.168.1.0/24;
address 192.168.2.0/24 192.168.2.0/24;
address 192.168.3.0/24 192.168.3.0/24;



[edit security policies from-zone trust to-zone vpn policy Remote-Offices]
root@SRX5800# show
match {
        source-address 10.0.0.0/8;
        destination-address [ 192.168.1.0/24 192.168.2.0/24 192.168.3.0/24 ];
        application any;
        }
 then {
        permit
        log {
                session-close;
            }
  }

[edit security policies from-zone vpn to-zone trust policy Remote-Offices]
root@SRX5800# show
match {
        source-address [ 192.168.1.0/24 192.168.2.0/24 192.168.3.0/24 ];
        destination-address 10.0.0.0/8;
        application any;
        }
 then {
        permit
        log {
                session-close;
            }
  }
/*Security Policies for Route-Based VPN East-Branch Core*/


[edit]
root@SRX650# show security zones security-zone vpn address-book
address 10.0.0.0/8 10.0.0.0/8;
address 192.168.2.0/24 192.168.2.0/24;
address 192.168.3.0/24 192.168.3.0/24;



[edit]
root@SRX650# show security zones security-zone trust address-book
address 192.168.1.0/24 192.168.1.0/24;



[edit security policies from-zone trust to-zone vpn policy Remote-Offices]
root@SRX650# show
match {
        source-address 192.168.1.0/24;
        destination-address [10.0.0.0/8 192.168.2.0/24 192.168.3.0/24 ];
        application any;
        }
 then {
        permit
        log {
                session-close;
            }
  }

[edit security policies from-zone vpn to-zone trust policy Remote-Offices]
root@SRX650# show
match {
        source-address [ 10.0.0.0/8 192.168.2.0/24 192.168.3.0/24 ];
        destination-address 192.168.1.0/24;
        application any;
        }
 then {
        permit
        log {
                session-close;
            }
  }
/*Security Policies for Route-Based VPN West-Branch Core*/


[edit]
root@SRX240# show security zones security-zone vpn address-book
address 10.0.0.0/8 10.0.0.0/8;
address 192.168.1.0/24 192.168.1.0/24;
address 192.168.3.0/24 192.168.3.0/24;



[edit]
root@SRX240# show security zones security-zone trust address-book
address 192.168.2.0/24 192.168.2.0/24;



[edit security policies from-zone trust to-zone vpn policy Remote-Offices]
root@SRX240# show
match {
        source-address 192.168.2.0/24;
        destination-address [10.0.0.0/8 192.168.1.0/24 192.168.3.0/24 ];
        application any;
        }
 then {
        permit
        log {
                session-close;
            }
  }

[edit security policies from-zone vpn to-zone trust policy Remote-Offices]
root@SRX240# show
match {
        source-address [ 10.0.0.0/8 192.168.1.0/24 192.168.3.0/24 ];
        destination-address 192.168.2.0/24;
        application any;
        }
 then {
        permit
        log {
                session-close;
            }
  }
/*Security Policies for Route-Based VPN South-Branch Core*/


[edit]
root@SRX210# show security zones security-zone vpn address-book
address 10.0.0.0/8 10.0.0.0/8;
address 192.168.1.0/24 192.168.1.0/24;
address 192.168.2.0/24 192.168.2.0/24;



[edit]
root@SRX210# show security zones security-zone trust address-book
address 192.168.3.0/24 192.168.3.0/24;



[edit security policies from-zone trust to-zone vpn policy Remote-Offices]
root@SRX210# show
match {
        source-address 192.168.3.0/24;
        destination-address [10.0.0.0/8 192.168.1.0/24 192.168.2.0/24 ];
        application any;
        }
 then {
        permit
        log {
                session-close;
            }
  }

[edit security policies from-zone vpn to-zone trust policy Remote-Offices]
root@SRX210# show
match {
        source-address [ 10.0.0.0/8 192.168.1.0/24 192.168.2.0/24 ];
        destination-address 192.168.3.0/24;
        application any;
        }
 then {
        permit
        log {
                session-close;
            }
  }

Remote Access VPN

The goal of this case study is to configure an IPsec client VPN on the SRX. The configurations will largely be the same as in the preceding case study, except where noted. The configuration should be set up as follows:

• Phase 1 should use Aggressive mode, and PFS (Diffie-Hellman Group2) should be used to secure the VPN, terminated on the ge-0/0/0 Untrust interface.

• For the standard-based IPsec client, use an IKE identity of [e-mail]. No specific client software will be examined here; however, any standards-based client implementation should interoperate with this example.

• Phase 1 should use 3DES-MD5 for the proposal with Diffie-Hellman Group 2.

• Use the preshared key 71hajfy44.

• Phase 2 should use AES128-SHA1 with ESP Tunnel mode for the proposal.

• Use a policy-based VPN for this configuration to allow the clients access to the Campus Core networks (10.0.0.0/8).

/* IPSec Remote Client*/
[edit security ike proposal Remote-Client]
root@SRX5800# show
authentication-method pre-shared-keys;
dh-group group2;
authentication-algorithm md5;
encryption-algorithm 3des-cbc;

[edit security ike policy Remote-Client]
root@SRX5800#show
mode aggressive;
proposals Remote-Office-PSK;
pre-shared-key ascii-text "$9$VWYJGDikqmTX74ZDif5revM7-s24"; ## SECRET-DATA

[edit security ike gateway Remote-Client]
root@SRX5800# show
ike-policy Remote-Client;
dynamic {
    user-at-hostname [e-mail];
}
external-interface ge-0/0/0.0;

[edit security ipsec proposal Remote-Client]
root@SRX5800# show
protocol esp;
authentication-algorithm hmac-sha1-96;
encryption-algorithm aes-128-cbc;

[edit security ipsec policy Remote-Client]
root@SRX5800# show
perfect-forward-secrecy {
    keys group2;
}
proposals Remote-Client;

[edit security ipsec vpn Remote-Client]
root@SRX5800# show
ike {
    gateway Remote-Client;
}
ipsec-policy Remote-Client;

[edit security zones security-zones trust address-book]
root@SRX5800# show
address 10.0.0.0/8 10.0.0.0/8;

[edit security policies from-zone untrust to-zone trust policy Remote-Client]
root@SRX5800# show
match {
        source-address any;
        destination-address 10.0.0.0/8;
        application any;
        }
 then {
        permit {
               tunnel {
                 ipsec-vpn Remote-Client;
                }
         }
            log {
                session-close;
            }
  }

[edit security zones security-zone untrust host-inbound-traffic system-services]
root@SRX5800#show
ike;

IPsec Caveats on SRX

We’ve discussed a few caveats with IPsec in this chapter, and we want to summarize them in a single section. It’s important to understand that Juniper is working on closing the gaps in many of these caveats, so regularly check the release notes for the latest and greatest.

• IPsec is not supported when the SRX is in Transparent mode.

• Transport mode is not supported for IPsec; use Tunnel mode instead.

• When terminating an IPsec VPN with LSYS, the VPN must be terminated in the root LSYS but the st0 interface can be placed within a child LSYS.

• Policy-based VPNs are targeted to very simple use cases without complex routing and NAT use cases. It is best to use route-based VPNs for anything but the simplest of scenarios.

• Remote access VPNs are limited to IKEv1 and don’t support bidirectional traffic today.

• Before Junos 11.1, there were challenges with terminating VPNs in non-inet.0 VRs including where st0 was placed, but this has largely been resolved in more modern versions.

• Terminating VPNs on local interfaces in active/active HA is not supported.

• NAT-T had several limitations prior to 11.4R4 with the different modes that were supported. If you are having issues when using NAT-T, you might want to be on Junos 11.4r4+ to support the newer modes for better interoperability.

• IPv6 for IPsec Phase 1 is currently in beta testing at the time of writing this book. The features and functionality will be coming to Junos, but we can’t give an exact readout at the moment. Work with your Juniper account team to get a roadmap, and—even better—get involved with beta testing!

Summary

IPsec VPNs have been a core tenet of network security and stateful firewalls for well over a decade. Their importance cannot be overstated, even in a constantly evolving era of new applications, virtualization, cloudy technologies, Software Defined Networking (SDN), and globalization. IPsec VPNs will definitely play an increasingly important role going forward. Writing a single chapter about IPsec is a very difficult task to undertake, as there are entire books written just explaining how the concepts themselves function, let alone the actual vendor implementation. In addition, the SRX is an extensive platform when it comes to IPsec and is greatly extending the capabilities of IPsec going forward, extending the GroupVPN, AutoVPN, IPv6, and other large-scale tunneling support. It’s definitely a very exciting time to be a part of the SRX development team when it comes to IPsec!

In this chapter, we covered a wide variety of the most common IPsec technologies that most network administrators are likely to interact with when building site-to-site and remote access VPNs. We couldn’t cover some of the more advanced esoteric technologies in this book due to space and scope, but to leverage any of those technologies you’ll need to have mastered these technologies first, not to mention the troubleshooting and operation components that can be leveraged for both mechanisms. If you have a solid understanding of the concepts in this chapter, you should be able to deploy the several primary IPsec functions in most real-world scenarios and have no problem with the IPsec section of the JNCIE-Sec certification!

Study Questions

Questions

1. What are the differences between IKEv1 and IKEv2?

2. What is the purpose of IKEv1 Phase 1 in IPsec negotiations?

3. With IKEv1, what is the difference between Main and Aggressive modes, and in which phase of negotiations do they occur?

4. Why would Aggressive mode be necessary instead of Main mode?

5. How many Phase 1 and Phase 2 proposals can be configured on the SRX, and how are they evaluated?

6. What is PFS and what purpose does it serve?

7. What are the advantages and disadvantages of policy-based VPNs versus route-based VPNs?

8. What is the difference between point-to-point and point-to-multipoint VPNs?

9. What is the difference between numbered and unnumbered st0 interfaces?

10. What is the difference between DPD and VPN monitoring?

11. What is NAT-T and when must it be used?

12. What are the advantages and disadvantages of certificate authentication versus preshared key authentication?

13. What is a proxy ID, how is it used in IPsec negotiations, and why is it a common cause of VPN establishment issues?

14. What are the two settings that define how VPN tunnels should be triggered for setup?

15. What must you configure at the zone level before IPsec tunnels can be established on the SRX?

16. What is the difference between a CRL, OSCP, and SCEP when it comes to certificate authentication?

17. What does DH stand for, and how is it used by IPsec technologies?

18. How does the SRX handle DSCP bits of original packets for the tunneled traffic? What about DF bits?

19. Can third-party IPsec clients be used to connect to the SRX for remote access?

Answers

1. IKEv2 is the successor to IKEv1. IKEv1 is split into two different phases, with Phase 1 operating in Main or Aggressive mode, and Phase 2 supporting Quick mode. IKEv1 was developed over three core RFCs with several extraneous RFCs that describe different extensions and aspects of IKEv1. There are some ambiguous elements to IKEv1 that have led to different vendors implementing IKE differently and led to interoperability issues. IKEv2 is a greatly simplified protocol that operates in a request/response format, offers more flexibility and options during negotiation, and provides better details as to acceptable parameters in the event that negotiation fails.

2. IKEv1 Phase 1 is used to create a secure channel to negotiate the Phase 2 encryption keys that will be used to secure the traffic.

3. Both Main and Aggressive modes occur in Phase 1 of IPsec negotiations. The difference is that Main mode negotiates the Phase 1 security with a six-message exchange with the IKE identities encrypted, whereas Aggressive mode negotiates them in a three-message exchange with the IKE identities in clear text. IKEv2 only supports one method of negotiation and doesn’t have a different mode. It is somewhat of a hybrid between Main and Aggressive mode of IKEv1.

4. Aggressive mode is necessary when the IP address of the remote peer is dynamic and another mechanism such as dynamic DNS is not used to help identify the host.

5. The SRX supports up to four Phase 1 and four Phase 2 IPsec proposals per gateway. They are evaluated in order from first to last, until a proposal can be matched with the peer, or negotiations fail because a proposal cannot be chosen.

6. PFS stands for Perfect Forward Secrecy. This is an optional configuration option that can be used to trigger a renegotiation of Phase 1 keys after Phase 1 has been completed. This is most often performed when using Aggressive mode for Phase 1 authentication.

7. Policy-based VPNs are good for simple VPNs without any needs for NAT, advanced Level 7 features, or complex routing. Route-based VPNs are more powerful, with the ability to not only control traffic, but also interact with dynamic routing protocols, provide automatic failover, and integrate more generally into the network architecture.

8. Point-to-point VPNs map a single VPN to a single st0 interface, whereas point-to-multipoint VPNs map multiple VPNs to a single st0 interface on the hub site. Each spoke still views its connection as a point-to-point connection. All VPNs’ st0 interfaces will be in the same zone subnet when it comes to the hub site using point to multipoint.

9. A numbered st0 interface means that it has an IP address on it, whereas an unnumbered st0 interface (which is only supported for point-to-point connections) will not have an IP address on it. Typically, it is best to use numbered interfaces for better routing and NAT support when it comes to point-to-point networks, but you can use unnumbered interfaces in very simple use cases.

10. DPD stands for Dead Peer Detection. This is a standard IKE capability to detect if the peer gateway is up by sending IKE pings. It is negotiated in Phase 1. VPN monitoring is not a standard IKE component, but rather relies on sending peers from the gateway through the IPsec tunnel to determine if it is up. It is a more reliable mechanism because it allows one to take into account not only whether the peer is up, but also whether the VPN is up. VPN monitoring and DPD results can then be used by the SRX to consider the VPN up or down, and make alternative arrangements if available to send the traffic over another VPN.

11. NAT-T is a technique for encapsulating IPsec traffic in UDP traffic so that it can pass through a NAT device (most commonly used for remote clients that are behind a NAT gateway). This is required because NAT can alter fields that will then make the authentication invalid. By encapsulating the IPsec traffic in a UDP packet, the UDP packet is NATed, and then, when it arrives at the gateway, the UDP headers are stripped off and the IPsec traffic is processed as normal.

12. Preshared keys are simple to implement, with little overhead. They are best used for site-to-site VPNs where only a few VPNs are used, or for remote access VPNs when there are only a few clients. The disadvantage of preshared key VPNs is that they don’t scale easily without compromising security (by using the same key). Certificates have the ability to dynamically update a certificate’s status, along with the ability to provide a unique certificate to each client. More overhead is associated with certificate authentication because it requires a CA to be generated, also called certificate generation (revocation and expiry). Other mechanisms such as CRL and OCSP can be used to ensure the validity of a certificate.

13. Proxy IDs are negotiated in Phase 2/IKE-Auth and are meant to provide information about the type of traffic that will be carried over the VPN. In reality, proxy IDs do not enforce any real control over the actual traffic that passes over the VPN; however, they must match to establish the VPNs. Proxy IDs are a common source of issues when establishing IPsec VPNs, particularly when establishing them between different vendors, because the IKEv1 standard did not specify exactly how the proxy IDs should be derived, and therefore different vendors derive them differently. This means the proxy IDs might not match, and therefore will require tuning for proper configuration.

14. You must enable IKE under the host-inbound-traffic configuration fields before IPsec VPNs are allowed to be established on the SRX. Additionally, if you are using any stateless ACL or security policies for traffic coming from or to the junos-host zone, you need to make sure that IKE and ESP/AH are permitted, otherwise negotiations will fail.

15. There are two settings that define how the SRX should establish traffic, on-traffic and immediately. On-traffic will establish the VPN only when there is traffic to be tunneled through the SRX, while immediately will trigger the SRX to always keep the IPsec tunnel up.

16. CRLs are generated by the CA that signs them. It includes a list of all of the certificates that have been revoked or are on hold. The lists are usually updated in real time, but are downloaded at an interval so it is possible for a certificate to be revoked with an older CRL file saying that it is still valid. OCSP allows for on-demand checking of certificate status rather than checking CRLs that might have outdated information. OSCP essentially acts as a request/response protocol. SCEP has nothing to do with certificate validation but instead is used to renew certificates dynamically. If you are supporting a large IPsec infrastructure with hundreds of devices, you need an automated way to renew and reenroll certificates, and SCEP supports doing just that by reenrolling and typically getting new certificates from the CA when a certificate is going to expire.

17. DH stands for Diffie-Hellman and refers to a method to securely establish a two-way encrypted channel for exchanging the symmetric keys that will ultimately encrypt the traffic.

18. The SRX will automatically copy the DSCP bits of the original traffic to the ESP/AH header so that other devices will get the same processing by up/downstream devices. DF stands for Don’t Fragment. By default, the SRX will honor the same behavior of the packets, but you can set it to copy, clear, or set the bits to the IPsec header.

19. Yes, third-party IPsec clients can be used to provide remote access to the SRX as long as they support the same standards-based implementations that the SRX supports. It is important to note, however, that JTAC cannot assist in troubleshooting client-side issues for third-party software, only on the SRX side. Clients like Shrew and NCP have been tested in the past and shown to work well in most cases.