Why does my VPN establish attempt fail?

I have 2 linksys routers which I try to establish a VPN between.
I have entered all the settings I though relevant, and saved the information.
The status says "Waiting for connection" on both sides.
Clicking "Connect" under "Tunnel test" leads to "Waiting..." until page reloads and I get back to same page.

I'm attaching some log information below, that I'm hoping someone more knowledgable than me can decipher. I'm confused by two things in the log. The local side says "Connection Accepted" repeatadly, and "(mismatch of preshared secrets?):".
I thought the connection accepted message would indicate success, but it doesn't seem to do so. Also, I'm _certain_ the key is identical on both sides. I have directly copy pasted it, and compared it again just to be safe.
Local log after "Connection test"
Dec 18 16:37:01 2009	     VPN Log	    Phase 1 message is part of an unknown exchange
Dec 18 16:37:01 2009	    VPN Log	   Phase 1 message is part of an unknown exchange
Dec 18 16:37:10 2009	   Connection Accepted	   TCP 192.168.16.143:50796->85.226.125.10:37167 on ixp1
Dec 18 16:37:10 2009	   Connection Accepted	   TCP 192.168.16.143:50796->85.226.125.10:37167 on ixp1
Dec 18 16:37:14 2009	   Connection Accepted	   TCP 192.168.16.143:50798->82.215.50.27:31122 on ixp1
Dec 18 16:37:18 2009	    VPN Log	   [Tunnel Negotiation Info] >>> Initiator Send Aggressive Mode 1st packet
Dec 18 16:37:18 2009	    VPN Log	   initiating Aggressive Mode #31, connection "ips0"
Dec 18 16:37:18 2009	    VPN Log	   STATE_AGGR_I1: initiate
Dec 18 16:37:18 2009	    VPN Log	   Received Vendor ID payload Type = [Dead Peer Detection]
Dec 18 16:37:18 2009	    VPN Log	   [Tunnel Negotiation Info] <<< Initiator Received Aggressive Mode 2nd packet
Dec 18 16:37:18 2009	    VPN Log	   Aggressive mode peer ID is ID_IPV4_ADDR: '80.252.191.50'
Dec 18 16:37:18 2009	    VPN Log	   Multiple ipsec.secrets entries with distinct secrets match endpoints: first secret used
Dec 18 16:37:18 2009	    VPN Log	   Aggressive mode peer ID is ID_IPV4_ADDR: '80.252.191.50'
Dec 18 16:37:18 2009	    VPN Log	   Received Hash Payload does not match computed value
Dec 18 16:37:21 2009	    VPN Log	   Phase 1 message is part of an unknown exchange
Dec 18 16:37:21 2009	    VPN Log	   Phase 1 message is part of an unknown exchange
Dec 18 16:37:23 2009	   Connection Accepted	   TCP 192.168.16.143:50806->80.252.191.50:6543 on ixp1
Dec 18 16:37:25 2009	    VPN Log	   Received Vendor ID payload Type = [Dead Peer Detection]
Dec 18 16:37:25 2009	   Connection Accepted	   TCP 192.168.16.143:50807->80.252.191.50:6543 on ixp1
Dec 18 16:37:25 2009	    VPN Log	   [Tunnel Negotiation Info] <<< Responder Received Main Mode 1st packet
Dec 18 16:37:25 2009	    VPN Log	   Multiple ipsec.secrets entries with distinct secrets match endpoints: first secret used
Dec 18 16:37:25 2009	    VPN Log	   [Tunnel Negotiation Info] >>> Responder Send Main Mode 2nd packet
Dec 18 16:37:25 2009	    VPN Log	   [Tunnel Negotiation Info] <<< Responder Received Main Mode 3rd packet
Dec 18 16:37:25 2009	    VPN Log	   Multiple ipsec.secrets entries with distinct secrets match endpoints: first secret used
Dec 18 16:37:25 2009	    VPN Log	   [Tunnel Negotiation Info] >>> Responder send Main Mode 4th packet
Dec 18 16:37:25 2009	    VPN Log	   probable authentication failure (mismatch of preshared secrets?): malformed payload in packet
Dec 18 16:37:27 2009	    VPN Log	   Phase 1 message is part of an unknown exchange
Dec 18 16:37:29 2009	   Connection Accepted	   TCP 192.168.16.143:50838->85.226.125.10:37167 on ixp1
Dec 18 16:37:29 2009	   Connection Accepted	   TCP 192.168.16.143:50838->85.226.125.10:37167 on ixp1
Dec 18 16:37:33 2009	   Connection Accepted	   TCP 192.168.16.143:50840->80.252.191.50:6543 on ixp1
Dec 18 16:37:35 2009	    VPN Log	   probable authentication failure (mismatch of preshared secrets?): malformed payload in packet 

Remote log after "Connection test"
Dec 18 16:37:17 2009	     VPN Log	    Received Vendor ID payload Type = [draft-ietf-ipsec-nat-t-ike-03]
Dec 18 16:37:17 2009	    VPN Log	   Ignoring Vendor ID payload Type = [draft-ietf-ipsec-nat-t-ike-02]
Dec 18 16:37:17 2009	    VPN Log	   Ignoring Vendor ID payload Type = [draft-ietf-ipsec-nat-t-ike-00]
Dec 18 16:37:17 2009	    VPN Log	   [Tunnel Negotiation Info] <<< Responder Received Aggressive Mode 1st packet
Dec 18 16:37:17 2009	    VPN Log	   Aggressive mode peer ID is ID_IPV4_ADDR: '62.182.217.20'
Dec 18 16:37:17 2009	    VPN Log	   Responding to Aggressive Mode from 62.182.217.20
Dec 18 16:37:17 2009	    VPN Log	   [Tunnel Negotiation Info] >>> Responder Send Aggressive Mode 2nd packet
Dec 18 16:37:25 2009	    VPN Log	   Initiating Main Mode
Dec 18 16:37:25 2009	    VPN Log	   [Tunnel Negotiation Info] >>> Initiator Send Main Mode 1st packet
Dec 18 16:37:25 2009	    VPN Log	   [Tunnel Negotiation Info] <<< Initiator Received Main Mode 2nd packet
Dec 18 16:37:25 2009	    VPN Log	   [Tunnel Negotiation Info] >>> Initiator send Main Mode 3rd packet
Dec 18 16:37:25 2009	    VPN Log	   [Tunnel Negotiation Info] <<< Initiator Received Main Mode 4th packet
Dec 18 16:37:25 2009	    VPN Log	   [Tunnel Negotiation Info] >>> Initiator Send Main Mode 5th packet
Dec 18 16:37:27 2009	    VPN Log	   Received Vendor ID payload Type = [draft-ietf-ipsec-nat-t-ike-03]
Dec 18 16:37:27 2009	    VPN Log	   Ignoring Vendor ID payload Type = [draft-ietf-ipsec-nat-t-ike-02]
Dec 18 16:37:27 2009	    VPN Log	   Ignoring Vendor ID payload Type = [draft-ietf-ipsec-nat-t-ike-00]
Dec 18 16:37:27 2009	    VPN Log	   [Tunnel Negotiation Info] <<< Responder Received Aggressive Mode 1st packet
Dec 18 16:37:27 2009	    VPN Log	   Aggressive mode peer ID is ID_IPV4_ADDR: '62.182.217.20'
Dec 18 16:37:27 2009	    VPN Log	   Responding to Aggressive Mode from 62.182.217.20
Dec 18 16:37:27 2009	    VPN Log	   [Tunnel Negotiation Info] >>> Responder Send Aggressive Mode 2nd packet

Open in new window

LVL 6
letharionAsked:
Who is Participating?
 
devinnullConnect With a Mentor Commented:
It looks to me like your pre-shared keys don't match.

"probable authentication failure (mismatch of preshared secrets?)"
0
 
letharionAuthor Commented:
I realised that the "Connection accepted" stuff is related to things other than the VPN, so that's probably irelevant.
0
 
zbatiaCommented:
Do you have the same MTU on both ends? If not, the packets could be messed up, and therefore not to be assembled correctly for the shared secret matching. It is just a guess...
0
Improve Your Query Performance Tuning

In this FREE six-day email course, you'll learn from Janis Griffin, Database Performance Evangelist. She'll teach 12 steps that you can use to optimize your queries as much as possible and see measurable results in your work. Get started today!

 
letharionAuthor Commented:
zbatia: The MTU is set to auto on both ends, I'll try setting it to some other value and see if it could help
0
 
zbatiaConnect With a Mentor Commented:
"Received Hash Payload does not match computed value"
I have a strong feeling that your have some kind of hardware problem when the assembled packets do not match each other on both ends. So, try to play with various parameters. Make sure they are similar on both ends (of course, as much as you can).
0
 
letharionAuthor Commented:
zbatia: Thanks for pointing that out. I'm gonna bring the router to another network and test it there,
0
 
letharionAuthor Commented:
After moving things to a different network, I noticed that the log said:
Multiple ipsec.secrets entries with distinct secrets match endpoints: first secret used
(It does so above too)
And that seem to have been the problem. I set the pass on the first VPN to the same as the one on the second, and then it pretty much worked. I did hit a few other roadblocks but I figured them out.

Thank you for your time :)
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.