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

5. Configure Policy-based VPN

After we’ve gone over all of the concepts, it’s time to dive into some configuration. In this lecture, we’re going to understand how to configure a policy-based IPsec VPN. First, we’ll talk about the topology that we’re going to implement. Then we’ll talk about the configuration steps at a high level. Then we’ll jump into the device and perform the configuration. And finally, we’ll perform some verification. This lecture is going to be a bit longer than the other lectures because we have a lot of configuration to do. So if required, grab a cup of coffee to keep you going through the lecture. If you’re ready, let’s get started. So here’s the configuration scenario:

We have two SRX devices. The first one is called SRX A, and the second one is called SRX B. Both of these devices are connected using their fast Ethernet zero slash zero slash zero interface. Now I must tell you here that to establish a VPN connection, the devices at both ends of the connection do not need to be the same type, meaning they do not need to be SRX devices. You could have SRX on one side and any other device on the other side; it could be a device from any other vendor, but for this configuration, we’re going to have Srxes on both sides. The IP addresses of these interfaces are eleven one for Srxa and eleven one two for Srxb. Also, we have two hosts, one connected to each firewall. The host on the left is 109 216-8110, and the host on the right is 10 1 10. Now, the topology in this case has the SRX devices directly connected to each other. But it doesn’t have to be this way. In fact, you will not find this configuration often.

Most of the time, the VPN endpoints are separated from each other by many intermediate devices because they are connected over the Internet. But right now, since we are doing this in a lab environment, we have a direct connection between both devices, regardless of the connection type (direct connection or otherwise), and the configuration remains absolutely the same. We need to configure a set of parameters on both devices. And if the parameters match and if they have been correctly configured, we should see the VPN tunnel come up, having understood the topology. Now let’s talk about the configuration steps at a high level. So the first step is to configure an ICC proposal. This is done under the Edit Security IC stanza.

And here we’re going to define five things. First, we’re going to define the authentication method, which can be a presaged key or a certificate. Then we’ll define the authentication algorithm or hashing algorithm that we talked about. Then we’ll define the encryption algorithm. Then we’ll configure the DiffHellman group. We understood the purpose of Daffy Hellman. It helps the devices generate a shared secret key over an insecure medium, and we’ll also configure the lifetime encryption. Step number two is to configure the IC policy. This is also under Edit security. Under IC policy, we’ll configure the mode, which can be main or aggressive.

We’ll then configure the pre-shared key, and we’ll then configure the IC proposals to use. That is, we will specify which of the proposals configured in Step 1 must be used. Or, in other words, we’ll call the proposal configured on step number one. Moving on. On step number three, we need to configure an IC gateway. This is also done under Edit security. Here we’ll configure which IC policy to use. This was done on step number two. We’ll then specify the remote gateway address. And then we’ll specify the external interface, or the exiting interface, of the VPN traffic. That’s for phase one. We’ll then proceed to phase two configuration.

We’ll first configure an IPsec proposal. This is done in the Edit Security. IPsec section. The security protocol, which can be ESP encapsulating security payload or Ah authentication header, will be defined here. We’ll also configure the authentication algorithm because both ESP and Ah can perform authentication. And we’ll perform an encryption algorithm if we choose to use ESP because ESP can do both encryption and authentication. But authentication headers can only do authentication. So if we choose to use ESP, we’ll configure both authentication and encryption algorithms. If we choose to use AET, we’ll only configure the authentication algorithm. Moving on. We’ll then configure an IPsec policy. This is under Edit Security IPsec, and here we have the option to configure perfect forward secrecy. Alternatively, we can define one more diffi- hellman configuration. This will generate a new set of keys for phase two. And then we’ll call the IPsec proposal what we’ve configured in step number four. Then we’ll configure an IPsec VPN.

This can also be found under Edit Security.IPsec. Here we’ll configure the gateway information and the IPsec policy to use, which were configured on step number five. Finally, we’ll configure security policies. This is under Edit Security Policies, and we’ll configure one policy per direction of flow. Now these steps need to be performed on both sides, meaning we need to configure this on SRX, A, and SrxB. I hope you’re ready. Let’s get to the terminal and begin the configuration. All right, I’m here at my terminal window, and I’m currently logged into the host that’s connected to Srxa. I’m going to first try and ping the host that is connected to Srxb, which is 10 1 10.

And as you can see, I’m getting no responses. So there is no communication right now between the host that is connected to Srxa and the host that is connected to Srxb. Once the VPN connection has been established, the devices should be able to ping each other. Now let’s get to the SRX and begin the configuration. All right, I’m here at the terminal of Srxa, and I’m in configuration mode. Now, before we begin the configuration of the VPN tunnel, one thing we need to make sure of is that IC traffic is allowed as host inbound traffic in the zone where the VPN terminates. On my SRX firewall, the VPN is going to terminate in the untrusted zone, the zone that contains the interface Fe. We need to make sure that IC is allowed to host inbound traffic.

And the way to do that is to define that under the zone. So if I go to edit security zones, Untrust, and do a show here, you can see that that’s the interface where the VPN will terminate. So untrustworthy is the zone on which we need to configure IC to host inbound traffic. And you can see that I’ve allowed everything. Now, on a production device, you may not want to do this. So you could do “set host inbound traffic system services” and you’ll need to allow the traffic; that is the traffic that needs to be allowed for the VPN connection to be established.

But for the time being, I’ve set this to all. Okay, now let’s go to the top of the configuration mode and begin the configuration. So we’ll go ahead and edit security IC first. And as we discussed earlier, the first step is to define a proposal. So we’ll say Insert a question mark here. Proposal Question Mark and we need to give it a name. Let’s call this IC Proposal 1. IC proposal. One question mark And here we have the parameters that we can define. Let’s start by setting the authentication method. So, for authentication methods, we can define presched keys or RSA DSA signatures, but right now we’re going to use presched keys. Next, we’ll define the authentication algorithm. Set the proposal, proposal name, authentication, algorithm, and question mark accordingly. Here, we have four options. Now for this configuration, I’m using a slightly older version of the SRX operating system. If you’re using the latest versions of JunoOS, you may see more algorithms supported. The steps will remain the same regardless of the Juno operating system. So let’s configure the authentication algorithm as Sha 1. Next, we’ll define the encryption algorithm. So Set the proposal’s name, and the keyword we are looking for is here. Encryption algorithm. Question mark. Let’s use AES 128.CBC. CBC stands for “Cipher Block Chaining” and defines a specific method for encrypting traffic.

As network administrators, we do not need to know the working mechanisms of encryption algorithms, but if you are interested, there’s a lot of good documentation available on the Internet. So right now we’ll set this to AES 128 CBC, and then we need to configure the Diffie-Hellman algorithm. So Set Proposal proposal Name inquiry Mark The keyword is “DH group question.” Markand, let’s set this to group two. The last thing we are going to configure here is the lifetime. Set the proposal’s name and lifetime. In seconds, we’ll configure that to the highest possible value, which is 86,400 seconds. Okay, let’s do a show. So we’ve configured all the required parameters we’ll need toensure that we configure the same parameters on the otherside of the VPN, which is on Srxp. The SRX device supports multiple proposals. So like we created proposal one, you could create multiple proposals, and the purpose of doing that is that from this device, from Srxa, you may have a requirement to create multiple tunnels to multiple VPN endpoints. And different endpoints may have different security requirements based on their IT policies. So you may have to have different proposals when you’re connecting to different devices. So you can create multiple proposals. Right now in this case, since both the devices are in our control, we’ll just configure one proposal exactly matching on both the devices, and that should be enough to bring up the tunnel.

Okay, so the proposal is ready. Now we need to create an IC policy. So we’ll use the keyword “policy.” Please keep in mind that we are still under Edit Security IC. As a result, we have a policy question mark. We’ll need to give it a name. Let’s call this IC policy. One question mark First, we’ll set the mode, so we know that you can have either main mode or aggressive mode. We’ll use the main mode because with the main mode The IC identities are not sent in clear text. Press Enter. The proposal must then be named. So Set. And the keyword here is proposals. Proposals. We first need to set the policy name. So let’s do it again. Set policy. Policy-name proposals And we must refer to the proposal that we defined earlier. If you wanted, you could call this one a multiple proposal. And finally, we’re going to set the preset key. So establish policy; it policy one question mark. And we’ll activate the Preshad key. The Preshad Key is juniper.

The key must match on both the VPN endpoints. Press Enter. That command is not accepted. I realised that I missed a keyword there, the question mark. The keyword was key text. And then we need to provide the Preshad key. So that’s working fine. Now the last step is to configure the gateway. As a result, we are still under Edit security IC. We’re going to configure the gateway. So put in a question mark. The initial question mark We need to give the gateway a name. We’re going to configure properties for the remote gateway. As a result, we’ll refer to this as Srxb, question mark. And we need to invoke the IC policy. As a result, IC policy is a question mark. We only have one policy, so we’ll provide that, then we’ll provide the gateway address. So set the gateway to srxb. The keyword we are looking for is address and the address of the remote end, which is eleven, one, one, two.

And then we need to configure the external interface. So set the gateway to srxb. The external interface that we must use is inadequate. So we’ve configured a proposal, we’ve configured a policy, and we’ve configured the gateway information. With that, phase one configuration is complete. Let’s now configure phase two, and that is performed under Edit Security IPsec. So make a note that we’ve changed the configuration stanza. We are currently under editing security. IPsec is the first thing we’re going to configure is a proposal. So we’ll say Set the question mark, and we’ll define a proposal. So set the question mark on the proposal. We need to provide a proposal name. This one will be known as the “IPsec proposal with a question mark.” First, we’ll configure the protocol question mark. And as we know, there are two security protocols that we can configure.  Let’s configure ESP. That means we need to specify the encryption algorithm and the authentication algorithm. So let’s do that. Set the proposal and the proposal name. The keyword we are looking for is “encryption algorithm.” Those are the options that we have.

Like I said earlier, if you’re on a more recent version of the Juno’s operating system, you may see some more options as well. Right now, we’re going to set this to 128 CBC. Notice that you have another option here that ends with GCM. That stands for Gala counter Mode. Just like CBC, it is a mode of operation that is used for encryption. So we’ll set the encryption algorithm, and we’ll also set the authentication algorithm. So set the proposal name, and the keyword we’re looking for is authentication, followed by a question mark. And let’s set this to HMAC shaw 196. HMAC stands for hash-based message authentication code. Again, it’s a specific type of algorithm. We’ll press enter here. So that’s our phase-two proposal. Now we’ll configure a policy.

So put in a question mark. Now we’re going to use the policy keyword here. As a result, we have a policy question mark. We need to provide a policy name. Let’s call this an IPsec policy. One question mark Here we’re going to specify the Diffi Hellmangroup to be used for perfect forward secrecy. So the keyword is “perfect forward secrecy.” The next keyword is keys, and then we need to specify the group. In this case, we’re going to use group two. And the last thing we need to specify is the name of the proposal that we want to use. So set the policy. Policy name? And we’re going to use the keyword “proposals” and the proposal name, which is IPsec Proposal One. So that’s done. And the last thing we need to configure is the VPN information. So put in a question mark. The keyword we’re going to use is “VPN question mark.” We need to provide a name for the VPN. Let’s call this as SRX.a hyphenated B. meaning from A to B. And let’s put a question mark here.

We’ll use the IC keyword “question mark.” And we need to provide the name of the remote gateway. We’ve already configured this as part of phase one. So if we put a question mark here, we should see that, which is Srxb. We also need to set the policy that needs to be used. Set the VPN name accordingly. The keyword is IC, and the next keyword we are looking for is IPsec policy. If we put a question mark here, we should see the name of the policy, and there’s one last thing we’re going to configure over here that is set VPN, VPN name, question mark, and we are going to use this keyword here. Establish tunnels, and we have two options over here: we can say “establish tunnels immediately” or “on traffic” if you set it to immediately. As soon as we complete the configuration on both sites, the VPN tunnel will come up. If you set it to on traffic, the tunnel is only established when user traffic comes in, so we’ll set it to immediately. So as soon as we commit the configuration on both sites, we should see the tunnel come up. Press Enter, let’s go up, and let’s do Show IC.

So that’s our phase one configuration; let’s doshow IPsec for our phase two configuration. So from a phase one and phase two standpoint, we are done with the configuration. Now we’re going to configure the security policies. We’re going to configure two security policies. One, from the trust zone to the untrust zone, that will allow the host connected to Srxa to initiate traffic to the host connected to Srxb, and will also configure another policy in the reverse direction, from untrust to trust, that will allow the host connected to Srxb to initiate traffic to the host connected to Srxa. Before we configure the policies, let’s see if we have any existing configuration. So if I do a show policies, we can see that it’s all empty. So let’s begin the first configuration. So we need to provide a policy name and edit from zone or edit policies from zone trust to zone untrust. I’ll call this one “trust.” Untrustvpn. Now we need to provide the source address set to match the source address. When you’re configuring this in a production environment, you’ll want to be very specific in terms of what traffic you’re allowing over the VPN tunnel.

So specific subnets from one side to the other. But since we are in a lab environment, we’ll just keep it simple. We’ll configure this to any; we’ll say “set match destination address” to any; we’ll say “set match application” to any; we’ll then configure the action, which is set to “permit question mark,” and we will choose to tunnel the packets, meaning send them over a VPN tunnel question mark. We need to provide the VPN name. The keyword for that is Ipseg, VPN, and the VPN name that we configured earlier. A hyphenated B is SRX. Perfect. Let’s do a show. Okay, let’s also create one more policy in the reverse direction. So edit security policies, change zone untrust to zone trust, and we need to provide a policy name. I’ll call this an “untrustworthy” VPN, and we’ll provide source and destination information. So any set that matches the source address, any set that matches the destination address, any set that matches the application—any set then permit. And we want to tunnel the packet into an IPsec VPN, which is called SRX-A or SRX-B. The policy configuration is almost complete, but we’re going to add one more command, and that is pair policy. This keyword can be used to link a policy, in this case the policy called Untrust Trust VPN, to another policy that references the same VPN tunnel, and that is going to be this policy in the reverse direction. The purpose of doing this is so that both policies can share one proxy ID and one security association. We haven’t yet talked about proxy IDs. A proxy ID is a mechanism for identifying traffic carried within the VPN tunnel, and it contains two components for identification purposes: a local prefix and a remote prefix, as well as the associated service.

So proxy ID is just a mechanism to identify what traffic is being carried over the VPN. By linking both the policies using this keyword, “pair policy,” we can have both the policies share one proxy ID and one security association. So what happens if we don’t pair the policies? Well, if you don’t pair it, the device will have a different proxy ID for inbound and outbound policies. So that’s really the whole idea—that both policies will share one proxy ID. So let’s quickly do that. Set pair policy, or we need to type the command again, so that’s set, then permit tunnel, and then the keyword, which is pair policy, and the policy name. Now we have to type that out. So I’m going to copy this from here and paste it over here. So now, if we do as such, that configuration should show up. We must now apply the same logic to the other policy. So if we go up one level and if we do a show from here, we have the pair policy on this policy configuration, but it’s missing on this one. So let’s do that quickly. Set from zone trust to zone untrust policyname, trust to untrustvpn, then permit tunnel pair policy, and we must provide the untrust to trust VPN policyname. All right, so we are almost done with the configuration except for one last setting, and I promise you this is the last one. We are going to set the MSS value for the VPN connection, and the command to do that is at the top of the configuration mode. Set the security flow, then the question mark.

We’re going to set the TCP MSS value, or the TCP maximum segment size value, for IPsec VPN, and we’re going to set this to 1350. I missed a keyword there, so I’m going to erase one word from there. Set the security flow TCP/MSS Ipseg VPN I missed the “MSS” keyword. 1350 Now the purpose of doing this is to set the maximum segment size, or the MSS value, of packets that are going to enter the VPN tunnel. As we discussed earlier, when traffic flows over the VPN, there are headers that get added on top of the packet. And those headers increase the size of the packet. By setting a lower segment size, we are allowing room for the headers to be added. So when all those VPN headers get added, the packet doesn’t become large enough that it needs to be fragmented. As you may know, fragmented packets can cause performance issues because they need additional processing, and sometimes they can also cause communication issues. So we are lowering the MSS value of packets that will enter the VPN tunnel. So even after adding all those VPN headers, the packet will not be large enough that it needs to be fragmented. Okay, so that’s all the configuration. Let’s quickly take a look at all that we’ve configured and commit the configuration. So the first thing we configured was to show security IC. We have an ICC proposal and an IC policy, and our gateway configuration demonstrates IPsec security. Here again, we have a proposal, a policy, and a VPN configuration. And we also configured a couple of policies, one for each direction. and we configured the MSS value. So we are now ready to commit the configuration. All right, committing has been completed. Let’s now go to Srxb and repeat all of that configuration, which should take us another 20 minutes. I’m kidding; I’ve already done that on Srxb. I already applied all of the configurations, so we can save some time. Let’s quickly review the configuration. So I’ll enter configuration mode, and from here we’ll do Show security IC. And you will see that I have configured the same proposal (phase one proposal) and the same policy for phase one.

The only distinction is in the gateway parameters. So the gateway address is one for Srxa, which is eleven one one. The external interface is FEarly. I’ve also configured the IPsec settings. So I’ve configured the ESP proposal encryption and authentication algorithms (Diffihelman group two) for perfect forward secrecy. And I’ve configured the gateway parameters over here. I’ve also configured a couple of policies. So demonstrate security policies. One policy from the trust zone to the untrust zone, and another policy from the untrust zone to the trust zone And I’ve also paired the policies, and I’ve also applied the TCPMS settings to show security flow. And here we can see that the setting has been applied. So that means the configuration is ready on both SRX devices. We should check to see if the tunnel is open. So if I go back to the operational mode here, and if I try to look at the Phase 1 tunnel, it will show security like a question mark, and the keyword is security associations. If I press Enter, we can see that the phase one tunnel is up. Let’s take a look at some more details. Show security. I have security associations, and let’s look at the details. Press Enter and now we have some more information. So you can see here that the pier is the other device. One, two, eleven. The gateway name is Srxp. This device is the initiator of the connection. The exchange type is main mode. The authentication method is preset keys. Here is the information for the local and remote gateways. Here are all the algorithms that we configured. And here we have some traffic statistics. All right, now let’s take a look at phase-two information. So show the security IPsec question mark, and the keyword is security associations.

And here we can see a couple of security associations. Now before we look at the details of the security associations, let’s go to the host that’s connected to SRXa and ping the host that’s connected to Srxb. So ping 1011, and we can see a response coming back. Okay, let’s go back to the SRX and look at the details of the security association. So demonstrate security IPsec and security associations, and we’ll go over the details. Here is some more information. Here’s the VPN name. Here we can see the local gateway and the remote gateway. Here we can see the IC version that we are using. So that’s IC version one. Here we can see the policy name. The security association direction can be seen here. This one is an inbound direction, and this one is an outbound direction. Let’s also look at some traffic statistics. So we’ll use the command “Show security IPsec” and we’ll say “Statistics.” And here we can see under the ESP statistics that packets are being encrypted and decrypted. The important thing to note here is that we do not have any errors. So that means our configuration is good. All right, so that’s how we configure policy-based IPsec site-to-site VPN. The key takeaway here is that with a policy-based VPN, we are using security policies to tell the SRX device which traffic qualifies to be sent over a VPN tunnel. I’m going to encourage you to try this configuration on an SRX device. Even if you have only one SRX device, you do not have a second device to configure the other end of the VPN tunnel. I encourage you to try the configuration on one device just to get a feel for the commands and understand the different settings that can be used to configure a policy-based IPsec VPN.

6. Configure Route-based VPN

Welcome back. Let’s move on to the second VPN configuration style, route-based VPN. So we’ll first understand the configuration scenario. We’ll then talk about the steps at a high level, and then we’ll go to Juno’s terminal and begin configuration. So the configuration scenario is exactly the same. We have two SRX devices. SRX a and SRX b They are connected to each other on their own networks, and the IP addresses look like this: eleven one one and eleven one two. We have a host connected to each of the SRX devices. The host on the left is 1921-681-1024, and the host on the right connected to Srxp is 10 1 100:24. With route-based VPN, we are going to configure a new interface, which is called the “Virtual Tunnel Interface” and is labelled “SD Zero.” And we will be using static routes to define what traffic needs to go through the SD 0 interface.

So the SD Zero interface will be used to establish a logical link between Srxa and Srxb. So SD zero on Srxa will have the IP address 10 110 1, and SD zero on Srxb will have the IP address 10 110 2. All IP addresses in this topology have a 24 subnet mask. Make a note that the IP addresses used by the SD-Zero interfaces are on a completely different network. So 10 is the network used by the SD 0 interfaces. Also note that they have private IP addresses. Class A addresses beginning with ten SDzero interfaces belong to the VPN connection or the virtual private network connection, so they can have private IP addresses. So on the Srxa device, we will configure a static route that routes traffic to the destination 10: 1124 via the SD 0 interface. Similarly, on Srxb, we will configure an async route that uses the SD zero interface to route traffic to the destination 109 (2168-1024). As we discussed in the last lecture, their devices do not have to be directly connected like we see over here.They can be connected over the Internet.

Since we are in a lab environment, the SRX devices are directly connected. Also, it’s not required to have SRX devices on both sides of the VPN connection. Now let’s talk about the configuration steps at a high level. So for the route-based VPN, we’ll first begin by configuring a secure tunnel interface, or an SD-Zero interface. Under the Edit interfaces hierarchy, we know that every interface must belong to a zone. We could attach the SD zero interface to the untrust zone because that’s where the traffic is exiting. Or we can configure a new security zone. And that’s what we are going to do. We’ll configure a brand new security zone, and we’ll attach the SD Zero interface to this zone. Step number three is to configure the route. This is under Edit static routes, and we’ll route VPN traffic via SD 0. Then we’ll move on to the actual VPN configuration. So we’ll configure the IC proposal under “Edit Security IC,” where we’ll define the authentication method, authentication and encryption algorithms, Diffie-Hellman group, and lifetime. Then we’ll configure the ICT policy, where we’ll define the mode, which is main or aggressive.

We’ll configure the presat key and the IC proposals that will be used. Then we’ll configure an IC gateway where we’ll define the ICT policy to use the remote gateway address and the external interface. Then we’ll move on to IPsec configuration. So we’ll configure an IPsec proposal under Edit Security > IPsec. Here we’ll define the security protocol, which can be ESP or AAT, the authentication algorithm, and the encryption algorithm. If we choose to use ESP, then we’ll configure the IPsec policy where we’ll define perfect-forward secrecy, or in other words, another Diffi-Hellman group for phase two. And we’ll also configure the IPsec proposal to be used. We’ll then configure an IPsec VPN where we’ll define the gateway, the IPsec policy to use, and, very important, we’ll bind the VPN with the Secure Tunnel interface. And finally, we’ll define security policies to allow traffic. We’ll define one policy per direction of flow. Now let’s get to the terminal and start configuring. All right, I’m here at the terminal of the SRX device. I’ll first enter configuration mode, and the first step is to define the Secure Tunnel interface. So we’ll begin with the edit command, edit interfaces, and we’ll define st zero or secure tunnel interface zero. We know that IP address configuration is done under a unit or a logical interface. So set the unit zero family in it, which is an IPV4 address, and then the IP addresses 10, 110, and 124. Next, we need to attach the SecureTunnel interface to a security zone. We are going to define a new security zone. So let’s do that. Let’s edit security zones, security zones, and call the zone.

As VPNs, we need to attach the secure tunnel interface. So we’ll say “set interfaces to zero zero.” Let’s do a show. All right, now let’s go to the top. And now we need to define a static route. So the command we’re going to use is “set routing options.” Static is the keyword for static routes. The next keyword is route. And now we need to specify the destination. Make a note that I already have another default route configured on the SRX device. This route that we are defining now is specifically for VPN traffic. We are currently configuring on Srxa, and we need to define a route for the destination on the other side connected to Srxb. And the ratio is 10:1. I’m going to quickly pull up the scenario diagram just to verify the static route. All right, so here’s the configuration scenario diagram on Srxa. We need to define a static route for this destination. The SD-Zero interface is used to route ten one. Let’s go back to the terminal. All right, so back over here. Set routing options Static route destination is 10, and the keyword we are going to use is “Next Hop,” and we are going to route it via SD Zero. Okay, so now we’ll define the phase one configuration, and we know that it’s under Edit Security IC. I’m going to clear my screen. First, we need to define a proposal. So we’ll say “edit proposal,” and let’s give it a name. I’m going to refer to this as Proposal One. First, we’ll define an authentication method. Set the authentication method, and we’ll set it to Preshad keys. Then we’ll define the authentication algorithm, and we’ll set this to Shao One.

Then we’ll define the encryption algorithm, and we’ll set this to AES 128 CBC. We also need to define the Diffi Hellman group. So set the DH group, and we’re going to use group two. Finally, we need to define the lifetime setting (lifetime seconds), and we’ll set this to 86,400. We’ll go up one level. And now we need to configure an IC policy edit policy. And let’s call this IC policy 1. Here, we need to define the mode. Let’s begin with a question mark. So first we’re going to define the modeset mode and set this domain. The proposal must then be called. So set proposals, and we’re going to call IC proposal one. We also need to define the preshad key. Set the preshad key, question mark, and ask key text accordingly. And the primary key is Juniper. Let’s go up one level. And now we need to define the gateway. So edit the gateway. The gateway configuration contains information about the remote gateway. So let’s name this Srxp. Change the gateway srxp. Let’s begin with a question mark. First, we’ll define the ICT policy. Set the ICT policy, and we’ll make it iPolicy One. Then we need to define the remote gateway address. So set the address to eleven, one, two. Then we need to define the external interface. The external interface is the interface that will be used for the VPN connection, not for routing purposes.

So the interface is Fe. Make a note. We are not going to configure the SD Zero interface here because that’s the interface for routing VPN traffic. But the actual connection of the devices is on the Fe interface. So set external interface fe to zero. And finally, we’re going to add one more command. We’re going to set the version. When we looked at the policy-based VPN configuration example, we did not configure this. So automatically, it used IC version one. But we can hard code this so we can say, “Set version, and this time let’s do V 2.” Only use version v2. Let’s do a show here. So we’ve called the IC policy, we’ve defined the gateway address, we’ve defined the external interface, and we’ve set the IC version to IC version two. That completes the phase one configuration. Now we’ll get to phase two. So we’ll say “Edit IPsec.” And first, we need to define a proposal. We need to provide a proposal name; let’s call this IPsec Proposal One. So we are under the “Edit Security” IPsec proposal. Let’s begin by setting the security protocol. So the command is “Set protocol,” and we’re going to set it to ESP. With ESP, we need to define an authentication and encryption algorithm. So put in a question mark. The keyword is “authentication algorithm,” and we’re going to set this to HMAC-SHA 196. We’ll also set the encryption algorithm to AES 128/128 CBC. Next, we need to define an IPsec policy. So we’ll say “edit policy,” and we’ll provide a name. Let’s call this IPsec Policy One. Here, we’re going to configure perfect forward secrecy. Set perfect forward secrecy, and we’ll assign this to group two. Group Two. Set perfect forward secrecy keys group 2, as well as the proposal. So we’ll use proposals, question marks, and call IPsec proposal One. Now we need to configure the IPsec VPN. So the command is “edit VPN,” and let’s call this “SRX A Hyphen B.” Let’s begin with the Setspace question mark. We’ll use the IC keyword Set IC, and we need to define the remote gateway, which is already configured as Srxb. Then we need to configure the IPsec policy. set IC IPsec policy and the policy that we just defined, which was IPsec Policy One.

And we’ll also configure and set up established tunnels immediately. This means as soon as the configuration is ready on both sides, the VPN tunnel should come up. We do not need to wait until interesting traffic is generated for the VPN to be established. So set up tunnels immediately. And we have one more configuration to define here, and that is the Bind interface. Set Bind Interface, and here we’ll bind it to Stzero Zero. Press Enter, and that configuration is complete. Now the only thing that remains is the security policy configuration. So let’s go to the top and define the security policies. So modify Zone’s security policies. The traffic is going to originate from the trust zone, and we are going to send it to the zone where the SD zero interface is located. So we’re not going to send this to the untrusted zone, but we’re going to send it to the VPN zone. This is very important. So edit the security policies from “Zone trust” to “zoneVPN not untrust,” and we’ll provide a policy name. This is referred to as VPN trust. Let’s match the source address in any set matching the destination address in any set then permit. Because we are not defining a policy-based VPN, we will not use the tunnelkeyword, so only the permit action will be used. So if we do a show here, that’s what the policy configuration looks like.

Now we are in a lab environment, so we’ve configured everything as “any,” but in a production environment, you’d want to be more specific in terms of which IP addresses and which applications you’re permitting. Let’s also define a policy for return traffic or traffic coming from the other side. So change “Zone VPN” to “Zone Trust Policy Name.” Let’s call this a VPN to trust, and we’ll match the source address. So any set can match the source address, any set can match the destination address, any set can match the application, and any set can then permit. With that, the security policy configuration is complete. And there’s one last thing to configure, and that’s the Tcpmss value for the VPN Show Security flow. And as you can see here, I’ve already defined the Tcpms value for the IPsec VPN traffic as 1350. We spoke about this in the last lecture, where we said that with VPN traffic, with all the headers adding up to the packet, the packet can become large enough to require fragmentation, and fragmented packets can cause trouble, require further processing, and can also cause issues with tunnel establishment.

So we’ve reduced the maximum segment size of VPN packets to 1350. With that, we will perform a commit check just to ensure everything is in place. All right, everything looks good. Let us now issue the commit statement. Commit has been completed. Let’s now go to Srxband quickly to verify the configuration. All right, I’m here at the terminal of Srxb, and just to save some time, I’ve already applied all the required configurations on Srxb. Let’s quickly verify that. So, starting in configuration mode, we’ll show interfaces. SD Zero, so here’s the configuration of the secure tall interface. Then we’ll look at the zone showing security zones. The SD-Zero interface is connected to the securityzone VPN. Then we’ll look at the routing configuration. Set the routing options to static route, and we’ll look at 192.168.1.24 because it’s from Srxb’s perspective and is routed via SD 0. Next, we’ll look at the phase-one configuration shown in Security IQ. So here we have the proposal, here we have the IC policy, and here we have the gateway. Make a note that we’ve explicitly specified IC version two for this configuration. Let’s also look at the phase-two configuration shown in Security IPsec. So here’s the IPsec proposal, here’s the IPsec policy, and here’s the VPN configuration. It’s worth noting that we’ve bound this to interface st 0.

Finally, we’ll look at the Show Security policies, and we’ve got similar policies on this device as well. So all the configuration is in place. We should see that the tunnel has been established. We can confirm this with Srxp as well. So from the operational mode, we’ll use the command show security IC Security Associations, and here we can see that the phase one tunnel is up, the state is up, and notice that the mode is IC version two. We can see some details as well. Display Security IC Security Associations detail from this device’s perspective; the peer is 11-1, which is SRX-8. This device serves as a responder. The authentication method is pre-shared keys. Version two is the exchange type. And here are all the algorithms that we’ve configured. And here we have some traffic statistics. Now let’s take a look at the IPsec security associations. So, enter and show security IPsecsecurity associations. And here we can see that we’ve got two security associations. Let’s look at the details. So here we can see the VPN name, here we can see the local gateway and the remote gateway, and this information is what is known as the proxy ID. It is an identifier for the traffic that is being tunneled. So recall the security policy that we configured. We set it to any; we can see that over here, and we also set the application to any; we can see that over here. As a result, proxy ID. is an identifier. for the VPN traffic.

We’ll talk more about this in an upcoming lecture. IC version two is being used, and this is the bound interface. Another important thing that we should know is SPI, or the security parameter index. This is a value that is used to uniquely identify a security association. We have two security associations, so we should see two spies or two values for the security parameter index, one for each security association. Let’s also look at the traffic statistics. So show security IPsec, show security IPsec statistics, press Enter, and we can see that we’ve got some encryption and decryption going on. We haven’t tested any traffic yet, so let’s do that from this terminal, which is the terminal of the host connected to SRX A. Let’s ping the host connected to Srxb. So ten dot one, one dot 10, press Enter, and we can see responses coming in. Let’s return here, hit the up arrow, and show security IP six statistics; we should see the counter-increment, which we can see over here. Okay, so that’s how we configure a route-based VPN. The key takeaway here is that with route-based VPNs, we first need to configure a secure tunnel interface. Attach that to a zone. We can attach that to the existing zone, which is the untrusted zone, or we can attach that to a new zone. Then we need to define static routes for the destination traffic via the secure tunnel interface. And the other thing to keep in mind is that security policies will not use the tunnel action, and they should be defined from the trust zone or from the source zone of the traffic to the zone where the secure tunnel interface is attached.