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

"Sunny" <sunny@xxxxxxxxxx> wrote in message

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.


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 :-)


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.