Juniper JN0-230 JNCIA Security Associate – IPsec VPNs Part 2

3. IPsec VPN Concepts – Part 2

Let’s continue our conversation on IPsec VPN concepts. So, in Part 1 of IPsecVPN concepts, we spoke about encryption. We understood the different encryption algorithms and authentication algorithms. We understood what hashing is and how it helps with authentication. We also understood how a phase-one tunnel is established, the different IC key exchange mechanisms, including the annual key exchange, and, using the IC protocol, how proposals are negotiated between VPN endpoints and the different versions of IC. Now let’s build upon those concepts and talk more about IPsec VPN. But before that, we’ll rewind just a little bit by beginning with IC.

So we know what IC is IC. IC is the Internet Key Exchange. IC is a more secure way of negotiating keys because it allows host to renegotiate VPNs on the fly. IC has two versions: IC version one and IC version two. The IC negotiation Version one occurs in two phases: phase one and phase two. Now Juno calls IC “auto.” IC is talking about phases one and two. Phase One is used to authenticate the VPN endpoints and create a tunnel between both sides. This tunnel acts as a management channel for further negotiations and to create a phase two tunnel. Phase Two is used to negotiate the encryption keys that will be used to secure data traversing the VPN.

Talking about negotiating encryption keys, we need to talk about the Daffier-Hellman key exchange. This protocol is very important for VPNs. It allows two parties to negotiate a shared secret over an insecure medium. Now you might be thinking, “Wait a minute, have we not already configured the preset key?” The answer is yes. Preshared keys and certificates are used as authentication mechanisms for the VPN endpoints. So both sides present the preshade key as a way to authenticate with the other device. The key exchange we are talking about here is to encrypt the data.

Both sides need a key to encrypt the data. Now, the challenge here is that both the devices, or both the VPN endpoints, are connected over an insecure medium, the Internet. How do you exchange a secret key for encryption without it being read over the Internet? That’s what Diffiheldman helps you with. It allows two parties, or the VPN endpoints, to generate a shared secret key for encryption purposes over an insecure medium. It uses public and private keys and mathematical computations to generate a shared secret. The interesting part is that the shared secret is never exchanged on the medium. So without ever exchanging the secret, both VPN endpoints are able to generate the exact same secret. How interesting is that? Now, we’re not going to talk about the working mechanisms of Diffi Hellman Key Exchange, but if you’re interested, I highly encourage you to read some documentation about this. You will find it very interesting. As network administrators, we only need to know the purpose of Diffihelman and how to configure it on the device.

The Diffi Hellman Key Exchange mechanism supports the use of different key sizes, which are referred to as “groups” on the device. So the larger the key size, the more secure it is going to be. All right. Now let’s talk a little bit more about IC phase one. Now remember, IC phases one and two are properties of IC version one. So really, we’re talking about IC version one. Phase one. When negotiating IKE phase one tunnel, the VPN endpoints can use one of the two supported modes, main mode or aggressive mode. The important thing is that the same mode must be configured on both sides of the tunnel. So when negotiating a phase-one tunnel, the VPN endpoints have a choice. They can use main mode or they can use aggressive mode. Let’s talk about the differences. We’re going to start off with IC Phase 1, main mode. So here we have two devices, SRX One and SRX Two, which act as VPN endpoints. And we’re going to talk about the exchange of messages in main mode. It is important to note here that the VPN endpoints do not have to be SRX devices.

You could have SRX on one side and another vendor’s equipment on the other side. And main mode will continue to function normally. So the first message is sent by the VPN initiator. Let’s say SRX-1 is the VPN initiator. The first message contains proposals for encryption and authentication algorithms. The responder, in this case SRX Two, is going to look at the proposals and choose one of the proposal. So the response, which is message number two, is going to contain the chosen proposal.

The third message is again from the initiator. It initiates the Diffie-Hellman key exchange process and presents its public key. Remember that the purpose of Diffi Hellman is to generate a shared secret over an insecure medium, and that shared secret key will be used for encryption purposes. So then the responder responds back, which is message number four. It responds with its public key. And once this is completed, an encrypted channel is established. So at the end of step four, a secure channel has been established. Message number five is from the initiator. It presents its IC identity to authenticate itself. And the responder responds back on message number six. It responds with its IC identity, and phase one is considered complete. The important thing to note here is that we have exchanged six messages in total.

And messages five and six are important. They are used to present IC identities. But notice it happens after step number four, where a secure channel or an encrypted channel has been established, meaning the IC identity is never presented in clear text. Now let’s talk about aggressive mode. Aggressive Mode contains only three messages or three exchanges. The first message is from SRX1 or from the initiator. It contains proposals for encryption and authentication algorithms. It also initiates the Diffie-Hellman key exchange and sends its IC identity.

Now, straight away, you can see a difference. Here. The IC identity is presented in clear text. On step number one, there is no secure channel, so the ICC identity is being sent in clear text. Message number two is from the responder. It chooses a proposal. So it lets the SRX One know what the chosen proposal is. It presents its IC identity, and the initiator, in this case, SRX One, has been authenticated. Message number three is from the initiator. The initiator authenticates. The responder confirms the exchange, and phase one is complete.

As you can see, there are two major differences. The first is the number of messages. Main mode has six messages, while aggressive mode has three. And the second important difference is that main mode sends the identity on a secure channel, meaning it’s never sent in clear text like in aggressive mode. So now that we know the modes, the question is, which one should we be using? Main mode or aggressive mode? So, Main Mode is more secure because the ICidentities are encrypted and not transmitted in clear text.

Main mode is used when both sides have a fixed IP address. Aggressive Mode is used when the client’s IP address is dynamic, like a workstation connecting to a VPN gateway. All right, so that’s about IC version one, phase one. Now let’s talk about IC version one. Phase two. During phase two, IPsec Security Associations, or IPsec essays, are created for encrypting and authenticating data. So a phase-two tunnel is commonly called the IPsec Security Association. So when you see IPsec Security Association, just remember we’re talking about a phase-two tunnel. Let’s put all of these concepts into an example. So here we have SRX One and SRX Two. They’re connected to the Internet, and they want to establish a VPN tunnel. The first step is to create a phase one tunnel. And the way to do that is to exchange proposals from both sides.

SRX One will send its proposal, and SRX Two will send its proposal. They will agree on a common proposal. They will then authenticate each other using preshade keys or certificates. And when that is completed, they will establish the first phase of the tunnel. The phase one tunnel is not used to send encrypted packets, but rather as a management channel to further negotiate for phase two to create the phase two tunnel, which both endpoints will do. So SRX One will send its phase-two proposals, and SRX Two will send its phase-two proposals.

They will come to a common agreement, and that will lead to a phase two tunnel. That is, the tunnel that is going to be used for encrypting and authenticating the VPN data. So, talking about phase-two endpoints exchange proposals to determine which protocols and algorithms to use for the Security Association, Now, we are saying that proposals are exchanged for phase two, but what is really contained within a proposal? So, a phase-two proposal contains information about which security protocol should be used, and there are two choices. You can use a protocol called ESP (Encapsulating Security Payload). Ah, which is the authentication header?

The proposal will also contain information about which encryption and authentication algorithm to use. And optionally, you may also specify a Daffy Hellman group. Now I know what you’re thinking. You’re saying, “Well, did we not do this earlier on Phase One?” Did we not already specify diff? Hellman. The answer is yes. However, we have the option of specifying another diffihelman group for phase two. And this is used to renegotiate keys for Phase 2.

These keys are independent and unrelated to phase-one keys. It is simply a mechanism to provide additional security for phase two. Now, when you’re configuring the VPN on the device and when you’re configuring phase two information, you will not see the word “DeFi Hellman.” Instead, it is called “perfect forward secrecy.” PFS stands for “perfect forward secrecy.” So when you see “perfect forward secrecy” when configuring phase two of the VPN, just remember we are talking about a Daffy Hellman key exchange specifically for phase two. For IC. Version one. In phase one, we understood that there are two modes: main mode and aggressive mode. But phase two only operates in a single mode, which is called “quick mode,” and involves the exchange of three messages.

Now let’s talk about these security protocols. What is an “encapsulating security payload” and what is an “authentication header”? We’ll begin with ESP, or encapsulating security payload. When this protocol is configured for phase two, it performs encryption and authentication on VPN traffic, ensuring confidentiality and integrity. With ESP. You may choose to encrypt and authenticate or encrypt only. or simply authenticate. because it performs both encryption and authentication. You as an administrator can decide which one you want to apply: encryption only, authentication only, or both encryption and authentication. ESP is more commonly used than Ah or the authentication header.

Let’s talk more about the authentication header. The authentication header only authenticates the content and the origin of the packet, ensuring the integrity of the contents and the source. important to keep in mind that encryption is not performed. The main distinction between ESP and Ahis is that ESP can perform both encryption and authentication, whereas the Authentication header can only perform authentication. So far, we’ve learned about IC version one. Let’s now talk about IC version two. The purpose of IC version two remains the same as IC version one, which is to authenticate the peers and establish a secure channel for communication called security associations. IC version two, unlike IC version one, has no defined phases.

So in IC version 1, we had phases one and two. But IC version two has no defined phases. It uses a total of four messages, of which the first two are enough to create a child’s essay. In the terminology of IC version 1, we used to say “phase 2 tunnel.” IC version two calls it a “child essay” or a “child security association.” Now let’s talk about the four messages. The first message is “IC essay init.” This message is used to negotiate protocols and algorithms. The second message is IC authentication. This message is used to authenticate the peers, and by the end of this message, the IPsec tunnel is established. So messages three and four are optional. Message number three is “Create Child Essay,” and this message is used to create additional essays for the peers or additional security associations for the peers. The fourth message is informational. With this message, the peers perform additional functions, such as a liveliness check and the deletion of essays. So really, IC version 2 requires only two messages to establish an IPsec tunnel. Now let’s talk specifically about the differences between IC version one and IC version two.

For phase one, we have main mode and aggressive mode with Ike version 1. But for IC version 2, there’s only one exchange process defined, which contains four messages. With IC version 1, the total number of messages will depend on the mode that you select. Main mode has six messages, and aggressive mode has three messages. With IC version 2, we only have four messages. IC version one creates a phase one tunnel and a phase two tunnel, or a phase one security association and a phase two security association.

But IC version two creates what are known as “child security associations.” With IC version 1, the supported authentication methods include preshared keys, digital signatures, and public key encryption. With IC version 2, only preshade keys and digital signatures are supported for authentication. With IC version 1, both peers must agree on the same authentication method. With IC version 2, the peers may use different authentication methods. Debt peer detection and keep alive checks for essays can be defined in IC version 1, but only as extensions. With IC version 2, dead peer detection and keep-alive checks are natively supported. With IC version 1, remote access VPN isn’t natively supported. With IC version 2, remote access VPN is supported by default. These are not the only differences between IC version one and IC version two. There are a few more as well, but these are the most important differences to keep in mind. Let’s move on.

And now let’s talk about IPsec VPN modes. I know what you’re thinking. There are so many modes that we discussed IC versions one and two. Phase one, phase two, main mode, aggressive mode And we now have another set of VPN modes. The mode we are going to talk about now determines how a packet is going to be encapsulated before it is sent over the VPN connection. So there are two VPN modes. The first one is tunnel mode, and the second is transport mode. Before we talk about the conceptual differences between tunnel mode and transport mode, let’s see how a packet is affected by these two modes. So on the left side, we’ll see the packet in tunnel mode, and on the right side, we’ll see the packet in transport mode. So this is how a packet looks before it gets encrypted. We have the original data, or the payload. On top of that, we have TCP headers, and then we have IP headers. Now, if you’re wondering how these get added on top of the payload, think about the OSI model. So layers five to seven of the OSI model are where you have the payload, or the data. As the data travels down towards the transport mode, you have the TCP header applied on top of that. So the TCP header contains information like which protocol needs to be used (TCP or UDP) and what port numbers need to be used. As the packet further travels downward, it reaches the network layer, where IP address information and IP protocol information are added. Which is why we have the IP Header.So you have the original data or the payload.

On top of that, we have the TCP header, and then we have the original IP header. Now let’s see what happens to the packet in tunnel mode and transport mode. Remember, we have two security protocols that can be used as part of phase two. We can use an encapsulating security payload or we can use an authentication header. We’re going to talk about an IPV4 packet. After applying the Ah protocol or the authentication header protocol, In tunnel mode, we understood that the purpose of the authentication header was to authenticate the packet. It does not perform encryption. So with Ah applied in tunnel mode, the packet will look like this:

You have the payload TCP header and the original IP header. On top of that, Ah will add its own header to authenticate the packet. And now, since the original IP header is hidden, a new IP header is added. So this is how the Authentication Header, or Ah, authenticates the packet in tunnel mode. Now let’s see the same thing in Transport Mode. In transport mode, the Authentication Header is added between the original IP Header and the TCPHeader, and that’s how the packet is authenticated. So the key difference between tunnel mode and transport mode is that in tunnel mode, a new IP header is added because the original IP header is hidden. But in transport mode, the original IP header is retained. Now, let’s talk about ESPor’s encapsulating security payload. The purpose of ESP is to encrypt and authenticate. So here we have the original packet data, the TCP header, and the original IP header. On top of that, an ESP header, an ESP trailer, and ESP authentication are also added.

ESP Trailer provides information such as padding, padding length, and the next header information, while ESP Authentication contains information such as integrity, check value, and a message authentication code for verifying the sender’s identity and the message’s integrity. Now, as you can see, the original IP header is now hidden with the ESP header. So a new IP header is added, and this way the packet is encrypted and authenticated. Now, let’s talk about ESP in transport mode. In transport mode, the ESP header is added between the original IP header and the TCP header, and you also have the ESP trailer and ESP authentication.

And that’s how the packet is encrypted and authenticated by ESP. So the key difference between tunnel mode and transport mode, regardless of the security protocol, which is AET or ESP, is that in tunnel mode, a new IP header is added, while in transport mode, the original IP header is retained. So in tunnel mode, the original IP packet and its headers are encapsulated, and a new IP header is added. The original IP packet can be encrypted, authenticated, or both. An important thing about tunnel mode is that all traffic appears to be coming from the two VPN gateways.

Because this process is applied by the VPN gateway, the new IP header will have the information, or the IP information, of the VPN gateway from where it is exiting. So the traffic will appear as if it is coming from the two VPN gateways when at least one of the endpoints of the tunnel is a gateway device, such as an SRX device or a router, and tunnel mode must be used. Now, here’s the important thing. Juno’s devices always operate in tunnel mode for IPsec tunnels. So when we get to configuration, we will be configuring VPN in tunnel mode. In transport mode, the data payload is authenticated, encrypted, or both, but the original IP header is untouched. The potential downside to this is that it can cause IP address information to be exposed. This has a lower overhead compared to tunnel mode because we are not adding a new IP header. All right, so that’s about the IPsec VPN concepts. We’ve discussed a lot of concepts, a lot of modes, and a lot of protocols. If this is the first time you’re learning about IPsec VPNs, my recommendation is to go over these lectures one more time, both Lecture One and Lecture Two. This will not only help you reinforce the concepts, but it will also help you understand the configuration that we’re going to do in the upcoming lecture. You will be able to correlate why we are applying a specific configuration or why we are configuring a specific mode. Okay, so that’s all the IPsec VPN concepts that we had to discuss. There’s one more thing that we need to discuss, which will come up in the next lecture, and then we’ll get to the configuration of VPNs.

4. Policy-based vs Route-based VPN

Policy-based VPNs versus route-based VPNs Before we begin configuring IPsec VPNs, there’s one more thing we need to talk about: the difference between policy-based and route-based VPNs. We’ve already spoken about so many differences. We’ve spoken about the differences between encryption and authentication algorithms. Differences between IC version one and IC version two Main mode versus aggressive mode; ESP versus Ah; tunnel mode versus transport mode and now we have one more difference.

All the differences that we’ve spoken about until this point were technical differences. But policy-based and route-based VPNs are basically configuration styles. So we as network administrators can configure IPsec VPNs as policy-based VPNs or route-based VPNs. And the real distinction is how you define interesting traffic or traffic that needs to be encrypted. That is the fundamental difference between policy-based and route-based VPNs. They use different configuration styles to define what traffic needs to be encrypted. So the SRX device supports two types or styles of VPN configuration. The first one is a policy-based VPN, and the second one is a route-based VPN. The VPN type determines what traffic will be encrypted. Regardless of the type, IPsec functionality largely remains the same.

Let’s talk about policy-based VPNs. With policy-based VPNs, you’ll configure security policies to define what traffic should be tunneled. So any traffic that matches the security policy that you configure will be encrypted and sent over the VPN tunnel. This configuration style allows you to configure VPN tunnelling on a per-policy basis because every policy that has a tunnelling action configured will be encrypting the traffic. This is commonly used for simple site-to-site VPNs and remote access VPNs.

Now let’s talk about route based VPN.Route-based VPNs use a virtual tunnel interface, unlike the security policies used by policy-based VPNs. And all traffic routed through the tunnel interface will be sent over the VPN tunnel. So you’ll start by configuring a virtual tunnel interface, and then you will configure routing. So all traffic that needs to be encrypted is sent over the virtual tunnel interface. The virtual interface is known as the secure tunnel interface, or St Zero. Here, we do not configure security policies that use the tunnel action. So largely, there are different styles of configuring VPNs. With policy-based VPNs, you define security policies that permit and tunnel traffic. And with route-based VPNs, you will define a virtual tunnel interface and then route interesting traffic or traffic that needs to be encrypted using the virtual tunnel interface. With this information, we are now ready to configure IPsec site-to-site VPNs.