Results 1 to 3 of 3

Thread: Contivity VPN "Unable to complete encryption handshake with remote side. Encryption Mismatch."

  1. #1
    Join Date
    Sep 2004
    Posts
    66

    Contivity VPN "Unable to complete encryption handshake with remote side. Encryption Mismatch."

    My corporate VPN is not working at all. I was not having issue with connection before. But suddenly it failed to connect. The error that I am getting is unable to complete encryption. What is wrong with the same. It says something encryption mismatch. How to fix the same.

  2. #2
    Join Date
    Sep 2005
    Posts
    76
    It looks there is some issue with VPN setup. Check your entire settings one more time. There would be logs that is having clear information based on the connection. You can then troubleshoot on basis of that. Check the logs that would give you more highlight. Or simply paste the log files here.

  3. #3
    Michael Guest
    "Sunny" <sunny@nospam.net> wrote in message
    news:GSSKf.11565$%14.388753@news20.bellglobal.com...
    >
    >
    > Somebody. wrote:
    >
    > > "Michael" <michael@yahoo.com> wrote in message
    > > news:CXAKf.12889$yK1.9831@news-server.bigpond.net.au...
    > >
    > >>Hi Everyone,
    > >>
    > >>
    > >>Since early Saturday morning, I'm unable to connect to my corporate VPN.
    > >>Getting an error as follows (from the log)
    > >>Tue Feb 21 19:39:11 2006 | Isakmpd | I | Connection initiated to
    > >>xxx.xx.xxx.xx[xxx.xx.xxx.xx] using Diffie-Hellman group 2.
    > >>Tue Feb 21 19:40:01 2006 | Logging | I | : last message repeated 2

    times.
    > >>Tue Feb 21 19:40:01 2006 | Isakmpd | E | Unable to complete encryption
    > >>handshake with remote side. Encryption Mismatch.
    > >>Tue Feb 21 19:40:01 2006 | Isakmpd | I | Connection initiated to
    > >>xxx.xx.xxx.xx [xxx.xx.xxx.xx] using Diffie-Hellman group 1.
    > >>Tue Feb 21 19:40:04 2006 | Isakmpd | F | Login failed. Please consult

    the
    > >>switch log for further information.
    > >>
    > >>It was working early Saturday, then I disconnected and reconnected, and
    > >>got
    > >>this error on the reconnect.
    > >>
    > >>My IT people haven't gotten back to me.
    > >>
    > >>There have been no changed settings on this side.
    > >>
    > >>We have 2 different IPs for the VPN. I've tried the second and it works
    > >>the
    > >>same.
    > >>
    > >>Please assist,
    > >>thanks,
    > >>Michael

    > >
    > >
    > > Ask them if they've changed anything on the VPN setup, such as the phase

    1
    > > proposal. Perhaps deleting a few alternate proposal types that they

    thought
    > > nobody was using. Or perhaps the shared secret.
    > >
    > > -Russ.

    >
    > Good guess, probably close to the mark. There's no doubt the OP has to
    > wait for his IT people to fix it, the problem isn't on his end.



    Thanks Sunny thats what I suspected.
    Mysteriously, all is fixed today, even though my fault hasnt been opened or
    actioned.

    > It's really quite amazing how incredibly verbose and yet completely
    > useless most vendors' IKE debug logs are!


    Yup. This is Contivity client





    "Sunny" <sunny@nospam.net> wrote in message
    news:GSSKf.11565$%14.388753@news20.bellglobal.com...

    >> Ask them if they've changed anything on the VPN setup, such as the phase
    >> 1 proposal. Perhaps deleting a few alternate proposal types that they
    >> thought nobody was using. Or perhaps the shared secret.
    >>
    >> -Russ.

    >
    > Good guess, probably close to the mark. There's no doubt the OP has to
    > wait for his IT people to fix it, the problem isn't on his end.


    Yep, it mysteriously fixed itself. Funny how that happens. :-)

    > It's really quite amazing how incredibly verbose and yet completely
    > useless most vendors' IKE debug logs are!


    Good IKE logs are crucial to doing a successful interop. Either that, or
    *really* good luck.

    >
    > I've been fighting Solaris to Checkpoint for a few days. Solaris IKE debug
    > is great, human-readable, almost narratory - about what it received, but
    > it neglects to tell you details of what it sent! Checkpoint IKE debug is a
    > sparsely annotated dump, completely unreadable. I had to raise a support
    > request asking for a GUI that is supposed to interpret the dump, still
    > waiting for a response.


    So the thing to do there is make sure you initiate from the checkpoint side
    most of the time. If the Solaris box tells you what it recieves and whether
    or not that's ok, you know what it's sending back It will essentially only
    send back correct stuff, or, it will decide that what it got was no good and
    send back nothing. When you see an error someplace tweak the Solaris to
    match the parameter it says it got, that it didn't like.

    >
    > The tunnel works if I change the phase 2 id on Checkpoint after phase 1
    > completes, won't work on client reboot or cluster failover :-(


    That's cheating man, you can't go changing the tunnel parameters halfway
    through. :-) But you probably knew that.

    >
    > I'm getting close, but might have to build a Solaris to Netscreen tunnel
    > to gain a full understanding of Solaris' behavior - Netscreen IKE debug is
    > unsurpassed :-)
    >
    > Sunny



    That's a great trick I've also used -- indeed NS debugging is awesome. The
    latest flavors of Fortigate have just as nice IKE debugging too (yay!
    finally!) so using one of those as a reciever even temporarily is a great
    way to figure out something that's a little less clear in configuration and
    debugging. Lots of products assume this and that setting and the NS (or FG)
    lets you configure all of them speccifically so you can eventually match up
    anything that is not actually proprietary.

    And BTW, using 0/0 as proxy ID's is fine actually, as long as both boxes
    have some other way to decide what does and does not go into the tunnel,
    which most boxes do. But if you had a box on one side that counts on proxy
    ID's alone (rare) to decide what goes into the tunnel, and the other box
    counts on using 0/0 to set the tunnel up, that would be an example of a
    situation where you will have trouble getting the VPN up and running.

    -Russ.

Similar Threads

  1. Replies: 1
    Last Post: 17-09-2011, 11:41 AM
  2. Replies: 5
    Last Post: 30-08-2011, 09:48 AM
  3. Cityville: Unable to complete the "Build Restaurant" level
    By Ferdinand Alosa in forum Video Games
    Replies: 4
    Last Post: 02-02-2011, 09:19 AM
  4. Good Encryption or "Folder Lock" Program
    By Baijnath in forum Windows Software
    Replies: 6
    Last Post: 08-01-2011, 09:28 AM
  5. full disk encryption "Backup"
    By EDALENE in forum Networking & Security
    Replies: 2
    Last Post: 25-10-2008, 02:27 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •