S3E2 Quick Mode messages || Phase 2 message exchange

hello and welcome back first of all i would like to thank you for supporting me in doing the scripture 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 comment and share if you are new to this channel also hit the subscribe button in right bottom corner with that being said let's see what we have got today so if you have already seen my previous videos you already know that for a for a side to side panel to come up it happens in two phases phase one and phase two they're also known as main mode let's quick so the main mode is your phase one and quick mode is phase two so i've already covered main mode or phase one everything about phase one in previous videos if you have not seen the previous videos then i will recommend you to pause this video right here go to the description and look for the main mode videos so go through them understand what main mode is and then come back to quick mode but if you already have a good understanding about main mode then feel free to continue watching it as you already know in main mode they exchange six packet or six messages in quick mode they exchange three messages for every pin tunnel to come up there are total nine messages exchanged between the peers so let's see what information is shared in the quick mode in these three packets quick mode is going to be a little difficult to understand and the reason is in main mode there are six messages so let's say we have an initiator we have a responder initiator sends the first packet responder sends the second message initiator sends the third message responder sends fourth message so after exchanging these four packets both ends initiator and responder based on rate a session key and they use that session key to encrypt some part of the next packets so fifth packet will now be encrypted or you can say part of the fifth packet will be encrypted and then sent to the responder and likewise responder will also send this six message as encrypted using a session key e after this point they start sending encrypted data to each other now they no longer send the clear text data like they did in one two three and four they send the encrypted data so after this point you cannot see what's actually in there because the data is encrypted right so if you take a wireshark and try to see what information has been sent in the fifth message you won't be able to see it because that's encrypted all you will see encrypted data and the size of the encrypted data how much it is now that's the reason because they started doing that encryption from fifth masses so seven message seven message eight and message nine will also be encrypted using the same session key so that is to protect your ike session so that now you you can exchange your critical information and we are encrypting it so that's why if you open these package the quick mode messages the package seven eight and nine these this is your quick mode if you open them in wireshark you won't actually see anything that's why quick mod is going to be a little difficult to understand because i won't be able to show you the wireshark like i said in quick mode there are going to be three messages initiated on responder quick mode is your phase two initiator will send the first message there are going to be three messages so we say this is the first message initiator is going to send responder will send the second message and initiator will then send third message you know in phase two also we exchange kind of similar information that we did in phase one and we have less packets to share that information so like in main mode we were sending phase one policies right and then the responder was checking which policies are matching and then responder will select one of them and send back that let's use this so there were lots of room to negotiate like one two three four five six lots of package exchange between each other so you send i'll tell what to use you send i'll tell what to use so there was a lot of room to negotiate things but here in quick mode there are only three messages three packets so there will be less negotiation let me go a little back and see what information did we exchange in phase one so in phase one we had phase one policies where the policy included information items such as hashing authentication diffie-hellman group the age group lifetime and the encryption so hashing had a few options like you can use md5 or sha authentication was pre-shared key based defeatment group 2-5 it's lifetime so you can use any value in seconds and encryption so you can use a yes so these these were the few items that we were negotiating in the first message of the main mode and like i said in phase two also we negotiate the similar similar information but we do it again and we do it little you know the content is little different in phase two also we need all these items hashing authentication group lifetime encryption right because using these items only we will end up creating the keys the encryption keys so in quick mode when we send the first packet this is when we send all the information anything that we have that we have to send to the responder everything is sent in the first message or the first packet because then there is no room to negotiate anything else right so anything that we have the initiator has it sends everything in the first packet and what information do we send in the first packet so in the first packet we send phase two policies that they're called here as transform set if you remember you create a transform set and call the transform set into the crypto map okay so that's the fit that contains your phase two policies there's something that is optional it's known as pfs so this is an optional thing if you want you can do it pfs stands for perfect forwarding secrecy or you can say it said tiffy helman for phase two why this is optional you can renegotiate tiffy helmand for phase two or if you don't do it then it's going to use the same keys that it used in phase one for diffie-hellman so we if you remember we did negotiate difficult in phase one right so if we do not use bfs here then it's not going to negotiate diffie-hellman once again and it's going to use the same keys that is generated in phase one the only disadvantage is if the phase one diffie-hellman keys were somehow compromised then phase two defeat helmet keys will also be compromised because phase two is also using the same keys but if you enable pfs then phase two will negotiate difficult once again and create the development keys again and the recommendation is have it enabled so though we say it's optional but it's recommended to have pfs enabled then we also send a nonce value then we send a hash payload hash value as well so this hash payload will be hash of few values from phase one and few values from phase two and the purpose of this hash is to to authenticate the peer once again then there will be proposal payload so this will include uh the type of encapsulation that we're going to use is it going to be ah or esp and this will also have an spi value then there will be a transform payload so this will include if it's going to be a tunnel mode or transport mode and they will uh one last thing that will be there is an id payload this id payload will contain your proxy ids proxy ids so this id payload will contain your crypto acl now here is the complex part all this information the phase two policies transform set the pfs nonce hash payload proposals proposal payload transform payload the id payload all this information is sent in one packet the first packet of quickbook so if anything is a mismatch you don't know which one if any of the information sent by s does not match the information responder has this tunnel will not come up so let me show you packet once again so in the first message of quick mode doing quick mode here and this is going to be the first message so in the first message we send hash payloads hash payload will be a pseudorandom function of skid a which was generated in phase one initiator nonce then the proposals and the transforms the x a dash so this means you know what this is it's the public key right in the development so dash indicates here that this has been generated once again that means we're using pfs the new quick mode will have an sa payload this sa payload will have information uh like about the dui domain of interpretation and the situation same as what we used in phase one then we'll have proposal payload proposal payload will of course include the proposals hellman hashing encryption and spi and then there will be transform payload this transform payload will have whether it's the tunnel mode or transport mode and it will also have the timeouts key exchange payload key exchange payload will of course have the new development public key the non-payload so you will have the new nonce value and then we will have identity payload so there will be two identity payloads so the name will be same but of course there will be different information the identity payload will have information about your proxy ids or the crypto seo so this let's say this identity payload has information about local subnet and there will be second identity payload and this will have your information about remote subnet you can also write it as source proxy or destination proxy this all information is going to be one package the first one so let me first take a snapshot if we need to refer this again all right i have it now when the responder receives first message from the initiator so the responder also sends the similar message back with few changes so let's see what the changes are so let's start with the hash payload so i'll just write hash payload and this hash payload if you remember in the first message the hash payload contained the hash of skid a initiator non proposals transforms and the tiffy helmet public key the new default public key but this hash payload is only going to have payloads that are contained in this message so that this hash payload will be considered as a kind of a proof for the responders liveliness so this hash payload will contain the hash of the latest nonce as well as the message id field from the previous message so this is just to tell the initiator that the responder is alive to confirm the responders identity or give it as consider it as a proof and this will also confirm that the responder has received the your first packet and it's ready to receive the encrypted data now because there is going to be no more packets from the responder right remember the third message is going to be from initiator so responder has to give its confirmation in this only packet that i am ready to receive the encrypted data now so this hash also gives a confirmation that as a responder i am ready to receive encrypted data this is the only packet responder has got to confirm that thing that's why it's doing here in the hash payload the next payload will be sa payload so the sap load it's again going to have the same things doi and situation and then we will have proposal payload the proposal payload will have the accepted proposals and the spi values and we will have the transform payload transform payload will have the accepted transforms what has been accepted tunnel mode transport mode and the timeouts the next payload will be the exchange payload this key exchange payload will have the diffie-hellman public key of the responder xp dash non-spellowed the non-spayload will have the nonce value have identity payload there are again going to be two identity payloads one of them will have the local identities the source identities and other will have the remote subnet ids so you can say id of destination this is going to be similar to what the initiator has sent let me take a screenshot of this as well and so that i can show you the [Music] comparison and now comes the time to send the third message from the initiator the initiator sends the third message to the responder before sending third messages both initiator and responder they have exchanged some information in first and second packet and i would say not some information all the information they have exchanged in first and second packet right so if there was anything that was not matching or if there was any mismatch between their parameters in first that was that was sent by the initiator in the first message and let's say something did not match on the responder so responder will not reply with the all the parameters in the second message instead send an informational message telling that some few things do not match so i'm not going to continue this negotiation with you right but if everything matches then there is going to be the third packet and before sending this third packet and after responder is done sending the second message back to the initiator they both initiator and responder they both do some calculation in both first and second messages they've exchanged their tiffy helmet public key the new dfi helmet public key xa dash and xv dash right these values have been negotiated in the key exchange payload now using this key exchange payload we have they generate a new daffy helmet shared sacred similar to what we did in the phase one so if you want more details about how this was generated you can go back to the previous videos and check this out so they generate a new daffy helmet sacred this is done on the both sides and then using these steffi helmand secret the session id the sk ids and some other parameters they generate encryption and decryption keys the ipsec encryption and decryption keys the initiator generates the session keys for inbound a pseudorandom function skiddd protocol ic cam the new daffy helmet shared secret responder spi the new initiator nons and new responder nodes so using these values the ip6 session key for inbound traffic is generated and the initiator also generates ipsec session key for outbound traffic so session key for outbound traffic formula is going to be pretty much similar pseudo random function session key id d sk idd protocol and the new daffy helmet shared secret vi of initiator the initiator nonce and responder nodes and in the similar manner responder also generates the session keys so for both inbound and outbound so let's say on the responder side the ipsec session key inbound is going to be exactly same that was generated on the initiator side side for outbound so the formula is you can say it's going to be exactly same so this goes here and this goes here so whatever key is used on initiator side for inbound traffic that will be used for outbound on the responder end and the key that is used on the initiator site for outbound traffic will be used as inbound on the responder side this all is done before sending third messes they both generate these keys independent of each other using the same same values that they've already negotiated and that's why these keys are going to end being same on both the sides so once these keys have been generated it's pretty much ready third message is sent by the initiator initiator sends the third message and in this third packet it's in proof that i'm live so it just sends a proof that i'm live and how it does that initiator sent the first packet the responder said replied with the second message in the second message responder also replied because responder knew that this is going to be the only packet that i'm going to send so in the second message itself with the help of hash payload responder made sure to let the initiator know that i'm live and ready to receive the encrypted traffic the responder has already given the proof of life after exchanging first and second messages they processed the data and came up with the ipsec encryption and decryption keys right once the keys have been generated now the initiator will send the third message in the third message it sends a proof of life by sending the hash payload only so the third packet will only have a hash payload and this hash payload it is going to have the hash value of new initiator nons and new responder nodes and with the help of that it confirms that i'm live and i have received your second packet and successfully processed it this will be a hash of new initiator nonce value and new responder nonce value once that packet is sent there is nothing else required for either from the initiator or responder so once it has been sent from the initiator it all comes up the initiator does not wait for any confirmation the tunnel comes up so let me show you some debugs i'm just going to enable debugs for my tunnel so i have this vp internal with 72 163 5.144 you can enable these debugs in live environment as well but you have to do it exactly the way i'm doing it right now you have to enable your debugs conditionally just for your particular vpn tunnel that you're interested in and do not enable the debugs for everything right so i'm just going to take this ip and say debug crypto condition here and the prip so that's how you tell the asa to enable the debugs just for this particular vpn here right and sometimes what happens that you know when you have multiple vpn tunnels and multiple people managing the device so they might also enable the conditional device for some other vpns and forget to remove them right forget to disable their debugs when they leave this session so that keeps the condition there if someone else has enabled some conditional debugs the way to do that is show debug crypto condition and you can see there is only one iep in the filter and that's that 5.144 if you see more than one eyepiece you'll have to turn off the debugs and get rid of that and then enable it again right now only my ip my required ip is in the condition i'm going to enable the main debugs now so i said debug crypto 1 128 i do and then i'm say debug crypto ipsec 128. all right so we have the debugs in place let's initiate some traffic so i'm going to go to so i'm going to initiate some traffic from my other computer in the lan let's see what happens so there you have i've stopped the pink let's look at this debugs so i'm not going to show you the phase one debugs once again because we have already done that in previous videos so if you want to see how to troubleshoot or how to read debug for phase one you can watch the previous videos look in the description you will see the link there now once it says phase one has been completed let's see what happens then so after phase one completed it starts the phase one re-key timer and starts to negotiate phase two here it says icon initiator sending first qm packet so it's sending the first message now that means whatever this thing is done before sending the first message so let's see what it has done so i got spi from key engine so it has generated one initiator spi then constructing quick mode constructing hash payload ipsec sa payload non-payload key exchange payload the pfs key exchange payload pfs stands for perfect forwarding secrecy which is a diffie helmet for group sorry diffie helmet for phase two the proxy id is constructing proxy ids like transmitting proxy ids so these are the proxy ids we have the crypto acl the local subnet is 10 42 166 0 and the remote subnet is 19168 7.0 and both are slash 24 so you can see that information right here in the debugs and then it says i can ensure the sending initial contact constructing qm quick mode hash payload so that's the hash payload right now this was a constructing blank hash payload and now this is the actual hash payload right initiator is ready to send the first quick mode packet with this this message id right so i decode sending messages message i did this so just notice the message id it's same as this that means it's still the first packet so it has a header hash sa nones payload key exchange payload id payload or id payload again identity payload so all this the payloads that we discussed just discussed i decode received message with this message id so it has received a message from the responder with the header hash and it says delete and there is nothing else but we were expecting the similar payloads right so instead we got delete message from the remote end and then we start to process it so processing hash payload processing delete in the delete it has said terminate so the connection terminated for the peer and then we send the delete to the peer that we have deleted he also delete so we are sending ict code sending message we send header hash and delete and then the session is being turned down reason user requested so that's not the actual reason that user has requested for it and then it says removing peer from correlator table failed no match i'm just showing the debugs again here this was phase one completed and then it starts the phase two creating all these payloads sending the first quick mode packet and then this is the actually sending this is when it's actually sending the packet and this is the received one where we received the delete payload all right so what do we know from these debugs what's happening removing pier from correlator table failed no match so you get this error message when when usually there is a mismatch in phase two this can be a mismatch of transform set can be a mismatch of the crypto but as we know it's not because i've i've made sure that all the crypto seals are fine the reason we are not seeing lots a lot more information about why it's steering down the tunnel because we are the one who is initiating the vpn so we are sending something that the remote n does not like and that's why the remote end is sending us a delete message you see we sent the first pass we sent the first quick mode message and then we receive a delete from the remote end right that means in our message there was something that remote and does not like that's not configured there not supported and that's why it has requested for a delete that delete the tunnel i don't like this right so if you are not seeing really a valuable information in your debugs then it will be a good idea to have the same debugs on the remote end so let me get access to the remote and i'll we'll take the debugs there all right this is the second asa let's enable the debugs here again so show run crypto map i want to make sure i know my peer oip so that i can have the conditional debugs enabled so i'll say debug crypto condition peer and the peer i p once i have the conditional debug enabled i would like to verify what condition do i have so i'll say show debug crypto condition and that will confirm my peer i p once you once you've done that let's enable the actual debugs so debug crypto icon 128 and debug crypto ip618 let me go back to my pc and run the traffic once again and you will start to see the debug the ping is running i've stopped it now debugs are going to stop as well under bug all that's how you stop them once you've done on debug all let's let me show you this check the debug condition again and there is none so once you do undebug all it automatically removes your conditional debug but at times you forget to do one debug all and your session times out your sss session to the firewall times out and that is when it leaves that conditional you know the conditional debug that you have entered in the filter let's take a look at the debugs and i'm seeing little more different debugs here as you can clearly see this is where phase one completed and phase two processing started so because this guy is responder so it has not created the first packet it has received the first packet right respond to starting qm quick mode and received message so it has received the header hash sa non ski exchange id id processing the payloads processing hash payload sap load non payload k exchange payload processing i i secm key exchange for pfs in phase 2 id payload so it after processing the id payload it is also showing what id or the what proxy ids have been received so ipv4 address subnet id received 1042 166 24 right this was the local id so and received remote ip subnet line id so this is the remote ip 1042 166 and we also show you the local id so these are the local id so received local ip proxy subnet 19168 7.0 processing notify payload and then it says tunnel rejected conflicting protocol specified by tunnel group and group policy that's why it's sending a delete because it doesn't like the protocol so let's see what it doesn't like in the protocol so it says conflicting protocol specified by tunnel group and group policy so we have to look at the tunnel group and group policy configuration so show run tunnel group and the tunnel group name the tunnel group name for a site to site vpn is usually the peer id so my tunnel group does not have any protocol let's check the group policy i don't have any group policy here so if you do not specify any group policy in your tunnel group it automatically takes the default group policy and how do you see the default group policy you say show run all group policy that's how you see the default group policy so you see come on group policy default group policy so it talked something about the protocol so i have vpn tunnel protocol and it is set to ike version 2 but i'm doing a tunnel that that has been configured as ike version 1. so this is the mismatch the group policy says let's do i equation two but the internal configuration says let's do i question one so we have to fix this thing and how do we fix it let's enable the i question one as well in the same group policy so you can do config d go to group policy attributes so we're going to enable both of them i question one and i equation two it's not necessary if you are not using i equation two you can of course get rid of that let's verify the tunnel protocol here here as well children all group policy so the external protocol is i question two so here i'll show you that we can get rid of this and only have only have i question one so i'll say no and there you go let's verify show run all group policy you only have a question one now you might be you might be wondering why am i saying sure and all group policy and not just showrun group policy because if you do student group policy it will only show you the system changes that you have done or the custom group policies that you have created so this is the custom thing that i've been done in the default group policy then why then then i'm seeing it here right otherwise it doesn't show the default group policy when you do sure run group policy it only shows you the policies that have been manually created and the default one is it's by default you don't create it it's there already so looks like we have everything in place now let's have the debugs enabled once again sure crypto map i need my pure ip debug crypto condition peer and the peer i p duplicate address in the filter table okay so let's check the tables what debugs do i show debug debugs are already enabled here with this as a filter all right let's have some traffic initiating thing should see the debugs now stop the ping all right good to see phase two completed face to completed my dear friend and i have just sent five things so i'll show you where you can see that the good news is phase two completed let's quickly take a look at these debugs what information do you see more i'll just say un-debug all so that nothing else comes in when you're looking at them so similar thing here once the phase one has completed it starts the phase one leaky timer and starts to create the first quick mode packet and before sending the message it creates few payloads sending the first quick mode messes with header hash sa non-ski exchange id id notify and then it received and the received message it says header hash sa non ski exchange id id similar thing it is processing the received packet and extracting the information so if it finds loading i loading all ipsec says generating quick mode key so that's what i told you that after they've sent first and second packet then they start generating the keys right so it looks at the crypto map and constructing final quick mode so you see it has generated these spi values here the inbound spi three five one and outbound spi is something like ends with dft let's let's just copy them i wanna show something so let's copy this sva values somewhere open the notepad here they are i have copied them so these spi values has been created and then it sends the final quick mod message sending third quick mod packet in the third quick mode packet it sends header hash and nones none sorry not nonce it only sends a hash value then the security associations have been created which binds itself with these spi values that we have just created right so there were two spi values this one let's take a look at this notepad that we just copied so inbound spi you see this ends with three five one here this is our bond section anyways let's look at the outbound spi then so here this this says outbound sphere is 58229 dft so this is outbound spi 58229 dft the tunnel type is l2l protocol is esp lifetime to 40 seconds so it creates a kind of vpn context for it which will store the encryption keys encryption or decryption keys that are going that they are going to use so these are not the keys the spi values you see they are not the keys but they are referenced to the keys that are going to use right so we cannot have the keys displayed right there so they are stored in the database and this is the reference number so when it points to this spi that spi points to that particular key stored in the database that's out there that's how it works and this was for outbound the direction outbound and we'll also have for inbound so this is for inbound where the spi is 351 so it creates a vpn context creating inbound vpn contacts for spi three five one so it starts the sa spi the pier all these values all right and finally it says face to complete it so after once it is done sending the third message it will just simply say face to complete it now how do you check your phase 2 is up and what's happening in the phase 2 so you say show crypto ipsec s you know before showing paste let's check the phase one so show crypto i second let's say and that tells mm active means main mode is up so your phase one is up show crypto ipsec as safe here pure ip prip that shows you phase two so this is your crypto acl local identities your local network remote identities the remote network and the current prip what crypto access list is matched how many packets have been encrypted how many packets have been decrypted so it shows you that information right and interestingly it also shows you the information about the spis that we're talking about so inbound esp essays and outbound esps says right because it has to refer to that database right where it has the keys to encrypt and key to decrypt so that's why it creates this this uh essays here with the spis as a reference so you see the spi's are still same d351 and dfd i'll just open that notepad once again so d351 is the inbound so you see inbound here let me take the pen so the inbound spi here 351 matches the inbound spi here 351 right and same goes for the outbound spi so outbound is expanding with dfd matches the outbound spi here dft so they are the same spi values right and like i said this spi value is just a reference to the actual key database that is being used to encrypt and decrypt so once it see this spi it matches to the particular database right um this output is little lengthy so what i do to compress the output and see the only only thing that's required i do pipe include i didn't and pick it yes so usually the problems are like packets are encrypting not decrypting how many pack you want to see how many packets are going how many packets are coming so you can use this if you need to see the spi values then of course run the direct command do not filter it so you will be able to see the spi values as well it also mentions the inbound and spi outbound spi here that's all for now i hope this has been informative to you and i would like to thank you for watching it it is your support your likes comments that keep me motivated for bringing up more stuff like this please let me know if this has helped you if you are new to this channel also hit the subscribe button

Channel: ASAme2

Views: 540

Keywords: Phase 2 messages, Quick mode messages, quick mode IPSEC, ipsec quick mode messages, ipsec quick mode vs main mode, Understand phase 2 of VPN, site to site VPN cisco ASA, Best video on quick mode, best video quick mode, best video phase 2

Id: ux62EtNBQBk

Length: 43min 50sec (2630 seconds)

Published: Sun Apr 25 2021