Fortigate tech

Phase-1 of IPSEC In 1st two message it negotiate proposal and IKE version and NAT-T capability  Proposal/transform >> HAGLE - HASH, AUTH, DH Group, Lifetime ,Encryption   1st Message IPSec main mode: SA Payload  Proposal payload Trasform payload SPI/cookie 2nd IPsec Main mode message 3rd Message IPSec main mode: In 3rd and 4th message, it will do key exchange and Nonce and NAT-D (IP & Port hash) DH key exchange :: DH algo used to agree on same shared secret and generate key material DH public value is calculated  (public value is mathematical calculation of private keys) -->>It generate public and private key's --->>It share public key's (x^b) (x^b)==>g^a mod p (MOD(generator of private key=a)) g^ab=>(x^b)^a mod p (large prime no) ==>Each side has their public key and nonce ( Ni_b is the Initiator's Nonce, and Nr_B is the Responder's Nonce) ==>It generate   SKEYID = prf(pre-shared-key, Ni_b | Nr_b) The See...

In first two packet, it will negotiate NAT-T compatibility  1st Message in Main mode: 2nd Message in main mode: In 3rd and 4th Message, it will exchange hash of IP address and Port. 3rd Message main mode: 4th Message in main mode Debug on FGT: ike 0: comes 10.1.1.20:500->10.1.1.10:500,ifindex=4.... ike 0: IKEv1 exchange=Identity Protection id=987e2067d9c61bc0/3954de8f43e2c2c0 len=348 ike 0: in 987E2067D9C61BC03954DE8F43E2C2C004100200000000000000015C0A000104CD2F264257D538BA3EC01D4446EB541E8923 ike 0:VPN:14: responder:main mode get 2nd message... ike 0:VPN:14: received NAT-D payload type 20    ike 0:VPN:14: received NAT-D payload type 20 ike 0:VPN:14: NAT not detected   <<-----------------------       If hash matches, there is no NAT device in between and It continue to use same port 500 for remaining communication If there is NAT device in between both peer:==> 3rd message in main mode: 4th message in main mode: ike 0:VPN:3: ...

==> TCP checksum is combination of Data + TCP Header + Pseudo Header We all aware about DATA and TCP header but what is this Pseudo Header? Pseudo header is combination of [SIP + DIP + Protocol ID (TCP or UDP) + TCP length (including both header and data) + Reserved(all 0) ] Pseudo Header:=> Sometimes, question may arise whether router changes TCP checksum as it changes (decrement) TTL value   ==>Pseudo header doesn't include TTL value 

        Encryption is good thing when you send your traffic on public network, but sometimes we may need to decrypt packet to troubleshoot the issues and need to see what is going on under the hood. Here, I am going to explain how to decode the ESP packet using Wireshark You can see in below image that after phase2 negotiation, data is getting encapsulated using ESP header (Note: I am using FortiGate firewall here but it would be same process for different vendors as well provided you need to collect authentication and encryption parameters) =>In Wireshark navigate to edit -> preferences -> protocol -> esp. =>As per image, enable the last 3 checkboxes and select "edit" next to ESP SAs ==>Create two entries for the incoming and outgoing SA ==>We need add information obtained from the VPN tunnel list in each line ==>Save the changes Finally, you can see the ESP packet is decrypted Thanks for reading the article...😃