Juniper JN0-230 JNCIA Security Associate – IPsec VPNs

1. Introduction to VPNs

It’s now time for the most interesting topic of the course: virtual private networks, or VPNs. I’m sure you’ve heard about this before. So in this section, we’ll understand what our VPNs are. Why did they even exist in the first place? What are the different types of VPNs, and how can we configure one? So, to understand why we have VPNs in the first place, we need to go back in time a few years back in time. Assume an organisations has two offices, or offices in two locations. They have an office in London, and they have an office in Paris. That means they’ve got devices, servers, workstations, et cetera, on both sites. And the sites need to access each other. meaning the users inside A will need to access servers inside B, and users inside B will need to access servers inside A.

How do we make this accessible over an insecure medium? The Internet. That’s why large organisations in the past used to have private lines between their offices. And they used to be called “leased lines,” lines dedicated for their own private use only. Those lines were not drawn by the companies themselves. They would just lease them from telecom companies. But they would lease the entire line. meaning that the entire connection, or the entire pipe, is dedicated for their use only. So it provides them with high bandwidth and also provides them with security. But the problem with these lines is that they are very expensive. So then came the new technology called VPNs, or “virtual private networks,” where we are using the Internet or a shared medium to establish a private connection. a virtual private connection, meaning it’s not a dedicated connection between two parties. It’s a private connection. But it’s also virtual. And hence we call it a “virtual private network.” It is a mechanism to establish a secure communication channel between two sites or between two parties. In this section, we are going to specifically talk about IPsec VPNs. So we need to understand: what is IPsec?

IPsec is a set of standards and protocols used to authenticate and encrypt packets as part of a VPN connection. So, simply put, it is just a collection of standards and protocols that we’ll use as part of the VPN implementation. It provides a secure communication channel between two networks that use the IP protocol. So it provides a secure channel for the IP protocol. Hence, we call it IPsec. Now, IPsec aims to provide four main functions. The first one is authentication. It provides for peer authentication. A VPN connection is established between two peers, and the peers need to know that they are talking to the right entity or the correct entity. So IPsec provides a mechanism to authenticate the peers. Each peer can authenticate the other one. And it also provides for data origin authentication, meaning the peers can verify that the data is actually coming from the correct peer. IPsec also provides a mechanism for integrity, meaning it provides a mechanism to ensure that data has not been modified or tampered with. The third function, which is again a very important function, is confidentiality. It ensures that data is not available to unauthorised parties. And the way this is done is by encrypting the packets. If the data lands in the hands of any unauthorised person, all they are going to see is encrypted data.

And since they don’t have the encryption key, they cannot reverse the encryption and read the original data. And the last important function provided by IPsec is replay protection. This is done using packet sequence numbers to ensure that packets are not intercepted and modified and that new packets are not injected into the stream. Now let’s talk about the implementation styles for IPsec VPNs. Primarily, there are two styles. The first one is to secure data between two or more sites, and this is commonly called a site-to-site VPN. And the second is to secure data between a remote user and a site, which is known as a remote access VPN. Apart from IPsec VPNs, there are other flavours of VPN as well. For example, we have SSL VPN, another type of VPN called L2TP or Layer 2 Tunneling Protocol, OpenVPN, et cetera. So there are different flavours of VPNs, but we’re specifically going to talk about IPsec VPNs. And specifically in this course at the JNCIA level, we are only going to talk about site-to-site VPN. So let’s understand the topology of these two VPN styles. The first one is a site-to-site VPN. As you can see here, we have two sites, site A and site B, and both sites have a perimeter device, which can be a router or a firewall. And a site-to-site VPN is established between these two perimeter devices.

Now, it’s important to understand that the workstations or host machines at these sites may not even be aware that there is a site-to-site VPN. They may not even be aware that the traffic they are sending out from their computers is actually going over a site-to-site VPN. So this implementation style is transparent to the end user. They may not be aware that their traffic is actually being routed over a site-to-site VPN. Another important thing about this VPN is that the endpoints do not need to have any software on their devices to establish the VPN because the VPN is established between their perimeter devices. So the endpoints do not need to have any client software installed on their machines. The other style of VPN is a remote access VPN. In this case, the endpoints will have VPN software installed on their computers. They will use the VPN software to connect to the VPN. Gateway employees working remotely, mostly from home, commonly used remote access VPNs to access servers sitting in the office. So primarily, there are two styles of IPsec VPN implementations: site-to-site VPN and remote access VPN. In the upcoming lectures, we’ll dive into the technologies and protocols used to establish site-to-site IPsec VPNs.

2. IPsec VPN Concepts – Part 1

IPsec VPN concepts In this lecture, we’ll understand the protocols and processes involved in establishing an IPsec VPN tunnel. Now, there are a lot of concepts that we need to discuss, so we’ll break this down into two lectures, maybe even three lectures. But I promise you, you will enjoy it. Now, let’s get started. So we understood that one of the key functions of IPsec is to provide encryption. IPsec encryption provides confidentiality. This means that data can only be read by the intended recipient. Encryption causes data to be obfuscated, or, in other words, it makes it illegible. This ensures that data can only be read by the sender and the intended recipient to perform encryption. IPsec supports some encryption algorithms. The first one is the DSS, or data encryption standard. The second one is triple-DES, or triple-data encryption. Standard.

And the third one is the Advanced Encryption Standard, or AES. We’ll talk about these encryption algorithms at a high level, meaning what kind of output they generate. But we’re not going to talk about how these algorithms work at a computational level. As network administrators, we only need to know which algorithm supports our use case. We do not need to understand at a computational level how these algorithms work. If you are interested in understanding that, there’s a lot of documentation available online. But as network engineers, we do not need to go to that level. So let’s talk about these algorithms at a high level, starting with Des, or Data Encryption Standard, which uses a 64-bit key. So every encryption algorithm requires a key to encrypt your data. Des uses a key that is 64 bits long, of which 56 bits are used for encryption and eight bits are used for error detection. This algorithm is not recommended because it is susceptible to brute-force attacks. Next, we have triple zeros. And just like the name suggests, it uses 356-bit keys for encryption, resulting in a total key size of 168 bits. This is a suggested algorithm for dealing with death.

Third, we have the Advanced Encryption Standard, or AES. This is available in varying key sizes. 128 bits, 192 bits, or 256 bits Longer key chains are better from a security standpoint. The second key function of IPsec is authentication. Authentication ensures that data is not altered in transit. This means if one of the VPN peers is sending some data, that data should not be altered in transit. It should arrive in the same form at the other end of the VPN tunnel. Authentication also ensures that data is coming from its original source, and this is done using a hashing algorithm. So what is hashing? Well, hashing is a technique to generate what we call as a hash value from a given input. The hash value is an output of fixed size. The interesting thing about hashing is that it’s a one-wave function. That is, if you have the hash value for a particular piece of data, you cannot reverse engineer it to obtain the original input. So this is different from encryption. With encryption, if you have the encrypted data and the key, you can decrypt it and get the original data. But hashing is one way. If you have the hash value, you cannot reverse it and get the original data. Let’s look at some examples of what hash values look like. I’m using a string here. The string is Juniper, and I’ve applied the hashing algorithm, Sha 1, resulting in this hash value. I’ve also done the same thing with another algorithm and the same string.

Again, juniper. This algorithm uses shad 256. And this is my hash value. And I’ve also tried this on another algorithm, MD Five. And this is my hash value. As you can see, with the change in algorithms, the output, or hash value, is different. If you had this hash value, you couldn’t reverse it to get my original string, which is juniper. Let’s look at an example of how encryption and authentication can be used to transfer data securely. Let’s say we have two people, John and Mary. John wants to send a piece of string or a piece of text to Mary, and he wants to ensure that no one in the middle is able to read the data. So John is trying to send a communication to Mary, and the plain text that he’s trying to send is, let’s say, juniper. Now, before he sends the string, he’s going to encrypt it. And for encryption, he needs a key. Now, before sending this communication, John and Mary have agreed on a common encryption key. So John encrypts his data with the agreed-upon key and sends it to Mary. Now, Mary already has the key. She will apply the key, decrypt the data, and get the original string back. Juniper but here’s what Mary thinks. Mary wants to know if John really sent Juniper. Did he send something else, or did he really send Juniper? That’s where the authentication piece comes in. Now, after sending the encrypted data, John also computes a hash value for that string. He also sends this hash value to Mary.

Now, Mary has already decrypted the data and found that the string is juniper. She applies the same authentication algorithm to that string, gets a hash value, and compares that hash value with the hash value sent by John. If the hash values match, she knows that John actually sent the text. Juniper, as demonstrated by this example, a combination of encryption and authentication ensures that data cannot be read by unauthorised parties while preserving data integrity. So let’s talk about the authentication algorithm supported by IPsec. The first one is MD 5. This produces a hash value of 128 bits. Then we have sha one. This produces a hash value of 160 bits. And then we have chapter two. This produces hashes of size two, five6384, or five one two bits. So let’s put all of these concepts into an example and understand how a VPN tunnel is established. Assume we have two devices: one on the left with the IP address 111 and one on the right with the IP address 111. And on the right side, we have a device whose IP address is 2222. Now, these devices want to establish a VPN connection over the Internet, meaning they want to establish a secure communication channel. One of the first things they’ll need to do is verify each other’s identities.

We see something like this in quite a few movies. Two people agree to make a secret deal, and they decide to meet at a common place. When the time comes, the two people meet at the commonplace, but they want to ensure that they are actually meeting with the right person. So to do that, before meeting at the commonplace, they agree on a secret code word. So when they meet at the common place, they both present the code word they agreed upon, and that way they are able to authenticate each other. Something similar happens with these devices as well. They both agree on a common way or a common mechanism for authenticating each other. Now, that can be a shared key. So when these devices begin the communication, they both present their preshared key, and that way they can authenticate and make sure that they are establishing a VPN tunnel with the right device. Or the devices can also be configured to present their certificates as a way to authenticate each other. So the first thing that must happen is that both devices need to authenticate each other. Then they need to agree on aset of common protocols and parameters. For example, if the device on the left says I want to use MD5 as the hashing algorithm and the device on the right says I can’t use that and I’m only going to use Sha1, that’s not going to work. So both devices need to agree on a common set of protocols and parameters.

When both devices agree on a common set of parameters and when they have authenticated each other, they establish the first tunnel, which is called the “phase one tunnel” or, in other words, a security association. Now, this tunnel that they have created, the phase one tunnel, is not the actual VPN tunnel that will be used to send data. This is used for management purposes. Now, both devices will communicate over the secure channel or phase one tunnel and exchange further parameters to establish a second tunnel, which is what will be used to send data. So the phase-one tunnel is just a mechanism for both devices to securely talk to each other. Think of it as a tunnel that’s used for management purposes but not actually for sending data. Another important thing we need to understand is the key exchange process. When two devices want to establish a secure channel, they will need to exchange keys because keys are what will be used for encrypting data. So there are a couple of ways this can be done. We can perform manual key exchange or we can use a protocol called IC, or Internet Key Exchange.

Let’s talk about manual key exchange. Just like the name suggests, it requires no negotiation from participating hosts because the keys are going to be manually exchanged. The algorithms and keys to be used are statically defined by the administrators. On both devices. It is very important that the configured values match at both ends; otherwise, the tunnel will not be established. This method works well for small networks, but for large networks, it’s a lot of work to do. For large networks, the recommended way to exchange keys is to use the IC Protocol, or the Internet Key Exchange Protocol. IC is a more secure way of negotiating keys because it allows hosts to renegotiate VPNs on the fly. So even when the devices have established a VPN, if they need to renegotiate the keys, they can do it on the fly. If they choose to use the ICC Protocol with manual exchange, you would have to do it manually. So here’s how it works: When two devices want to establish a VPN tunnel, each one is going to present a set of parameters that it supports. For example, the device on the left says, Well, I support two encryption algorithms, triple-S and AES. I support Shafer authentication. I am a member of Diffi Hellman groups 5 and 7. Now, we haven’t spoken about Diffi Hellman at this point, but we are going to talk about it as the next topic.

For the time being, just remember that Diffi Hellman is a method for both users or both devices to generate a common key for encryption. So the device on the left says, “Well, I support Diffi Hellman Groups Five and Seven.” And for authenticating the identity, I support the use of preshared keys. Now, the device on the right says, “Well, this is what I support.” I support AES for encryption and Shaw for authentication. Daffier Hellman, Seventh Group. And for device authentication, I support preselected keys or certificates. The key to establishing a tunnel is that both parties must agree on a common set of parameters. So they both decide—well, let’s agree on these parameters. For encryption. We’ll use AES. For authentication. We’ll use Shad. We’ll use the Daffier-Hellman group seven. And for device authentication, we’ll use pre-shared keys.

So, as we can see, with IC or Internet Key Exchange, both devices, or both VPs and peers, will come to an agreement in terms of what parameters to use to establish a VPN tunnel. Now, the ICC Protocol has two versions: IC version one and IC version two. Phase one and phase two are the two stages of IC version one negotiation. And the tunnels that are created as a result of these phases are called phase one tunnel and phase two tunnel, respectively. IC is referred to by Don’t knows as “auto Iscor,” or “auto Internet Key Exchange.” Phase one is used to authenticate the VPN endpoints and create a tunnel between both sides. Keep in mind that the phase one tunnel is not used to send encrypted packets. Phase one functions as a management channel for both devices to securely talk to each other and work on establishing the phase-two tunnel. Phase two is used to negotiate the encryption keys that will be used to secure the data traversing the VPN. So we have two tunnels. Phase one is the management tunnel, and phase two is the actual tunnel that will be used to send data over the VPN. Okay, so that’s all the concepts that we’re going to talk about in Part One of IPsec VPN Concepts.