Printable View
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.
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.
"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.