037 IPsec Verification Troubleshooting

[Music] in our next section we're gonna look at the verification and troubleshooting of the crypto map based landal and VPNs on iOS and a lot of the techniques that I'm gonna show here are also gonna carry over into the other variations of IPSec because again when you run into a problem with these cryptic and figs it's very very difficult to troubleshoot it based on looking at the show run output so we want to know what are the different debug commands and what are the different show commands besides the show run that we can use in order to try to narrow down what is the specific problem in the configuration now the reason why this is a problem is that there's so many different ways to make minor mistakes in the configuration well see as we get to some of the more complicated configs especially especially in remote access VPN s you may have upwards of a hundred plus lines of config just for one a particular VPN tunnel so there's so many different ways to make mistakes and the vast majority of them are gonna break your configuration to where the tunnel is a hundred percent non-functional so understanding how to do the verification is a must and understanding how to interpret the debug output is a must so let's talk about what are some of the different commands we can use first to do verification and troubleshooting and then we're going to take a look at this on the command line so the first one that we saw previously was the show crypto ice at camp sa this is going to show the phase one security Association which is the ISO Camp security Association and this should be in a QM Idol and have the status active where QM item here means that we have gone into quick mode quick mode means to move to the Phase two negotiation for IPSec now if we see that it is not QM idle and the debug that we're going to look at is either debug crypto iso camp or debug crypto KMI which is for the key management so from here this is going to show the step by step negotiation process this is one of the debug that I'm gonna walk through step by step here and show exactly what do they do pieces mean through the negotiation and how can we use this to figure out where exactly the problem is in the negotiation process and is it on the initiator or isn't on the responder because depending on which end of the connection you're looking at the sender or the receiver the debug output is going to be a little bit different here now the other thing for this debug is that if you have multiple tunnels at the same time and you don't want to see the debug for all of them you can set a debug condition that is going to filter the output to just a specific peer so let's say I'm on some tunnel head end that's got a hundred different tunnels on it and if you do bug crypto I see camp or debug crypto IPSec then you're probably just gonna crash the box so you may need to filter through this through a just a based on a specific Pure's address and then that's going to filter out any of the the non relevant output that you're trying to troubleshoot the next thing that we you would want to look at is is the authentication working you can tell this generally from the debug crypto ISO camp whether you're pre shared key or whether your certificates are working because that's going to be part of the phase 1 negotiation also we want to look at do the attributes match for the policy so when we look at this debug for crypto ice at Camp it's going to show the proposal exchange where the initiator says to the receiver I want to do this authentication this encryption this hashing this diffie-hellman group and then the responder is going to say I'll check that against my policies and then determine is this acceptable or is this rejected and the debug is going to clearly tell you are the atributes acceptable and if not it'll show specifically in the step-by-step process of which attribute is not acceptable or which one is rejected now if everything is working what we should see is that there is going to be one bidirectional security Association for the phase one ISO camp so we should see bi-directional UDP connectivity UDP 500 specifically between the initiator and the responder now for Phase two yet IPSec again we need to make sure that phase one is working first that phase one is active doesn't make sense to move on to any of these unless we checked phase 1 so once phase 1 is working we can look at the show crypto ipsec si and we should see that there is an inbound and an outbound security Association based on whatever particular transform set that we have we can also filter this based on the remote address this is going to show us our the packets getting encrypted and decrypted are they getting encapsulated in d capsulated this is going to help us to troubleshoot anything that is related to the data plane so let's say we have an ACL in the transit pack that's dropping ESP or that's a filtering traffic in just one direction we would be able to see our is the traffic going out but not coming back in that might be an indication of not necessarily a negotiation problem but a problem in the data plane now if the security Association doesn't establish at all then we would know that's a problem in negotiation another place where this could be a problem in negotiation in phase 2 would be with the proxy ACLs so if the endpoints do not agree that you are sending traffic from A to B and I'm supposed to send traffic from B back to a then they're not going to be able to form the phase 2's a so we can also see this if we look at the debug crypto IPSec that's going to show the negotiation of the phase 2's a the end result of this should be two unidirectional security associations for each proxy ACL entry so there's going to be an inbound SA and an outbound si which again is different than phase 1 phase one has a bi-directional UDP 500 connection Phase two is going to have two unidirectional connections so this means that if we're going through a stateful firewall we're coming from the outside back in we have an unsolicited connection that's going to be dropped unless we can get the firewall to either inspect the ESP sessions or we're poking a home manually with an ACL to say allow ESP or to allow aah so let's take a look back at our topology that we're using and in the previous example we had a land to land VPN that was set up between a router 1 and router 3 that was going between their loopback interfaces so on router 1 this was 151 one on router three this was 150 one three three we were using static crypto maps we were using pre-shared keys a pretty straightforward policy and we had connectivity over the tunnel between the two endpoints so now I've introduced some problems in the topology and without having to look at the show run output we're going to go through the step by step verification and see if we can figure out you know what commands do we need to look at and how do we interpret that output to figure out where specifically the problem is in the in the network so first let's start on router one and let's try to send traffic between the two endpoints so we're trying to get to the destination 151 33 and we're sourcing traffic from 151 one one and we can see the endpoints are unreachable so something is wrong with the tunnel but we don't know exactly where is it a problem in negotiation is it a problem in network address translation is it a problem in filtering from this output we can't really tell we just know that something is broken okay so the first thing that we may want to look at then is did the endpoints negotiate phase one so let's look at the show crypto I see camp si now it says that the si is in quick mode idle State so it looks like the negotiation was correct let's go ahead and look at the phase 2's a show crypto IPSec si and we see that we have an inbound security Association and we have an outbound security Association so this tells us at least there was negotiation that happened previously for this tunnel but for whatever reason you know something changed in the in the tunnel is no longer working so before trying to troubleshoot based on this particular output as it stands what might be a good idea is to delete the state for the phase two si delete the state for the phase one si and see if we can refresh both of them individually because what may have happened it's possible that the tunnel was working at one point somebody changed something and broke it but we're not actually going to know that until the tunnel goes to rekey because when we look at the output here of the security associations it says there's still fifteen hundred and fifty-eight seconds left before we rekey or this amount of data transfer and if we look at the show crypto I see camp s a detail we can also see what is the lifetime of this si so this has almost 24 hours left before it's going to rekey so we don't want to have to wait a day to figure out you know is there a problem in negotiation so let's say clear crypto si that's going to delete to the Phase two IPSec si and let's clear crypto clear crypto ic-cap okay that's gonna delete the phase one si then of course we can do it based on specific connection number this is going to be if we have more than one tunnel currently active so now let's look at the show crypto I see camp security Association right now it says that there's no state because this was was deleted manually so eventually this is going to age out and leave that table if we look at the show crypto IPSec si we see that there is no longer an inbound security Association nor is there an outbound security Association so basically right now the tunnel has been deleted so let's go ahead and do the pings again and see if we can get phase one and/or Phase two to establish so again phase one verification show crypto I see camp si says that there's no state still okay this means that this is definitely not a problem or at least not up to this point it's not a problem with anything that is related to Phase two now it's not necessarily to say that there's not a problem phase two you but we haven't gotten to that point to even figure that out yet because the Phase two negotiation won't occur until I see camp goes into quick mode idle so we have to troubleshoot up through phase one now so the way that we're going to do this is going to be to look at the debug crypto ic-cap okay let's make sure that we're logging to the console logging console and logging is on okay so we do the ping again ping 151 33 from 151 101 we should see that router one attempts to form the tunnel because remember with the crypto map this is basically a dial on demand connection it says look at the packet that we're generating it's going out an interface with a crypto map if it matches the condition of the crypto map then we're going to start the aiesec amp negotiation now in this case here we see that there's no output from the debug at all this means that for some reason the the dial on demand did not trigger on the crypto map okay there could be a couple different reasons for this it could be as simple as the crypto map is not applied it could be that the access list is not applied to the crypto map where the access list is matching the wrong thing so let's look at the the crypto map configuration let's say show crypto map the crypto map is applied on gig 0 0 which is our outbound interface and it says the exes list is going to be matching traffic coming from 151 1 1 going to 151 2 3 3 so it should theoretically be triggering the connection but for some reason it's not so what other option here is potentially involved in the crypto config ok remember the two things that I mentioned that are independent of crypto that we still need to make sure that are working one is the routing process and one is the NAT process because encryption happens after routing succeeds and encryption happens after network address translation succeeds so before looking at the crypto config probably what what we may want to have done is just look at do we have a route to the destination which in this case we don't so something is wrong either with our static routing or something is wrong with our dynamic routing let's check the same thing on the other and other end does router 3 this router 3 have a route back to router 1 which it doesn't now in the previous example these loop backs were advertised into each RP and they were learning their endpoints dynamically through this IGP but in most designs this is not really going to be the case because you're probably forming the IPSec tunnel over a public network like the Internet and the sources and destinations of the traffic in the tunnel is probably private addressing like the 10 network or the 192 168 network so this is not going to be something that you could dynamically learn over the tunnel using a crypto map now we'll see later with other designs like the vti the virtual tunnel interface or a GRE tunnel or a dmvpn we can run dynamic routing over those but the vast majority of cases that we are using crypto Maps we're simply going to have to do static routing now the device is in the middle like the aasa' in this case it does not need a route to the loopback of router 3 and it does not need a route to the loopback of router 1 the reason why is that when packet is sourced packets are source from 151 1 1 and they're going to 151 3 3 this is then going to get encapsulated inside of ESP and there's going to be another IP header that the source is going to be the public address of router 1 so now the source becomes 136 1 18.1 and the destination becomes 136 138 38.3 so we're assuming in this case that the a si in the middle already has a route to those subnets because from the ASA's perspective these are directly connected so always make sure that you selves the routing process first because it's completely independent of crypto both from the initiator and the responder so on router 1 we would need to make sure that we have a route to 150 133 and we could simply say point that out the gig interface okay under normal circumstances you would not want to do this because of the way that proxy ARP would have to resolve this but this is a special case here because we're essentially just pointing it towards the interface with the crypto map applied now no one on the other end actually has to know this destination we just need to get the traffic to route out the gig interface in order to trigger the crypto map process and again this has to do with the issue that the legacy crypto map config is essentially a dial on demand VPN okay so we're simply doing static routing saying that the endpoints of the tunnel are reachable out those connected lengths so now when we look to the routing lookup router 3 knows how to get to one's loopback and router one should know how to get to router 3 we'll see that this is also going to be the case when we're dealing with remote access VPN s whether it's easy VPN or whether it's as a cell VPN we need to make sure that when the clients come in and terminate remote access that we have routing information in order to go back to them so whether this is static routing or whether this is dynamically through reverse route injection or it could be something like network extension mode in the case of ez VPN remote but still the point remains that routing has to be solved before the crypto processes so they're completely independent options here in the network design ok so now that we have the route let's go ahead and try this again if we look at the show debug we're still debugging phase one so let's try our ping let's see is this going to initiate the process now which it is ok so let's start at the top here and work our way down ok let's undo bug this first thing it says is that we are creating a new peer structure for one 36.1 38.3 the peers port is 500 and notice this is from AIESEC app basically what this is telling us here is that we found what is the destination of the other tunnel the destination of the tunnel is 3 I'm using port 500 that's for our IC camp and we're gonna send them a UDP request okay so this at least means that the crypto map is applied that routing is working and that whatever access list we have in the crypto map is triggered against this particular type of traffic okay so now we know we're starting the negotiation okay what we want to do here is see that we have a response back in from router three now from the initiator of the tunnel we'll see that the output of the debug is going to be different than the receiver or the responder of the tunnel now from the initiator there's not really much that you can tell when you're looking at a failure in negotiation other than this output here it says processing of informational mode failed with the peer with this address this doesn't tell us what the problem is it's more just saying that there was a problem in negotiation so to figure out where exactly the problem was we need to look at the other side we need to look at the receiver router three and look at the same debug on its side which is going to be again to debug crypto ic-cap again let's make sure we're logging to the console and we're logging to the console at level seven okay on router 1 let's go ahead and send those pings again and on router three let's look at the receiving of this so on router three it says we received a packet in from router one destination port was 500 the source port was 500 and we're gonna start a new security Association so what does this tell us here was successful it means that at a minimum the traffic was able to route from router 1 to 3 so we now know that UDP 500 does not have a transport problem getting from router 1 to 3 now if router 1 was starting the session but router 3 never received it we may want to look at the middle and see is there an access list dropping port 500 is the reveal NaCl is there some sort of IPS sensor in the middle that's dropping to traffic when in this case router 3 did receive the the negotiation request so the transport from one to three is fine okay next it says we are going to start the proposal process so we're scanning the profiles we're checking against our locally configured policies so this means that router one has now proposed that it would like to use Triple DES encryption md5 hash diffie-hellman Group five do pre shared authentication have the S a lifetime in seconds and then this is the specific value okay now we can see it says there is a problem here because the encryption algorithm does not match the policy and the attributes are not acceptable okay this is really the final output that you're looking for here if we have multiple policies that we're checking against but for some reason the policy does not match the router where the a si is always going to end in this output that says the attributes' are not acceptable for the phase one policy this tells us that either there's a problem in the encryption the authentication the hashing or the difficult group now specifically what which one the problem is it should just tell us right here says that the encryption algorithm does not match the policy okay so let's look at what is is our policy here and how does that compare with router ones so my router one let's say show crypto I see camp policy and same thing on router three show crypto I see camp policy router one says I'm doing Triple DES encryption router three says - AES the rest of the attributes those are all the same md5 pre-shared key diffie-hellman group five now in this case it's pretty obvious that this is the problem because there's only one policy on both sides but in a normal design you're probably going to have a lot of policies and then you would have to Trek track this debug output all the way down look at each of the proposals one by one and then figure out where exactly the atributes do not match in the the policy so here let's go ahead and change Rao one so that it matches what router 3 is using in the policy let's say show run section I so camp and this should be here under the ICM policy we want the encryption not to be tripled as we want it to be AES ok let's do the debug again on both sides to bug crypto I see camp debug crypto I so camp and make sure we're logging logging to the console now in a real design you normally would not want to log this to the console you probably want to send it to the buffer and then show log two to sort through it there because you can get into a case where this output or this debug just hashes over and over and over and you can basically lock yourself out of the the console so be careful with that but here in this case there's really no other traffic so it's not a problem ok so let's do the ping let's see now what happens on router 1 router 1 it said and it goes by pretty fast there you have to pretty much know exactly what to look for router once said the attributes are acceptable ok this means that they exchanged the policy so they did the IC camp proposal and they agreed on all of the attributes they agreed they're gonna do a EES 128mb 5 hash diffie-hellman group 5 in pre shared authentication now once they have done this and agreed on the attributes the next step is that they actually do the authentication so if they're doing pretty shirt keys next thing they would do is to check the passwords if they're doing PKI they would check the certificates exchange their public private key pairs and then or exchange their certificates I should say and then check against the trust point to see whether the certificate is valid now whether this has completed or not we should be able to see this by looking at the show crypto I see camp si still does not say qmi although there's something else wrong here if we look at the rest of the output let's see if we can figure out what happened after we did the proposal so the attributes were acceptable we should get to the next process where it says we're gonna do the authentication and it says we're gonna do pre shared authentication and we're doing main mode key exchange this is basically where we're trying to authenticate but you can see that it's attempting multiple times so this basically says there's a problem in authentication but you can see from the debug output it's not very straightforward to figure out that's with the cases you have to know exactly in the process and where does the authentication happen and if it has a problem what do you not see and what do you see so on the initiator here it basically says we go into main mode key exchange and then we cannot proceed beyond this now the output will be a little bit different depending on if you're using pre-shared keys versus certificates in the case of pre-shared keys what you want to look at is on the receiver and the receiver should have this output that says and it's not a very straightforward not a very straightforward output let's send the packets again this one here it says let me undo bug crypto I see camp bad message the i ke message from router one has failed its sanity check or is malformed what this actually means is that the message came in it tried to authenticate it and it couldn't now it doesn't know is it because there's a problem in the passwords or is it because someone intercepted the packet and change it or there was an actual transmission corruption somewhere in the transit path because what the authentication is doing is basically the integrity checking to make sure the person that initiated the packet didn't have someone make any changes in the other transit path because ultimately the password that they have that they have configured the pre-shared key they're not actually exchanging the password it's not something that's sent in clear text to say your password Cisco my password Cisco let's authenticate it's going to be some hash to result of that and they compare their own local result to the the packet that's coming inbound so at this point we know the the we know that the the the policy exchange the proposal exchange was good but now there's a problem in the authentication so let's look at the show crypto I used to camp key this show is simply what is going to be their pre sure key so router ones using the password cisco router 3 is using the password cisco but the problem is this is case sensitive so lower case cisco is not the same is capital so let's say show run section crypto and we need to change that okay this should be uppercase okay so next let's do our debug again debug crypto I see camp and let's now try initiating the session again okay still no connectivity but let's look at the show crypto I see campus a hey now we got two QM idol this means what now means phase one was a hundred percent correct so the proposal process for those four tributes was good the authentication was good now we move on to phase two so we know at least that there's no routing problem between them there's no problem with the crypto map application because it's initiating the connection and we know that there's no problem in the phase one negotiation so now we would want to check on the receiving side does it also have the IC campus a which it should because it's a bi-directional security Association and then we're gonna check what's going on with the Phase two policy so on router three let's look at the show crypto I see camp sa says QM Idol if we also look at the debug up to bug output here we should see that okay it says we're doing the pre shirt authentication and the end result is that the sa authentication status is authenticated so it means that phase one is fine okay now they are going and now they are going after the okay after the authentication happens now we're going to go into a quick mode so it should say we're at quick mode idle that means phase one is complete we're now going to go to the IPSec negotiation so this is our phase two negotiation so we can see now router one is proposing to router three do you want to run es pas in a tunnel mode and also do sha authentication these attributes are acceptable so it means that the transform set that they both have configured in the crypto map is equal okay now they're going to go on to the next step which is to exchange their proxy identities proxy identities are the ACL it says for some reason now the IP set policy invalidated the proposal now what error 32 means you know we don't really know some of this stuff is only tak would be able to figure out what exactly the errors mean but this tells us at least we now know there's some problem with the phase 2 policy phase 2 security Association probably is not not acceptable so what we need to look at next is the debug crypto IPSec because something's wrong with phase 2 now it's not a phase 1 problem anymore debug crypto IPSec okay let's send the packets again okay on router 3 the receiver we get to the IPSec proposal and again router 1 says do you want to run a es es PA es with a key length of 128 do you want to run sha and do you want this si lifetime and tunnel mode ok router 3 says yes that's fine that's what I have configured also ok now we go to exchange the proxy identities so router 3 is saying that this is my source of the tunnel the tunnel is going to go to router 1 my local proxy is 151 3 3 the destination is 151 1 1 this is basically that access list that we have configured in the transform set under this though it says that the proxy identities are not supported ok notice this one here this is an IPSec debug this is not an ISO Camp debug what this means is that there's something wrong with the access list between the two of them so if we now look at the show crypto map show crypto map says that for the peer router 3 the proxy ACL is traffic from 151 one one going to 151 33 so again if we look at our diagram when a router one's going that way it's saying the source should be 151 1 1 the destination should be 151 3 3 okay this is for router ones outbound si4 router 3 s outbound si the source is going to be 151 3 3 and the destination is going to be 150 1 1 1 so if we look at on a router 3 and look at its access list what's the issue here router 3 is saying that the XS list is actually the same as router ones so the problem is that when we were configuring this basically the same ACL got pasted in which should have actually been at the opposite it should have been that the source was router threes loopback and the destination was router once and again from the output of the debug here we can tell that if the proxy ACLs or the proxy identities do not match then that is going to invalidate the phase 2 policy so they will not be able to form the tunnel if they do not agree on what are that what is the traffic's that is supposed to go inside the tunnel ok so on router 3 let's go ahead and fix that ACL let's look at the show run section access list and basically this should be opposite so let's say no permit that and per minute the otherwise source is going to be 150 133 destination 151 1 1 okay let's try this again now so from router three let's look at now the debug all right let's show debug debug crypto IPSec and initiate the traffic from router one again now we don't need to look at the debug crypto ISO camp because the phase one proposal already went to quick mode idle so we know that it's not a problem with ISO camp so let's see now did they agree on the ACL so it says the proposal had a proxy match okay this means that they do agree on what the access lists should say now you could see also it lists the protocol the source port in the destination port you can get more specific in these access lists and say not only what's the source of the traffic what's the destination but I could say that protocol is TCP the source port is any the destination port is 80 so that then my only my web traffic would go over the tunnel but we can see here from this output in the debug this is specifically where they exchanged that so the ACL entries have to be a hundred percent mirror image of each other otherwise it's not going to accept this okay so now it should say that we're actually going to create the security Association it also tells us what is the protocol protocol 50 here means that it is esp if this was authentication header aah that would say protocol 51 we generate the SPI which again is like our sequence number and there's going to be one that is for inbound and outbound so this is the destination router 3 this is our inbound sa destination router 1 this is our outbound SA so there's two unidirectional essays that have now been created ok so now let's look at on router 1 did the traffic get through No so still something is going on with the tunnel but we're getting closer if we look at the show crypto IPSec si what do we want to check here do we have an inbound si and do we have an outbound si yes we do for both so this means that negotiation was fine so a phase-one negotiation was good phase 2 negotiation was good and we formed the tunnels and but we're still not able to send traffic over it what else could be involved with this so let's think about what specifically would the traffic flow be so the first step was that router one sent UDP 500 and router 3 returned it okay that is the iso kemp si that's bi-directional then router 1 sent out the ESP request so this is our IPSec essay and then router 3 sent its own request for the IPSec si okay we're using ESP ESP is again IP protocol number 50 now we know that UDP didn't did not have a transport problem getting there because if it did router 3 would not have received the negotiation to begin with but what about protocol number 50 now we could go of course to all of the devices in the transit path like look at the switch here layer to make sure it's not dropping protocol 50 go to the a si make sure that it's not dropping it but one thing that we can do to kind of narrow this down a little bit further would be to look at the counters for the IPSec si so let's say show crypto IPSec is a pipe include and we want to look at just the end cap and D cap let's say end cap pipe D cap and let's look at this on both sides okay it says and router1 we encapsulated seven packets out the tunnel they got encrypted and they got hashed on router three we D capsulated those packets they came in bound we decrypted him and we digested them we then encapsulated seven of our own packets they got encrypted they got in hashed but on router one didn't receive it back so what does this mean them means that the packets were able to go this way but then somewhere on the return they got dropped these indications in the counters normally means that it's a problem in the data plane so some something is getting filtered in the transit path now if we were to look at the a si let's go to a si four which is the one in the middle and let's turn logging on logging on and logging to the console at level seven and on router one let's try to actually send the packets a si says I'm denying inbound protocol number fifty coming from router three going to router one which in this case is our ESP now the reason why if we look at the show name if and the link that is connected to router one this is our inside interface this is security level 100 the outside interface that's going to router three that is security level zero so as we know from the basic stateful filter of the a si traffic can go from a higher security level to low and then return but traffic cannot come unsolicited from a lower security level to a higher security level and this is the key point that I was trying to make about the IPSec ASAE's being two unidirectional essays so it's not a bi-directional request of response it's a response from one side on a response from the other side and normally the stateful firewalls in the middle are not going to be able to deal with us so there's a couple different ways that we could fix this problem one would just be to go to the a SA and say don't deny protocol 50 so we could do something like this we could say access list outside in permit ESP any any and access group outside in in interface whatever that is interface VLAN 38 okay now on router 1 if we send the pings we could see now the traffic is going to row ok so let's say repeat 100 packets if we look at our counters now for the endcap and d-cap we should see that these are going to be pretty close to each other okay so this is one simple solution that we're just saying don't filter ESP packets as they come in from the outside but what's the potential problem with this now we now have an unsolicited hole in the outbound or the outside interface so we don't know if these ESP packets are a response to a VPN on the inside or it's just someone randomly send a traffic that's ESP through the firewall so this might not be the the best solution for it yeah another better solution might be to say well let's get the a SA to actually inspect the packets so as long as the traffic comes from the inside and is initiated by router one then we can inspect the ESP and then allow the return flow to come back in so let's remove the access list on the interface and instead let's say show run policy map we're going to go to our global policy inspection default and say we're going to inspect IPSec pass through IP say pastor here means that we're going to try to do a stateful inspection for ESP and for a H then if we wanted to you a specific inspection class this is where you could change the individual options for ESP or aah like the individual connection limits the per host limits but in this case I'm just gonna leave them as the defaults so now if we look at the show connection detail on the a SA and on router one let's clear crypto sa that's gonna delete our phase two sa and let's say clear crypto I see camp that's gonna delete our phase one sa then lets reinitiate the tunnel so paying 150 one three three from 150 one one one now if we look at on the a si and look at those connections we should see three different connections we have the bi-directional I see camp flow which again is UDP five hundred and then we have the two unidirectional ESP flows so one of them from one two three the other one from three back to one but the difference is now these are being caught by the inspection engine so we're able now to send traffic from the inside out we should also be able to send traffic from the outside the outside back in which we can now the main difference is going to be here between inspecting the IPSec versus having the the explicit permit in the ACL is that with the inspection the tunnel is now only going to work if we initiate it from the inside interface so in this particular case when we look at the the topology here if we go to router one and ping three the response is going to come in and that's fine once the tunnel is open then router three can ping router one and get a response but if we were to try to initiate the tunnel from router three inbound the a si is going to say well wait a minute you're coming from one you're coming from zero you're trying to get to 100 I'm not going to allow flow to go through because you're going low security too high and remember the inspection engine takes precedence over the the security level so it's basically an exception saying if the connections there allow it in but in this case the connection doesn't establish unless we go that direction first and we could see this here if we were to go to router one and router three and let's delete the connection state let's say clear crypto iso camp clear crypto SI and we'll do this on both sides clear crypto iso camp clear crypto SI then let's turn logging on on the a si again logging on login console at seven and we have router three try to send packets from the outside in and actually what I need to do is delete those connections on the a si so let's do that again let's clear the essays clear crypto iso camp clear crypto sa show crypto IC camp sa okay it says phase one is deleted show crypto IPSec si we should see that there's no inbound there's no app on si so all the state is now delete it for the tunnel on the a si if we show connection detail these are still waiting to timeout so basically I need to clear all these connections clear local hosts all show connection detail okay so now the connections are deleted let's see from router three from the outside in now this traffic is gonna be is gonna get dropped so if we look at the a si the a si is now saying you're trying to send UDP 500 from the outside interface to the inside and since this is not it does not have an ACL exception you're trying to go low security - hi I'm not gonna allow this inbound so really whether this is a valid solution or not really depends on what requirements are if the requirements are we're talking about within the scope of the lab exam specifically if the requirements are that we need to go to router three and ping router ones loopback well no this is not a valid solution then because if the tunnel is not initially up the a si is gonna drop the packets as they come inbound but if we go to router one and do the initiation then then it's gonna be fine now we'll see with other types of tunnels if we were to do a GRE tunnel and then run IPSec on top of it or if we were to run a virtual tunnel interface or if we were to do something like dmvpn these tunnels normally would not run into this type of problem because they're not dial on-demand where or if they are dial in demand like in the case of dmvpn there's always going to be some type of interesting traffic like our routing protocol keep allies that are going to initiate the tunnel try to initiate the tunnel from both directions at the same time but with the crypto map this is one of the limitations that we run into that it's it is dial on demand and you might not be able to initiate it from both sides of the connection [Music]

Channel: Cisco Security

Views: 27,162

Rating: 4.9534883 out of 5

Keywords:

Id: v-DeG_LOu7c

Length: 48min 47sec (2927 seconds)

Published: Wed Jan 17 2018