cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
316
Views
0
Helpful
2
Replies

IKEv2 L2L VPN fails

Hello,

since some days an IKEv2 connection to one of our customers fails.

It seems that we send requests to their firewall and they also answer, but for some reason our firewall can't parse the answer.

We have an Cisco ASA 5525 and on the other side there is a checkpoint firewall used.

The configurations for phase 1 and 2 on both sides are the same and were, at least on our side, not changed.

We and also the customer have other vpn connections wich work fine.

Attached you find a 255 debug of our ASA, maybe someone here can tell me what the problem is.

Kind regards,

Chris

2 Replies 2

Hello,

since I wasn't able to find any solution for this problem, I now changed the VPN to IKEv1.

I know this is not the securest solution but it works now.

Maybe there is still someone who has a clue what the heck went wrong here.

Kind regards,

chris

Hi,

 

It seems that transformation fails between these devices..... Might be because of the non-acceptable attribute exchange. Have you tried using a different vpn parameters between those devices?

 

try to change these parameters between those devices...

Num. transforms: 4
   AES-CBC   SHA1   SHA96   DH_GROUP_1536_MODP/Group 5

 

 

Excerpt from RFC:

The values in the following table are only current as of the
   publication date of RFC 4306.  Other values may have been added since
   then or will be added after the publication of this document.
   Readers should refer to [IKEV2IANA] for the latest values.

   Attribute Type         Value         Attribute Format
   ------------------------------------------------------------
   Key Length (in bits)   14            TV

   Values 0-13 and 15-17 were used in a similar context in IKEv1, and
   should not be assigned except to matching values.

   The Key Length attribute specifies the key length in bits (MUST use
   network byte order) for certain transforms as follows:

   o  The Key Length attribute MUST NOT be used with transforms that use
      a fixed-length key.  For example, this includes ENCR_DES,
      ENCR_IDEA, and all the Type 2 (Pseudorandom function) and Type 3
      (Integrity Algorithm) transforms specified in this document.  It
      is recommended that future Type 2 or 3 transforms do not use this
      attribute.

   o  Some transforms specify that the Key Length attribute MUST be
      always included (omitting the attribute is not allowed, and
      proposals not containing it MUST be rejected).  For example, this
      includes ENCR_AES_CBC and ENCR_AES_CTR.

   o  Some transforms allow variable-length keys, but also specify a
      default key length if the attribute is not included.  For example,
      these transforms include ENCR_RC5 and ENCR_BLOWFISH.

   Implementation note: To further interoperability and to support
   upgrading endpoints independently, implementers of this protocol
   SHOULD accept values that they deem to supply greater security.  For
   instance, if a peer is configured to accept a variable-length cipher
   with a key length of X bits and is offered that cipher with a larger
   key length, the implementation SHOULD accept the offer if it supports
   use of the longer key.

Regards

Karthik

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: