Learn how to a build a cloud-first strategyRegister Now

x
?
Solved

Why does my VPN establish attempt fail?

Posted on 2009-12-18
7
Medium Priority
?
4,465 Views
Last Modified: 2012-05-08
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

0
Comment
Question by:letharion
  • 4
  • 2
7 Comments
 
LVL 6

Author Comment

by:letharion
ID: 26081504
I realised that the "Connection accepted" stuff is related to things other than the VPN, so that's probably irelevant.
0
 
LVL 3

Expert Comment

by:zbatia
ID: 26081838
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
 
LVL 2

Accepted Solution

by:
devinnull earned 1000 total points
ID: 26087049
It looks to me like your pre-shared keys don't match.

"probable authentication failure (mismatch of preshared secrets?)"
0
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 
LVL 6

Author Comment

by:letharion
ID: 26115452
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
 
LVL 3

Assisted Solution

by:zbatia
zbatia earned 1000 total points
ID: 26115489
"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
 
LVL 6

Author Comment

by:letharion
ID: 26207863
zbatia: Thanks for pointing that out. I'm gonna bring the router to another network and test it there,
0
 
LVL 6

Author Comment

by:letharion
ID: 26273123
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

Featured Post

NEW Veeam Backup for Microsoft Office 365 1.5

With Office 365, it’s your data and your responsibility to protect it. NEW Veeam Backup for Microsoft Office 365 eliminates the risk of losing access to your Office 365 data.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Will you be ready when the clock on GDPR compliance runs out? Is GDPR even something you need to worry about? Find out more about the upcoming regulation changes and download our comprehensive GDPR checklist today !
In this article, the configuration steps in Zabbix to monitor devices via SNMP will be discussed with some real examples on Cisco Router/Switch, Catalyst Switch, NAS Synology device.
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…
Monitoring a network: why having a policy is the best policy? Michael Kulchisky, MCSE, MCSA, MCP, VTSP, VSP, CCSP outlines the enormous benefits of having a policy-based approach when monitoring medium and large networks. Software utilized in this v…

810 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question