S2E3_IPSEC VPN - MM_WAIT_MSG4 - How to troubleshoot? (IPSEC VPN)

hello and welcome back first of all I would like to thank you for supporting me in doing this guitar I want you to know that I always try to bring accurate and clear information to you the sole purpose of me creating these videos is to help you understand those concepts that you always wanted to learn at the end of this video if you find it helpful please do like if you are new to this what can be the possible reasons that you see your a SS to get a member witnesses for and how can you fix it let's get started before we go into why we are at mmm wait mess with fall let's go little back and talk about what information is shared in messes three and four first let let's understand what does it mean mm wait messes for so we have an initiator we have a responder right initiator sends first messes after sending first messes now this guy he can wait for messes too so initiator can be in a state mmm wait messes too after sending messes one he can be on mmm wait messes to state the responder receives messes one and sends back messes - so this is - its sent after sending message to the responder can be on his stays now it has sent message - so it is waiting for message three that's what will be the state's mmm wait message three initiator has received a message to an initiator will now send message three so after sending message three initiator can be in stays it will wait for message for mm wait message for so now initiator has sent message three and it's waiting for reply if it stays here at mmm witnesses for if it just stays here that means it has not received message for back before we talked about why it is at mm wait message for let's understand what information it has sent in message three and what what are they going to do next I have already done another video on what information is shared in message 3 you know a quick recap so in message 3 we send key exchange payload in key exchange payload it sends diffie-hellman public key next thing we sent is non-spell owed the next thing is NAT D so net T is your net discovery these three things are sent in messes three now about the possibilities what is the possibility that initiator is stuck at mmm wait message for why it is stuck at mmm wait message for any thoughts is it possible that some other device here maybe a router is blocking this message 3 this message 3 is not reaching to the responder is it possible that someone here is blocking it well if your answer is yes let's see these all messages 1 2 3 & 4 they are exchanged on UDP port 500 if this router is blocking UDP port 500 then how was first message allowed so if you are saying that message third was blocked by any device in between because the router blocked UDP 500 how did it allow the first message right if the router was blocking it it would have blocked the first message as well it means this is not correct the router there is no other device blocking it maybe the third packet is reaching here the responder is even replying back sending the fourth message but the fourth message is not getting back to us it's being dropped somewhere here and what are the chances for it to be dropped here I would say zero because again fourth messages also on European Droid so if there is any device in between that is locking you to be 500 it would have also blocked message number two but that did not happen so that means there is no device that can block messes for so are we good here does it make sense to you that messes one and tool is allowed and then third and fourth is being blocked because some device is blocking you to be 500 when I'm telling you that all these four messages they are exchanged on European wondered so if third packet is getting blocked that means first was also being blocked if first message was being blocked how did we reach up to third message right if the first packet was being blocked then this would have never got any forward right initiator responder initiator sends first message responder sent second message initiator then sends third meses and goes into a state mmm wait method for hit third message it sends key exchange payload nonce payload and NAT D let's say the responder has received third packet now I need your attention here a complete attention this is very important thing so listen to me carefully if the responder has received third meses what will it do now it will send forth message back right if the responder successfully sends forth messes back now what will the responder do after sending forth messes it will wait for fifth messes and it will also start preparing for sixth packet if you remember after sending fourth packet both initiator and responder they do some calculations independently so let's say responder has successfully sent forth messes it came back here initiator received fourth messes now they both will be doing some calculation on their end independently what will be that calculation initiator here will generate session keys and responder will also generate its session keys and they both will be doing this thing independently so the moment responder sends forth message it will start creating session keys the moment initiator receives forth messes it will start creating session keys how these session keys are generated to generate session keys first of all they both calculate diffie-hellman shared secret so initiated calculate Steffie Hellman shared secret on initiator and in the responder calculates the filmin shared secret don't respond decide once diffie-hellman shared secret is calculated now they will create session keys so to calculate session key the formula will be something like nonce definite meant shared secret and the pre shared key so same thing the responder uses here so it uses nonce diffie-hellman shared secret and preciate key so after sending 1 2 3 & 4 messages they will start preparing for 5th and 6 meses or decides they will do it the moment responder has sent forth messes responder will start preparing session keys to prepare session keys we need diffie-hellman shared secret so they will first calculate difficult man shared secret and then using the decree and shared secret nonce and depreciate key they will calculate session key IDs so if you notice ppreciate key is necessary here right the responder has to know what is the ppreciate key same way the initiator needs to know what is the ppreciate key right where is the ppreciate key stored it's in the configuration on both sides they both sides they have configured ppreciate key right so they need to pick the ppreciate key from the configuration on the SA and in what part of the configuration do we store ppreciate key where do we you know enter ppreciate in the config part initiator responder on the preciate keys are stored internal groups so let's say initiators IP addresses 1.1.1 and the responders IP addresses to dot-to-dot to the preciate keys are stored internal groups so an initiator side I'm going to give it a different color the initiator responder so the initiator will have a channel group with the name of responder and in this tunnel group it will have ppreciate key configured in the IPSec attributes of terminal group good responder will also have eternal group and appreciate you configured here in the IPSec attributes let's say I've purposefully chosen that depreciate keys are different right I want to show you something so let's assume initiator has sent first packet responder had sent the second one back initiator has now sent the third message the responder should reply with the fourth packet they should go but before replying before sending the fourth meses responder because after sending if the responder sends forth messes what is the next step that it has to do the next step will be the responder has to calculate session keys and to calculate session keys it needs ppreciate key it needs to locate the ppreciate key right and to locate the ppreciate key it has to first find the channel group once it finds the tunnel group then only it can locate the appreciate key it sends the fourth message it has to calculate the session keys to calculate the session keys it needs to find ppreciate key to find ppreciate key it should find a tunnel group right if the responder finds that the pre-shared key is not configured there is no preciate key configured here it knows that it is you know we are trying to establish VPN with 1.1.1 and it finds that there is a tunnel group with the name one dot one dot one dot one and it's trying to locate the preciate key but the preciate key has not been configured so the responder does this thing before actually sending forth messes because it knows if I send forth messes then I will have to create session keys to create session keys I need to locate preciate key to locate preciate key I first need to internal group because speciate key will be in the tunnel group so before he means sending forth messes it says let me first see if I have a pre shared key because if I'm done sending forth message then I will need to calculate session keys so let me first see if pre shared key has been configured or not so it checks it locates the tunnel group the tunnel group is who is sending me these packets who sent me first packet who sent me third packet so third packet came from wonder 1.1.1 so it looks for you know the tunnel group with that one dot one dot one dot one so if it finds the tunnel group then it checks does the tunnel group have appreciate key has the pre shared key being configured in the tunnel group safe preciate key has been configured then it will of course reply back but if pre shared key has not been configured in the turnin group it will not send forth messes this fourth packet will not be sent because after sending fourth packet what will it do it cannot proceed further with the session keys because there is no preciate key configured then how will you tell the initiator that I cannot proceed further if the fourth packet has already left then how will it again tell the initiator that hey bro I don't have appreciate key configured so I will not be able to calculate my session keys so it does that you know it checks that thing in advanced do I have appreciate key considered or see it's not checking if the preciate key matches with the appreciate key of initiator or not all it is doing is just checking do I have appreciate key configure or not so that I can calculate my session keys they are not going to compare the preciate key yet right they're not sharing preciate key in fourth packet neither in third back at the initiator sent appreciate key so appreciate key has not been shared yet one two three four these messages they will not share preciate key and even it is not sending forth masses so it could be because reciate key has not been configured if it is incorrectly configured because on that side we have cisco and on this side we have one two three four five so they are different but they should be same but at this point of time they they're not checking if the preciate key is a match or not all it needs to know do I have appreciate he can figure if the preciate key has not been configured here then it will not send forth messes because after sending it will not be able to perform the tasks that it has to do after sending the fourth message which is to create session keys it will not be able to proceed further so the best step here is let's not let me not send the forth messes that way initiator will know that something is wrong correct otherwise how will initiate or come to know if let's say responder doesn't do this thing it doesn't check if preciate kids configured here or not and it sends the forth messes then how will the initiator come to know that if there is a problem there or not after sending forth messes then he will try to allocate appreciate key and we will not find preciate key because it's not there it will not be able to generate session keys so it's a waste waste of our faults why did he even send forth messes when you were not able to proceed you should all check this thing on first and right before you send forth messes but that's why it is stopping forth messes right here that I will not send forth messes though it has enough information to send forth messes but it knows that if I send forth messes I do not have enough information to proceed further in calculation of session keys so if ppreciate key is not configured forth messes will not be sent another reason can be if tunnel group is itself not configured right because ppreciate key is configured internal group so if Tunnel group is not there it can't find appreciate key for that right so there could be two possible reasons on the responder end that one the responder does not have Tunnel group configured and the second reason can be the tunnel group does not have preciate key configured at this moment it does not check your key is same or not all it cares about is if ppreciate he has been configured or not I mean if preciate key is different that will be a problem at later point of time when they actually compare the preciate key in fifth and sixth messes but as of now ppreciate key being different is not a problem as long as it is configured in the tunnel group the two regions initiator responder initiator has sent first meses responder has sent second messenger has sent third message and it went into a state among wet mess with wall that means it's waiting for message for to be received the responder is not sending masses for because it does not have enough information to proceed after sending message for that means after sending message for what in from what will be the responder doing it will be generating session keys to generate session keys the responder needs ppreciate key to find preciate key it needs the tunnel group right so if Tunnel group is not there it will not send forth message if the tunnel group is there and but depreciate key has not been configured it will not send forth messes if preciate tunnel group is there if Tunnel group is there and preciate key has configured even if it is different it will not care it will send forth messes we get is because it has located both sternal group and appreciate key so it can continue generating session keys right so these are the possible reasons for your initiator to stay at mmm wait message for so we are going to use this topology here where I have two sites let's say I'm you know given them some company's name so these two sites we have VPN between they say Si and this one here the history devices will have VPN connectivity the IP addresses are same as they are written 6 to 7 dot one dot 13.1 for two and they say say has a public IP of - da - da - da - I've already done the configuration and I'm going back I'm going to PC one and doing a ping - PC - let's see what's the PC two IP addresses so 1 1968 10.1 go back to PC 1 192 168 10.1 I'm doing a continuous ping so that I can see what what happens on the SA so it's time out let's go here on a si 1 and check the channel status chakra price again best say because I have already done this configuration and I wanted to you know reproduce the problem and show it to you so which right there the role is initiator and state is state at mmm wait message for stuck at mmm wait message for because I'm 5 continuous Pink's going on so you are continuously seeing this if I stop the ping you will no longer see that state there so will this go so it's gone now why do we have this the initiator says M I am waiting for mess for the initiator has sent why will it wait for message for because the initiator had sent 3rd messes to the responder and now it is waiting for 4th messes why it is not getting 4th messes back because there is some problem on responder end either it does not have appreciate key configured or it doesn't have a kernel go you you may be thinking that I'm just saying this right where is the proof this is me telling that if you see a man wait masses for that means these are the problems you do not have either Tunnel group or do you not have preciate ki so but how do we know right how do we know by ourself so you can do t bux let's do some debugs where do we do d bugs so we will do the bugs who is where do you think is the problem this guy has sent message three initiator and sent message three it is waiting for message for so you will not find anything in d bugs here because this guy is waiting for message for right the problem is on the end who is not sending message for so we'll go to the responder end and we'll do D bugs there so I met responder and now a sc2 is the responder so let's apply some D bugs here D value that I'm going to apply will be conditional D bugs well it's a debug crypto condition pure and pure IP so my PRI P is let's go back here and do show IP here I've here 63 113 140 to come back to is they to paste the priv here so apply the conditional D bugs and that's what you need to do in your life in moment if you have to do debug for one particular tunnel that's how you'll do it so you'll say debug crypto condition pierre-pierre IP and then you'll say debug twice chem 128 128 level gets enough information for you to figure out what is the problem I go back to PC one now and start the ping again so yeah one or two ping should be enough I'm just going to stop them and go back and look at the D bugs so it's right there in front of you it says you can read it no pre-shared key configure it for group cannot find fella channel group first it says no preciate key configured for the group it says I found the group but there is no appreciate he configured and then it says cannot find a valid ton group so valid tunnel group will be when when there is a valid preciate he configured right so this device has a channel group either a turn-on group missing or appreciate came missing so most likely it looks like it it says no appreciate key configured that means appreciate key is missing so let's check that out so we are looking for a tunnel group whose name should be this IP right say sure internal group and the name sternal group is configured but you see there is an appreciate kl8 so we have appreciate K missing so let me just quickly configure the preciate key so I say configure config t go into the channel of config so the preciate key will be in IPSec attributes and you have to say Ike we won pre-shared key you if you remember how will you remember depreciate key on a SI one is Cisco one two three and appreciate given a si - I'm going to configure it different let's just school one two three so I can figure the different pre shared key but I have configured appreciate keep right so pre-shared keys are different now we see what happens I'm just going to end go to PC one start the ping once again still say is timeout go to USA one say show crypto ice again best say it's no longer at mmm wait message for now with salmon wait message six right so we have get past that mmm wait message for by configuring a valid to shade key I'm not going to show you the debugger of a say too because those debug czar for a moon wid message six so I don't want you to get confuse at at this moment how did we fix someone wait message for there was appreciate key you know missing in the tunnel group configuration another reason I told you that if there is no valid tunnel group so I'm going to go back to the air set to and delete the tunnel group and then we reproduce the problem once again well we have a tunnel group configured sure internal group this is the tunnel group I'm going to delete it 60 now turn our group IPSec attributes and then now internal group this there should be no turned up now tryna group config is cleared the continuous ping is still going on so go to a state to sorry ass day one and do sugar price again best say and you see what again its mm wait message for so yes a1 had sent third packet it's waiting for the fourth packet from a sc2 but a a2 is not sending forth message back because it knows if I send the fourth message back then I will have to generate session keys to generate session keys I need preciate key and where will I find appreciate in the tunnel group so it's trying to find the tunnel group but there is no Tunnel group configured so it says I will not send forth messes because then I after sending forth messes I'll not be able to proceed further and we can confirm that with the D bugs so it's a debug crypto I say camp 128 should say D bugs there I'll just say only bug all and it clearly says can't find invalid tunnel group about he wait so there is no valid tunnel group that's why it's not sending messes flow there is no relation nor requirement of tunnel group or preciate key in mess with four it is not sending message for because after sending messes for it needs to create session keys to create session keys it needs the preciate key and without eternal group it will not be able to find the British aid key so that's why it's it's not sending message for that's the responders way to let you know that there is a problem and I will not be able to proceed further so when there is no channel group cannot proceed so there are two problems that we have identified that can let your initiators stay at mmm wait message for one the responder does not have a valid tunnel group and to the responder does have a valid turn group but it does not have preciate key configured it at this moment it does not really check if the preciate gives same or not so it should be configured there right if you are seeing it if you're seeing that your ASA's mmm wait message for that does not mean that preciate keys are not safe because it's not checking if the preciate K is same or not in the next video we will see about mmm witnesses file [Music] [Music] [Music]

Channel: ASAme2

Views: 812

Keywords: MM_wait_mgs4, TAC level explaination of 6 packets, understanding mm_wait_msg4, how to fix mm_wait_msg4, cisco VPN, site to site VPN, interview question on site to site VPN, Ikev1 VPN troubleshooting, Best tshoot video for VPN, No one will tell you this about mm_wait_msg4, Secret behind mm wait msg4

Id: 9qA71JiKqr4

Length: 27min 32sec (1652 seconds)

Published: Sun Mar 15 2020