CCIE Security Lab Video :: IKEv2 L2L VPN

good morning good evening and good afternoon everybody my name is Peter Cole is name and I will be your instructor during this free few lecture and the topic for today is going to be IDE version 2 so specifically what I will be trying to show you here is going to be how to build a site-to-site VPN connection between two iOS routers when IP 2 is going to be used for negotiation and we will take a look at so-called flexible a VPNs which use extensively use a tunnel air base paradigm for the configuration it is also possible to use legacy crypto maps to build IP to at least side to side connections the but this map of this is not going to offer us as many benefits as what can be accomplished with flex VPN or just the tunnel interfaces so the tunnel interface keator this is something that you should be actually and now from the from the IP 1 config when you are dealing with for example remote access VPN that were placed on dynamic virtual tunnel interfaces now this feature can be also used in side to side connections which is known as static virtual telegram places and the main benefit of using this method over crypto maps is that the IPSec connection is no longer associated or just bound to the physical port and the reason that this is important is that it allows you to apply additional features such as us or maybe the firewall policy directly on the on the virtual interface that represents our IPSec tunnel itself first just you can have a separate policy applied to the physical port which handles the traffic sent in clear so with the tunnel databases another thing is that is going to be different from the legacy crypto Maps is that our encryption domain is no longer negotiated it is going to be it is going to be the routing table what controls the traffic that is supposed to be encrypted and the logic here is that whatever the router is going to send to the virtual tunnel interface is going to be encrypted first is whenever a packet is to be sending clear actually further to the physical port it is going to be sending clear ok so um let's now talk about the basic theory I just want to discuss quickly discuss the um I Persian the negotiation because this is something that I will be and there is actually one picture that I will be using here in the demonstration I will be showing you here in the configuration and which is going to be one one of the methods we can modify our routing table to specify what subnets we would like to be reachable for the tunnel and this is going to be part of this negotiation here so there are going to be just two places and two exchanges the rounds of exchanges which total to four messages in IP to vs. will be had in IP one we had a eager aggressive mode in phase one which were three messages or if this was main mode that we were dealing with six messages and then the peak mode exchange some additional message is following our page one now here as I mentioned there are going to be just for messages total the two messages are going to be used to establish our connection a so called I guess a that is used to protect - occasion exchange now the I guess a and it exchange so the first messages as we you can see on this and our drawing here the initiator is going to be sending a so called I guess a in the request packet which contains our policy so this is going to be this is what's known as our Ike proposal the vetti Helmand grip hashing or just integrity function and encryption functions and then the responder is going to reply with the IHSA and the reply message sending its own policy and once the device is agreeing on the policy being used now the DT Hellman exchange is going to be performed and this a tunnel is going to be built so this basically means that a subsequent negotiation which is called icoffey negation is already protected by this I guess a and in the second negotiation we see there is a couple of other elements being exchanged apart from the policy that we will use to protect our data plane we nightly sack so our transform set which is going to be the security protocol integrity function and encryption function and we also exchange information about the traffic selectors and which is an equable proxy access list and Ike identities are exchanged as well so for virtual tunnel databases at least for site to site connection the traffic selectors and as we will see that this is going to be basically everything the devices will will say that whatever no matter what is going to be the packet that is sent to the tunnel interface it is supposed to be encrypted so there are going to be two tunnels when the process is finished so after Ike upon occasion is finished and there is going to be so-called childís a and that is created so at a high level this is going to look like that we'll start with this is a ended exchange which is once again used to create a connection that will protect a subsequent negotiation so when this exchange is done this is what built our with builds our place connection our first panel which is called I guess a and here is where the second negotiation is performed but this one is obviously already protected by the functions and negotiated in I guess a in it now when this second exchange is done this is what is going to be used to derive our second connection second secure connection known as a child sa so this is going to be the second tunnel this was the first tunnel this is going to be the second tunnel called child si which is used to protect the data traffic so these are going to be our security associations and this is basically an equi blend of IP one um ESP and actually this is going to be inbound and outbound and now depending on what protocol was negotiated if I stood and the icon fornication I should say and this is going to be either ISP or authentication header here so this is how the negotiation is going to look at the high level and obviously as I said this title let's say it is used to protect our data plane now during this a second negotiation so I communication exchange a depending on what type of tunnel or what type of VPN we are trying to build or if this is a site-to-site connection if I cover ization was essentially enabled there is going to be one additional exchange that is not shown on this diagram here which is called mode configuration so this is something that you should you should be already familiar with from remote access VPN so in IP one when there was one additional phase or just exchange taking place between phases one and to which was called phase one and half and this is where we were performing extended authentication when you were pushing the policy to our client and performing reverse calc injection so this phase one at F is now kind of like built-in to Anchorage into a standard it is not part of the of the standard and it can be also enabled and this is something that you will enable by a configuring Ike version two authorization so I version two authorization is mandatory if one of the devices is configured to ask for any gear s so this is going to be an example of in haven't spoke to Paula G well now that one of the devices act acts as a client one acts as a server and the client is asking the server for an IP address that is going to be assigned to it's tunnel interface then the authorization is optional for side to side in 92 but it can be enabled and this is something that I will be also showing you during this session one advantage of using one potential advantage of using the ICO polarization or just well configuration in general for side to side connections is going to be the ability to perform to use a feature and known as I version two rowdy so I person to routing is one of the methods of controlling our encryption domain in ID 2 when flex VPNs are being used so we will take a look at this in the example here ok but before I bu before I show you the configuration and let's quickly talk about the L let me quickly show you the Polish here and we will be using during this demonstration it is a really simple topology with just two iOS devices and we will have rubber 11 that is connected to 172 in 1611 / 24 so this is the subnet that we want to protect on this side with catalyst 1 being connected we're we're be essentially testing this connection is in catalyst switches so this is connected this guy is connected to some network some devices in the middle and when finally risking the another router another up VPN endpoint router 10 which is connected to 172 16 10.0 / 24 with another switch connected catalyst - which also uses 100 as its address here now let's take a look at the command line here because I also want to specify the addresses of the robbers themselves so on the level it says that this is going to be this is a public address that you will be using to establish a VPN tunnel this is 50 4.1.2 dot 11 so it's going to be 54 1 to 11 and I believe on 10 this is going to be something from the 23 class show IP interface brief so it's 23 to 110 so this is going to be the physical lobby 11 now this is going to be physical of 1020 frayed up to that one that 10 and we will be obviously building the tunnel between those physical interfaces and I Peter is going to be configured for negotiation okay so on the command line here now let's start number configuration on router 11 and we all think about we all have to think about a couple of components or just elements that are needed to configure an IP to a VPN which is going to be for this I guess a and in exchange we will definitely have to define our policy and for the policy itself so our cryptographic functions we will need to specify our proposal so the proposal is something that is going to be nested in the policy and then we will also have to define our ISO camp or just ugly to profile which is where we will specify our match identity statement define the authentication method which is no longer negotiated in 92 authentication method is statically configured and this is where we will also define our credential store in that IP to profile so this is what we will need for I guess a and it exchange for I communication we will have to specify our authentication credentials transform set then the transcript set is going to go to the ipsec profile which is also going to call out our IP to a profile and finally the ipsec profile is going to be applied to our tunnel okay so let's go ahead and start with the proposal here crypto IP - proposal I'm going to call it a PR LP and it says that it must have at least an encryption algorithm and integrity algorithm and a de tucumán trip number so let's go for a s now let's say 192 let's go for 30 , group number 14 and for hashing we will select which is called integrity here and let's go for sha-256 douche around section proposal now you have an option to specify there're more than one function for each of these elements and in ugly too it is going to be kind of like the initiator who controls what policy is going to be selected for the session so if I were to say here that for my encryption I first think when I use a wes is 128 and then AES with 192 bits used for the key this is going to mean that device is going to be first trying to negotiate 128 version so as long as this is supported on the other device by the other device this is going to be the function that will be used for encryption so the order of configuration of those proposals is important in our case this is going to be just a 192 now for encryption okay then the proposal must be activated which happens by assigning it to the policy so I could rewrite version 2 and policy let's call it I pol and it says it must have at least one complete proposal attached which in our case is going to be the ID prop now you also have an option to specify the matching criteria for the policy which is used when you're either initiating or responding to a connection request and the logic is that you have an option to specify an IP address of one of your local interfaces and only if the session is a niche initiated for this interface that matches which you in this command or when the SI initialization request is received on the interface that this policy is going to be used so we can have multiple policies or different interfaces in our case I'm not going to specify an amount of the matching conditions which means that this is going to be our global policy that applies to connections send or receive prayer and import okay so the next thing is going to be to define our hydrogen to profile the which is I would say a component that belongs to both bases so I can say in it and I co-education now one of the elements that I will need to find it within the profile is going to be a key ring because I will be opening hating our devices using pre-shared keys so it kind of like makes sense to first configure the keyring and then I start breaking on the profile my crypto IP to key ring and my peer is going to be router 11 the pure command this is basically used to provide some structure to the giving itself you will have a a separate section for you can have a separate section for different devices and this is just a name and that is locally significant on this device so I say that for this is going to be my peer and this is what we actually specify who is the pure so what is it what is it AP arrests and what's the pre shirt key so my peer is it's going to be router 11 which is now 54 1 to 11 and then the preacher key is going to be IP expert now for the keys you have an option to specify your local and remote keys and this is because in IP version 2 you can configure a so called asymmetrical pressure key authentication so I can authenticate myself with key number one but the peer is going to be authenticating to me with another key in our keys the keys will be symmetrical like in IP one so this is what we have so far so crypto so run a section crypto IP 2 we've got the proposal that goes to the policy and we have the curing now the profile is going to be defined next let's call it type prof and as you can see we have to we must specify the authentication method and a matching a criteria and now the matching criteria this is something that is needed to find a profile when someone else initiates a session to us so what we are acting as a responder now this this command is technically not needed when you're the initiator because the device is going on what profile we want to use for the session based on what you nested purchase associated with the ipsec profile because the ipsec profile as we will see is going to be a configured on the tunnel database itself but for the for the configuration here actually for any type of configurations I would always define the matching criteria and so in our case and let's say that we will be matching the connection based not on the IP addresses let's go for let's use I can't entities as our matching criteria so on this device we will say that our matching criteria is going to be fully qualified domain name and we are looking for this value re 11 that IT expert calm so the reason you can specify this as a matching criteria is that if you take a look at this high communication exchange the identities are exchanged during this this the second eye communication exchange were identity information about the initiator is sent along with the authentication hash so when the responder gets the packet it is going to already know what is the identity information of the initiator because this is what is what it gets from this eye communication request packet so this is where you can use anything for the identity in the in your profile here so it doesn't have to be an IP address now let's go for the authentication command the authentication is going to be pre shared key for both but we will be authenticating to our peer with a pre shared key and the peer is supposed to authenticate with very short key as well and finally the last element here actually they're going to be two one is going to be to specify what is our credential so the way what is going to be the credential people used to authenticate the tunnel which in our case is going to be the key so the keyring is configured locally it was called kay ring and finally I will say that my identity my chi and my Ike ID is going to be our 10 that IP expert comm this around section crypto ID 2 so once again we've got the proposal that the policy identity ring and the keyring is called out from the profile which is very also where we also specify what is the authentication effort for the session what is our identity and what identity we will be matching to have a match for the profile so what about the other configuration elements this time this is going to be more of that eye communication step so transform set ipsec profile and the tunnel interface the SVT eye you'd sell crypto IPSec transform set let's go for Triple DES and sha then transform set must be configured must be nested in the ipsec profile because we will be using the tunnel protection feature so this is a this is going to be at a static virtual tunnel interface configuration for just a flag VPN in 92 and we have to define our ipsec profile so we can use the tunnel protection command on the error base itself so prep the IPSec profile and this is where my transference that goes sab transform set along with my I person to profile and now the tunnel let's go for 101 as the number here and we need to specify what is the the subnet that is going to be assigned to the tunnel network as the tunnel network which is let's go for 172 m 101 101 10 for router 10 then my tunnel source is my physical error page my tunnel destination is going to be what we have configured in the keyring this is my tunnel destination so the physical address of router 11 then the tunnel mode is IPSec ipv4 so I'm changing the encapsulation from the default GRE to be SBT I to be IPSec encapsulation and then tunnel protection this is my ipsec profile IPSec prop so with the SBT I is being used as the configuration method if this is a always absolution and the SBT is they are always up I mean the the VPN session is always up and the device is going to be constantly trying to initiate a session so there is no need to specify our encryption domain once again because the encryption domain is as what's specified by the routing configuration so it's going to be the routing table what tells the router what traffic is supposed to be encrypted that versus what traffic is supposed to be sending clear so basically whatever is going to be sent to the tunnel is going to be IPSec protected okay so now let's take a look at this configuration and let's copy as much as we can to the other device so the policy the proposal and the policy the functions will have to match I'm going to also use the same names on another device this is going to be the fastest way of doing this so I can safely copy this DS to it then for our keyring I'm going to use the same name but this is going to be obviously for rubber 10 which uses 23 to 110 as it takes a rest so this is going to be for 23 to 110 and the pre shirt key is going to be IP expert now it is also possible to specify the identity instead of the IP arash so this is this would be useful when you would like to find the key for the peer not based on the IP address from the packet but based on the identity information that is sent by the peer and this is only going to work on the responder so on the other device that is that is replying to the is a init packet and this is because the based on how the negotiation is performed in night version 2 that the initiator is going to find the matching profile and this way a matching keyring once again based on the fact that the profile is say showed another face down on 101 the profile is attached to the tunnel error face so it knows that whenever it is going to be establishing a VPN session with this guy here this is an SVT I it is supposed to use these phase 2 functions and this place to information and ipsec profile not only includes the transform set but as I mentioned also that I do ID to profile and the profile points to the to the keyring so when you know take a look at the keyring here if I wanted to say that instead of the errors here I would want to use the identity option it would never find a matching key in the keyring because at this point before the negotiation started it doesn't know what is the identity of the of the pure you can have multiple entries in the keyring so it is never going to know which one it is supposed to use for the pier this is what you have to use a mat use the address command on the initiator and to figure out what is going to be the key for the session versus of on the device that is going to be acting as the responder m at the time when the keyring is found it is already going to going to know what is the identity of the pier and you could use this option to specify your matching condition for to find the key but in our case I'm going to say that both devices are capable of acting as initiators so I'm going to be using the address option on both okay so let's take a look at what we have on a 911 to your so we've got the proposal we've got the policy and we have the keyring now the next element is going to be our IP to profile so let's use the same name match identity in this case it's going to be up to the end of router 10 so our 10 that IT expert calm because this is what we said as identity on this side then these free commands I can save we copy them and paste versus our identity is going to be also type of fqdn but it's going to be our 11 that IT expert cam okay what about the IPSec elements so transform said profile this stuff is going to be the same I was using the same length for the security app components on 11 so I can copy this and paste the names also match and finally the tunnel interface so the summit is going to be definitely the same it's going to be average that it's going to be the print this is going to be the same because it's all so he can be different at zero than zero on 11 this is the same this is something that we must change and we can copy the profile the protection so interphase 10 L 101-80 RS 1 7 2 101 that 101 dot 11 tunnel source my gigabit internet error fish tunnel destination is what do we have in the curing here we've got 20 3 2 1 10 tunnel mode IPSec itv4 and tunnel protection ipsec profile this one here okay so one syslog message that you can see it was generated by the router it says that the line protocol came up on channel 101 so let's take a look at the verification commands show crypto IP 2 session and in this case we see that the session is the tunnel was established we could actually two tunnels negotiated so far we have one tunnel that is the accident of that ID one management session so this is something that is used to protect echo pen occasion exchange and we also have one additional it says child essay which is basically to individual ESP tunnels one for packets sent to the pier 1 for packets received from the pure a different SPS and it says that our encryption domain for the tunnel is everything so basically in other words and the packet that goes to the tunnel interface no matter what is the source no matter what is the destination it is going to be encrypted and we negotiated aes-192 sha-256 entity homograph number 14 the device is authenticated using patient keys we can also take a look at the details here and this is going to tell us that in this case we were the initiator so we initiated the connection the DPD was not configured and there was no net between the devices and the identities or these two finally this is and these are the functions used to protect or a data plane okay so now the question is we should see a similar output cure on on the other device the status is ready now the question is with this configuration what traffic will be and protected the pinna devices so this is our topology here and I said that the goal is going to be to protect this subnet beyond router 11 and this subnet beyond Robert N and since we are using this virtual tunnels this means that the encryption domain is once again not controlled by any type of access list which is negotiating that because the device is essentially negotiate everything it is the routing table which is now responsible for telling the router what packets we would like to protect so if I say show IP route at this point there is a bunch of the routes here but we don't have a route for 172 dot 16th at 11 we don't have a route for this one the only route we have for the tunnel is the tunnel subnet so if you take a look at the phase 2 counters at this point it says that no packets were exchanged but if I were to reach the tunnel address of my pewter so if I were to being 172 101 101 11 we should see that this traffic is sent for the tunnel based on the fact that this is a tunnel network this is a subnet that is defined on the tunnel interface so the traffic sent to this sound that is going to be sent for the tunnel so this stuff is encrypted okay but as I said the goal is going to be to go to encrypt and the traffic between those two subnets so there are actually three methods we can use to accomplish this with SBT ash one is going to be that the simplest solution which is to use static routes the other one is going to be to use dynamic routing protocols so something that we will enable among other interfaces also on the tunnel itself and finally the third method probably the most interesting one is to use one of the icon for ization features called or just by one of the mole configuration features I should say but called IP to routing so of this first option with the static route this is going to be a straight port configuration on 10 I will simply add a route for 172 that's 16 at that 11/20 for where I will say that this is supposed to be sent to the tunnel you could also specify an IP address at 11 but this is a point-to-point tunnel air phase it doesn't really matter if I specify the interface or the next hub at then on 11 we would use will create another route here so 172 16 10 so that's 24 via the tunnel and one I now try to think now let's actually go to the switches here so from cat one I will be trying to reach cat one is connected to at 211 so I will be trying to get to the two this guy here which is 170 to 1610 100 170 216 then 100 and let's say 50 packets show crypto session details so we see now that 55 packets were protected you can also use the show crypto IPSec command show prep the white piece I can say and it is going to give you the same outfit here okay so this was the first map at the steady crouch let's now go ahead and remove those and we will configure a routing protocol over the tunnel so let's go for OSPF as an example here IP ospf process number one area is going to be 0 so first thing I will be track to establish an adjacency over our tunnel then the same on 11 and then we will also say that in addition to run ego SPF on the on the tunnel interfaces and we also want to advertise those habits so it's going to be giga one on both IP ospf one area 0 on this side and on that side and when I say show IP route OSPF we see that 10 learned about 11 and 11 we learned about the subnet that is connected throughout earth 10 so when I try to communicate we again see see that connectivity is maintained maintained putting the boxes show crypto session details and other 50 packets plus routing protocol updates so this is going to be this is going to increase over the time for every single OSPF the packet that is being sent exchanged between the devices so even that the the tunnel interface uses the it says IPSec is being used for transport with IP so there is no GRE enabled on the tunnel the SBT I feature as opposed to the legacy crypto maps which don't allow you to exchange any kind of multicast packets for the VPNs with SBT is this is possible and it's supported natively by the feature so this is what we are able to enable routing protocols and establish adjacencies for the tunnel so this is the second method here and now we will remove this configuration and we will I'm going to show you the spread method implementation of I person to routing so instead of using the dynamic routing protocol what we did in the last case here and we will enable I Peter a link which is something that you can activate with the authorization or the VPN connection and the way that this works is that the devices will they will essentially tell each other about the subnets that are connected to them they would like the they would like to protect so 11 is going to tell about 170 16 11 then 10 is going to tell 11 about this one and they will know that those subnets are supposed to be reachable for the tunnel interface so for our IPSec connection which means that the traffic between the two is going to be IPSec protected okay so I have disabled now rather OSPF one I have disabled our OSPF and you only have to build them have to modify our configuration on both devices to enable the future and the first thing that we all have to configure if your you will have to enable triple a framework and specify a method list for authorization which is going to determine the location of our group policy and finally you will also have to define your at the group policy itself and in the group policy we will specify now what's out nets we would like to protect using an access list so triple-a in the model and then a method with for authorization this is going to be the network service specifically I'm going to call this list Ike let's say policy well actually let's call it let's call it I proud as for I crowding and I will say that the grip policy is going to be stored locally which means that is going to be defined on this device so now for the policy as I said we need to define an access list and we can use a standard access list where I'm going to say that we want to protect package the subnet that is connected to us so the subnet that they want to tell the other end is 172 16 10 slash 24 then trip to IP to authorization command which is used to specify the policy and the name for the policy is i pol excuse me so here is what we can set in the policy in our case this is going to be the route command which I will be using here to enable I person to routing and I'm going to say that we will be telling our appear above the subnet that is connected to us that is defined by this access list access list number 10 now I will also say that whenever the peer is telling me about something that's connected to him I will be accepting them so I will be adding them to the routing table and I'm going to tag them with let's say value 10 first is on the other side let's copy this now let's copy the model and the method list access list is going to be 11 here permit 172 16 11 / 24 and then in the policy also called i pol now we will also say that we wanna say and information about the subjects about our subnets but when we will when we are going to accept routes from the pier and we will tag them with value 11 so essentially what I am trying to do here is that when 11 gets the route from 10 it is going to tag it with 11 versus 10 is going to tag it with 10 so this is going to be useful for any type of situations when you're running a dynamic routing protocols with your insight devices and you want to advertise those prefixes learnt using IP - okay so we have to define the policy now we now have to activate it and which can be done from the profile so let's go back to our active right person - profile and we will have to use the triple-a authorization command where you have an option to specify if you want to configure operation for the users which is a user based organization so user base attributes or maybe you want to assign attributes defined in the group which is a group policy so this is going to be our version here that the user option is it's more useful when you're running it as the open occasion effort and when you're authenticating using radius in this case the group policy is defined locally and we are using pressured keys for authentication the local method list was called I crowd which once again says that the policy is stored locally is the PI locally so this is my listening and then another thing that it asks for is the name it says username but in this case it's going to be the name of the policy so it is also possible to define this policy on a radius server now but in our case once again we are using the local version so the policy name is the policy name is IPL the Sjogren's section profile so the same command goes to 11 and the same method list and the same name for the policy let's just copy this and paste over here so some crypto a key to operation policy I pol it says we will send information about those routes when you're accepting routes from the peer we will tag them with value of 11 first to stand on this device so I will need to clear the session the devices will have to renegotiate the connection the tunnel because now in addition to performing a regular echo indication exchange they will be also using the dos like configuration mode messages so it's going to be request from the initiator and the reply message which is going to be use the tail the initiator about the subnets and also then set an acknowledgment messages for the other side of the connection so it says that the tunnel protocol is app so ideally we should see that the session is is now app we - so this tab shouldn't change from the previous configuration the only thing that is different now is that section of this output remote sadness which tells me that I learned about 172 16 11/20 for purses 11 they learned about a subnet that is connected to the router 10 so what I now say show IP route static it says that it inserted this information to the routing table through the tunnel so it's kind of like an echo length this I get route I get a routing feature this is kind of like an echo blend of I would say split down the link and reverse route injection in IP 1 because those routes they are injected to the routing table as static route so the bottom line here is that I should be still able to connect between the devices for the tunnel and the counters will will reflect that so in this case once again we are not running any type of dynamic routing protocol for the tunnel there is going to be no increase for those counters because there are no multicast packets exchanged the subnets were lured using multi regression which is once again no part of the of the standard ok if you're looking for some more free training from us there are totally good sources you could use to find some additional information this is going to be our account on YouTube and our a technical blog so on IT expert comm for any type of promotions and news and other informations about our company maybe some of the new products or the upcoming lectures you can find us on Facebook and Twitter

Channel: IPexpertInc

Views: 14,707

Rating: 4.8961039 out of 5

Keywords: CCIE Certification, CCIE Security Lab, CCIE Security Video Training, IKEv2, VPN, Virtual Private Networks

Id: S3xocTty3hQ

Length: 53min 32sec (3212 seconds)

Published: Wed Dec 04 2013