03-09-2009 04:58 AM
Not sure if this is in the correct place, but here goes.
I'm trying to setup a VPN link between the Juniper 550M and the SWPro 3060. I have created the policy on SW and our customer has done his end on the J550m, He has setup a PC on his network for me to telnet, I try to connect and he can see it hit the firewall his end but it will not connect.
It will not get passed via phase 1. I thought it may be the preshared key, so we set the preshared key to something very basic "password"
We also checked to make sure the IP information was correct. source and destination
these are the setting that we both agreed on:
Keying Mode - IKE
Key Exchange - Main Mode without PFS
SA Authentication - Pre-shared key
Keying Group - Diffie Hellman Group 2
Encryption - 3DES with SHA1SA Life Time - 86400 seconds
On the juniper it only had listed SHA so I guessed that this was SHA1
Any help or advice please
03-09-2009 07:26 AM
The best place to check for the problem is not on the recipient device because the initiating device generally provides little to no information as to why the VPN has failed.
A get ike cookies allows you to determine the status of a Phase 1 IKE tunnel
A get event as the event log is responsible for displaying successful and unsuccessful VPN tunnel negotiations
The event log also displays failed negotiation attempts and even though it includes the general error message, it does not display the specific error instance. In order to view that, we need to enable the debugging of IKE. To enable IKE debugging, issue the following command:
debug ike basic | detail
In order to view the output, you must issue the following command:
get dbuf stream
Once Phase 2 negotiations have completed, it is possible to view these properties by examining the Security Association information. To obtain SA information, issue the command:
To obtain more information regarding a given SA, issue the following command:
get sa id id
Some common VPN errors are:
Phase 2: No policy exists for the proxy ID received - This error relates to a misconfigured proxy-ID
Different ends of the VPN may have a different policy configured for the VPN.
The most common place to look for a proxy-ID when a tunnel has been established is in the detail Security Association information. However, if the tunnel is failing, there are some other places to look.
If it is a Route-based VPN, the proxy-IDs are required to be configured as part of the VPN tunnel but if it’s a Policy-based VPN, the proxy-ID is based on the policy which references the VPN (unless the proxy-ID has been manually specified) so you can view the proposed proxy-ID by examining the details of the relevant policy using the following command:
get policy id id
Rejected an IKE packet because there were no acceptable Phase 1 proposals - This error typically occurs if the Phase 1 proposals on both end points do not match.
To obtain the specific proposals being used and expected, simply use the IKE debug.
Rejected an IKE packet because there were no acceptable Phase 2 proposals - This error typically occurs if the Phase 2 proposals on both end points do not match
Like Phase 1 proposal errors, the IKE debug provides full specifics regarding the proposal settings.
Rejected an IKE packet … (The preshared keys might not match.)
It’s safe to say that the preshared keys used by both devices did not match.
Rejected an IKE packet … an initial Phase 1 packet arrived from an unrecognized peer gateway.
Occurs when the outgoing interface for a given VPN has been incorrectly specified e.g. if the Internet facing interface and recipient of VPN traffic is Ethernet3, but the VPN has been incorrectly configured with an outgoing interface of Ethernet1, then this error will occur as the VPN tunnel is expecting the IKE traffic to arrive on Ethernet1.