042 IPSec Profiles Virtual Tunnel Interfaces VTIs

[Music] in this section we're going to talk about IPSec profiles in iOS as well as the virtual tunnel interfaces that is going to give us a functionality similar to the previous GRE tunnels with crypto maps that we saw before but it's going to allow for less overhead in simpler configuration now the first of these the IPSec profiles are essentially going to be a stripped-down version of the crypto maps that we saw in our previous configurations and what I mean by this is that the the profile is going to contain only a part of the Phase two negotiation parameters mainly being the IPSec transform set what the crypto profile is not going to define is the peers destination address or the proxy ACL so as I was mentioning before there's mainly three parameters that we need to think about when we're dealing with crypto maps who is the tunnel going to which is the peers destination what is going inside the tunnel which is the proxy ACL or the proxy identities and then how is the traffic going to be treated which is the IPSec transform set so in this case the IPSec profile is essentially only defining how the traffic will be treated with the transform set and the end result is going to be very similar where we form two security associations both one inbound and one outbound for IPSec but the proxy ACL is going to implicitly be all IP traffic or all GRE traffic now whether it's IP or whether it's GRA depends on whether we're using the profile on HERV tunnel or whether we're using it on a virtual tunnel interface the rest of our configuration is going to stay the same where we have the same requirements for our phase one eisah camp policy where again we have our four attributes which are the authentication the encryption the hashing and the difficult group once we do the phase one negotiation and then we move on to the Phase two IPSec transfer or the IPSec security Association we're going to define what the transforms are we doing ESP md5 are we doing em ESP sha are we doing Triple DES AES etc but then the proxy ACL is going to be essentially all traffic that is going out in the interface so let's take a look at this on the command line the configuration of this is actually very straightforward as compared to our previous crypto map examples and up to this point we already have a tunnel that is configured between a router one and a router three which is a GRE tunnel that is then riding inside of IPSec so in other words we have GRE inside of IPSec and the way that we configured this was to define a crypto map on both of the endpoints on router 1 and router 3 and in the proxy ACL we essentially said to permit our GRE traffic that is going from router 3 to router 1 and then on the other end we said the same thing to permit the GRE packets that are going from router 1 back to router 3 if we take a look at the command line and look at the tunnel as it stands now and look at the show crypto I see camp SA we can see that the phase 1 is established our phase 1 I could be one negotiation if we look at the show crypto IPSec si we can see that we have an inbound security Association and we have an outbound security Association and when we look at the proxy ACL it says that it's for traffic going from 1 to 3 specifically that is IP protocol number 47 which is our GRE now if we look at the interface of the tunnel its configuration is pretty straightforward here where we just have the source and destination we have an IP address on and then we have our IGP routing configured if we look at the show interface Tunnel 0 and look at the transport mode we can see that the transport protocol is GRE over IP so it means that on the outside we have an IP packet and then underneath that we have the GRE header which is going to be the default mode for any tunnel interface it's always going to be a unicast point-to-point GRE tunnel then at our physical interface level which in this case is gig 0 0 on router 1 we have the crypto map applied and the crypto map if we show run section crypto is specifying that any traffic going to router 3 is going to be encrypted with Triple DES and md5 if it matches the access list GRB over IPSec where our access list is gonna say just match the GRE traffic from 1 to 3 now modifying this config and changing it over to a crypto profile is essentially going to have the a hundred percent identical effect it's just going to cut down on the number of commands and simplify what the overall syntax is going to be that we're using so next what we're going to do is in global config the define at the crypto ipsec profile will say that this is our tunnel profile and in the IPSec profile really the only thing that we need to define in the set option is what is the transform set so in this case the transforms it is going to be the same one that we used before which our transform set name is esp Triple DES md5 then we're going to go to our physical interface level and if we look at the config on there again we're going to remove the crypto map so we should see that this is going to cause the routing protocol adjacencies to go down and we can see the word debugging our phase 1 that's going to cause the tunnel to go down if we take a look at router 3 on the other side and show show IP ospf neighbors which was the protocol we were running over there we should see in about 10 seconds give or take that the adjacency is going to go down because of course now the tunnel is down if we look at the show crypto I camp si we could see that the tunnel tunnel is deleted eventually this other one is going to timeout as well but to speed that up let's go ahead and just say clear crypto si to delete the phase two and then clear crypto IC camp to delete the phase one now if we show crypto I see camp we can see that right now there's no phase one tunnel op okay the next change on router one is we're going to go to our tunnel interface and we're now going to apply if we show runs section profile we're now going to apply this ipsec profile that we named tunnel profile we say crypto ipsec profile or actually now we say tunnel protection tunnel protection IPSec and the profile name is tunnel profile okay if we now look at the show crypto ISO Camp si we can see that now we have a new security Association go into router 3 on router 3 likewise we should see the same thing so we have a new tunnel if we look at the show crypto IPSec si we see that we have an inbound security Association and we have an outbound security Association if we look at the packet counters here from the show crypto IPSec is a pipe include end cap or D cap we should see that this number is going to increase as we have our IGP keeper lives go out there as we have OSPF sending its updates if we look at the routing table we should see that once this routing protocol adjacency establishes that show IP ospf neighbors that we should be able to form the adjacency so let's go ahead and try sending packets out the link let's show IP route connected and we should see our tunnel interface here as up so let's ping 169 254 0 1 and on rutter 1 if we look at the show crypto IPSec si pipe include end cap or D cap we should see that this counter is gonna increment let's send a bunch of packets we can see it's incrementing as those pings are going across the tunnel so even though in this case on one side of the link we're using the crypto map on the other side of the link we're using the IPSec profile from the negotiation point of view and from the data plane packet level point of view there are a hundred percent identical but when we look at the config of router one it's much simpler because the only thing we need to say is that if you route traffic out that tunnel interface it's gonna be subject to this transform set which says to encrypt the traffic with Triple DES in this case and also to use md5 so let's look at the change here if we look at the show run interface tunnel and this is still a govt tunnel interface if we show interface tunnel 0 and look at the encapsulation says tunnel protocol and transport is GRE over IP if we look at the show crypto IPSec si we still see that the type of traffic being protected is the GRE packets between their interfaces same thing is going to be true on router 3 here show crypto IPSec I say we can see that it's still GRE that's going across here but let's go ahead and do the same thing on router 3 so let's say show run section profile on router 1 and we're going to get the crypto profile then on rudder threes physical link which is where we previously had the crypto map configured we're going to remove this and then on the tunnel interface we're gonna change this to the tunnel profile so a tunnel protection ipsec profile the name is the tunnel profile okay so we can see they've reformed their OSPF adjacency if we look at the show IP route OSPF we see the route to router ones loopback out here and as we look in the transit path let's take a look back at our topology here this these packets are gonna be going out to router threes physical interface they should be IPSec and then inside they're gonna be GRE so nothing has changed here in the packet format by moving the configuration from the crypto map to the profile it just means that it's a lot simpler from a configuration point of view and a management point of view that we don't have to worry about the other proxy ACL the only thing we need to do is just establish a basic tunnel apply the tunnel profile and then it's automatically going to encrypt all of the traffic that were sending out that particular interface now the other variation of this since we've now removed the crypto map we can actually go one step further and change this tunnel interface into what is known as a virtual tunnel interface a vti now the vti is going to have two different sub variations that we're gonna look at here one of them is called the static vti one of them is the dynamic vti which one we're using depends if we're doing land a land VPN or if we're using or if we're doing from a remote access for easy bpm in this example we're doing our land to land config so this is going to be considered a static vti static VT i just like a GRE tunnel is going to be a point-to-point link the only difference is that we're removing that additional GRE encapsulation overhead behind the scenes it's still going to be using the same type of logic as the GRE tunnel is with the crypto map that it's saying match all of the packets that are going out that interface as they go towards this particular destination and they're going to be subject to whatever the crypto profile is which again is defining our transform set now in later examples we'll be looking at the dynamic VT I the used in our remote access VPN s this is going to be used for easy VPN remote so it's just like a normal dial and VPN except it's using a virtual template interface as opposed to a dynamic crypto map now one of the advantages of this is that when we use the virtual template interface it means that each of the peers is going to be allocated a new virtual access interface in the routing table which means that the routing logic is going to be a little bit easier to deal with because we have an interface that's actually associated with the with the neighbors so we'll come back to this in more detail when we get to remote access but for example one of the things you could do with a a dynamic virtual tunnel interface would be to say when the user comes in and they log in based on their authentication assign them to a particular virtual tunnel interface and that tunnel interface could belong to a vrf or it could have gone based firewall applied to it or gonna have specific QoS options applied to it because now instead of having the crypto map that's kind of just a virtual representation of the IPSec interface we have an actual interface that we can go into interface mode and then apply normal interface configurations to it so behind the scenes logically it's the same as a dynamic crypto map but it's an it give us gives us an interface that we can actually make configuration changes to now for making the change from the current config to the vti the steps in phase one are identical so nothing is changing in ISO camp we still have our four tributes that we need to negotiate and in phase two we're going to be using the IPSec profile which is essentially what we already have up to this point now the difference is going to be with the static vti interface it's always going to be on there's no type of interesting traffic that needs to trigger the interface additionally there's not going to be any tunnel keeper lives it's going to be using the AIESEC camp phase one to keep a lives in order to determine whether the interface is still gonna stay up so this means that the tunnel is only going to come up into the routing table so it's only gonna have its line protocol come up if IPSec is actually successfully negotiated so what this means from a routing point of view is that the vti interface is going to be a little bit more accurate as in to end-to-end reach ability over the tunnel versus a static GRE tunnel that we're applying an IPSec profile to because with the GRE tunnel interface we're not sending any keeper lives the interface is just gonna always be up in the routing table as long as we have a route to the destination but that doesn't necessarily mean we can reach the destination if someone were to filter IP sick in the middle the GRE tunnel wouldn't know that however the VT I would know that because eventually when the phase 2 and phase 1 go to rekey or we use IC camp people lives they would figure out that they're unable to reach each other and then the tunnel would go down now as we compare this to the GRE tunnel they both support multicast and unicast routing so there's no change here with static VT I versus GRE one of the differences though is that with the VT I interface you cannot test gateway to Gateway connectivity so you can't ping between the routers over the tunnel interface with GRE you could but with the VT I it's just not as supportive feature so you have to ping through the router in order to do the testing with the VT I interface the proxy ACL is always going to be permit any with the GRE tunnel it depended based on what we defined in the crypto map or the case of the IPSec profile the phase 2 negotiation says that you will encrypt all GRE which is protocol number 47 now we'll see configuration wise for this this is very very straightforward it's only one command to change our GRE tunnel interface to a virtual tunnel interface to an IPSec vti and specifically when we take a look well when we take a look at the command line here if we show run at interface tunnel zero the only change is that on the tunnel we're changing from the tunnel mode GRE to X to the GRE IP we're changing from this to IPSec ipv4 so same thing on router one as well interface tunnel zero tunnel mode is IPSec ipv4 now if we clear crypto IPSec SAR actually just clear crypto si and clear crypto ice account so that's gonna rekey the tunnel we see now the tunnel line protocol state comes up this means that phase one and phase two negotiation worked and then we have our actual data plane traffic going over which in this case is just the OSPF keep alive so if we look at the routing table no change here it still looks like a normal tunnel interface if we go to send packets out no change in the data plane with the exception of we're removing some of the GRE overhead so if we could do packet capture in the middle and then decrypt that and compare the to the GRE tunnel we would see that the the packet size is going to be lower in the the packet header because now we have just the outer IP header and then the inner ESP header so we don't have an additional energy re patter if we look at the show crypto IPSec si we'll see that the difference between the previous tunnel and this one is the proxy ACL is now all traffic so essentially anything that routes up the tunnel interface is going to be subject to our transform set now in this case the transform set does need to be tunnel because we don't have an additional GRE header in order to do the tunnel encapsulation so again when we were doing the GRE over IPSec normally you want to run the the transform set in a transport mode because if you run it in tunnel mode you have three headers the original IP header the new GRE IP header and then the new ESP IP header in this case here we have the original IP header and then the new ESP IP at ur so we're skipping the GRE overhead but really the end result functionality is going to be the same that we can use this for dynamic routing as a point-to-point tunnel okay so let's look at our final configuration for this if we show run section crypto or tunnel actually I think that should be capital tunnel the final config for this is going to be pretty straightforward so let's take a look at this in notepad okay first we have the ISO camp policy so none of this is changing we have our transform set K transcript set says whatever the encryption protocol is whatever the authentication protocol is we have the IPSec profile that is essentially just referencing the transform set we then have the tunnel interface says this is the source this is the destination then the rest of our upper layer protocols for the tunnel so we haven't we're running IP on the tunnel we're running routing on the tunnel the tunnel mode is IPSec ipv4 and then we're calling the transform set okay technically we're calling the IPSec profile the IPSec profile is calling the the transform set so then this means in order to change this over to the other side really the only thing we need to do is just change what's the source and destination of the tunnel and then what is the the authentication information in this case would be the IP address of the the pre shared key for AIESEC app but this means that you don't need to worry about the order of the crypto map you don't need to worry about if there's multiple physical interfaces that you need to route out because we could also say here that the tunnel source this could be like a loopback interface then as long as the remote neighbor has a route to this loopback we would be able to send the traffic out any underlying physical interface without having to apply the crypto map on multiple places [Music]

Channel: Cisco Security

Views: 4,108

Keywords:

Id: lpJFemqmlk0

Length: 22min 47sec (1367 seconds)

Published: Wed Jan 17 2018