Cyberoam Expertise Exchange

Mar 13 19:53:33 "VPN_1-5"[7] xx.yy.zz.aa #1780: responding to Quick Mode {msgid:6fbca545}
Mar 13 19:53:33 "VPN_1-5"[7] xx.yy.zz.aa #1780: transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
Mar 13 19:53:33 "VPN_1-5"[7] xx.yy.zz.aa #1780: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
Mar 13 19:53:33 "VPN_1-5"[7] xx.yy.zz.aa #1780: Dead Peer Detection (RFC 3706): enabled
Mar 13 19:53:33 "VPN_1-5"[7] xx.yy.zz.aa #1780: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
Mar 13 19:53:33 "VPN_1-5"[7] xx.yy.zz.aa #1780: STATE_QUICK_R2: IPsec SA established {ESP=>0xc3d2c8ac <0x58bb2aa2 xfrm=AES_128-HMAC_MD5 NATD=xx.yy.zz.aa:4500 DPD=enabled}

Mar 13 20:53:33 "VPN_1-1"[7] xx.yy.zz.aa #1760: received Delete SA(0xc3d2c8ac) payload: deleting IPSEC State #1780


1780 is connected and after an hour phase 2 negotiated..and generated delete SA for the 1780

I will try to explain phase 1 of IPSec:

Below is slide from CCNSE where VPN is explained. But most of us who are hungry for more below details might help you

I will explain main mode with PSK. Before that we need to understand how DH group works.  

DH : This is a key exchange protocol. Please note that at any point of IPSec, none of the peers will send the PSK. DH is a public key encryption. So it will have private and publick key.

Both sides will have same shared password. I hope till now we are on same page. Now let us go in to more depth.   In first message A (initiator) sends  à SA, encryption algorithms, authentication algorithms, DH groups, SA lifetimes
In Second message B(responder) will accept, match and send the accepted policies back to B. This is done because you have configured multiple combinations of encryption and authentication algo. B will choose the parituclar algo and then.   -------------------------------------IKE policies are exchange DONE----------------------------------------------------

In third message: A will send Apu and AEX which are public value and Nonce (random numbers) respectively. B will do three things: a>   combine AEX+BEX+ PSK to derive first of the four session keys, SKEYID_1 b>   Combine Apu+Bpr+modulation->DH secret Key (K); Note that K will be same on both peers c>   K + SKEYID_1 will derive three keys =>  Key 1 > SKEYID_E (encryption key) à Used to encrypt 5^th and 6^th ISAKMP messages  Key 2 > SKEYID_A (Authentication) à Used in creating HMAC for authenticating ISAKMP messages Key 3 > SKEYID_D  (data encryption key) à This will be used in phase two if PFS. It will be used along with DH group in 2^nd to derive final key.   In Fourth Message B will send Bpu and BEX which are public value and Nonce (random number respectively). A will do three things same as explained above   ------IKE policy has been agreed upon (first two messages), keying material has been exchanged (second two messages), and session key values have been calculated---------

In Fifth Message

This message is encrypted using SKEYID_E and hashed with SKEYID_A. B will receive the same and compare with SKEYID_A derived locally. If same, the peer is authenticated along with compared ID Payload values.

The ID payload will  simply have IP address of the initiator.

In Sixth Message

Same is done as above, A will receive the HASH and ID payloads. It will authenticate using ID payload and check the authenticity using HASH. Note again this is encrypted with SKEYID_E.

Phase I is done.

Error log:

Dec 09 12:37:50 "Mind_set_Tunnell-3" #5813: cannot respond to IPsec SA request because no connection is known for 10.64.21.160/28===1xx.110.1xx.98...91.21.xx.xxx===10.80.0.0/13


Solution:


This log describes the SA. The CR is not able to match this SA to any of its already existing SA. Check carefully the subnets at both ends. Everytime there is this error, customer has always done error in the subnet mask or the lan Ip address. So check carefully.

Cyberoam IPSec logs may give you pretty good clues about the error. To check the logs you need to type the command

show vpn IPSec-logs

(use can use tab just to complete the command)

Below is the error from the above said logs: ERROR: asynchronous network error report on eth1 (sport=500) for message to 60.51.xxx.xxx port 500, complainant 60.51.xxx.xxx: Connection refused [errno 111, origin ICMP type 3 code 3 (not authenticated)]

Solution: There is nothing much  you can do about this. The error simply says that the port 500 is not open at the other end or the pluto is not working at the other end. We can know later that port 500 was blocked by the ISP. Pretty Strange but that was all.

Error Msg:

Dec 01 15:00:42 "VPN-1" #436: max number of retransmissions (2) reached STATE_MAIN_I3.  Possible authentication failure: no acceptable response to our first encrypted message

Resolution:

VPN here is the tunnel name. This peer is initiating the tunnel but the other end is not responding to it and the reason is due to wrong pre-shared key being used. To resolve this change the pre-shared key in your tunnel settings.