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.



Relevant Pages

  • UPDATE: Site-to-Site VPN Using Solaris 9
    ... Solaris 9/10 IPsec tunnel to some other device? ... The problem comes in Phase 2 when the Solaris endpoint is telling ...
  • Re: Port forwarding (tunneling?) HTTP requests to Windows client
    ... Do you have web proxy running anywhere on your campus ... Let me also assume that you have a POSIX environment like Solaris ... Reconfigure your web browser to use ... machine at home and configure it to use your tunnel. ...
  • Re: Port forwarding (tunneling?) HTTP requests to Windows client
    ... way to forward HTTP/FTP requests from a graphical browser on ... Do you have web proxy running anywhere on your campus ... Let me also assume that you have a POSIX environment like Solaris ... machine at home and configure it to use your tunnel. ...
  • overall procedure for Solaris tunnel
    ... A basic checklist to establish a tunnel on Solaris 9: ... * Setup SAs for standard transport mode between two "outside" ... tunnel on both ends of the inside interfaces, ... Bring it up and voila - instant tunnel between two Solaris hosts. ...