Disclaimer

The content of this material are challenges faced onsite and how I personally resolved them. Please be noted that solutions posted here

1> should not be considered as ultimate. The material may be considered for reference only.

2> should not be considered as guarantee that solutions may work. Contact Cyberoam support before making any changes.

3> blog does NOT belong to the Cyberoam. It's a blog...a personal blog.

Changes done after referring this site may seriously damage the network. So...

........DO CHANGES AT YOUR OWN RISK

(please contact cyberoamsupport before implementing any changes)

Thursday, 13 March 2014

How to check IPSec - Phase 2 logs in Cyberoam

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

Friday, 21 February 2014

Port LED status of Cyberoam

Wondering what PORT LED talks about in Cyberoam. Check below:

Appliance Models: 15iNG/25iNG/35iNG
Green (left) 10M Link up
Green(left) 100M Link up
Amber(right)
Green(left) 1000M Link up
Green(right)
Appliance Models 50iNG/100iNG
Amber(left) 10M Link up
Amber(left) 100M Link up
Green(right)
Amber(left) 1000M Link up
Green(right)
Appliance Models 200iNG/300iNG
Green(left) 10M Link up
Green(left) 100M Link up
Green(right)
Green(left) 1000M Link up
Amber(right)

IPSEC phase 1 explained

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 5th and 6th 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 2nd 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.