Solved

Sonicwall PRO 330 dropping VPN connection at Phase 2 Negotiation

Posted on 2004-09-15
13
13,578 Views
Last Modified: 2013-11-16
I am having a problem with a VPN connection on a  Sonicwall PRO 330.  It seems to be failing at Phase 2 negotiation.  If I click the renegotiate button for the VPN tunnel, I lose the tunnel.

If I change the Phase 2 Encryption/Authentication to Tunnel Only (ESP Null), Ping the peer internal IP address and then change Phase 2 Encryption/Authentication back to Strong Encrypt and Authenticate (ESP 3DES HMAC MD5), ping the peer IP again..... the tunnel comes back up.  

This happens on a daily basis....

We recently converted our internal IP addresses from a 192. network to a 10. network and upgraded our Pro 330 firmware to 6.6.0.6



09/15/2004 07:30:51.896 -       IKE Initiator: Start Quick Mode (Phase 2). -       Source:208.17.69.11 -       Destination:208.1.59.73 -        -       
09/15/2004 07:30:52.016 -       Received unencrypted packet while crypto active -       Source:208.1.59.73 -       Destination:208.17.69.11 -        -       
09/15/2004 07:30:52.016 -       Received notify: INVALID_COOKIES -       Source:208.1.59.73 -       Destination:208.17.69.11 -        -       
09/15/2004 07:30:56.560 -       Received unencrypted packet while crypto active -       Source:208.1.59.73 -       Destination:208.17.69.11 -        -       
09/15/2004 07:31:04.688 -       Received unencrypted packet while crypto active -       Source:208.1.59.73 -       Destination:208.17.69.11 -        -       
09/15/2004 07:31:29.192 -       IKE Initiator: Start Main Mode negotiation (Phase 1) -       Source:208.17.69.11 -       Destination:208.1.59.73 -        -       
09/15/2004 07:31:29.912 -       IKE Initiator: Main Mode complete (Phase 1) -       Source:208.17.69.11 -       Destination:208.1.59.73 -       "3DES MD5  Group 2 lifeSeconds=86400 " -       
09/15/2004 07:31:29.912 -       IKE Initiator: Start Quick Mode (Phase 2). -       Source:208.17.69.11 -       Destination:208.1.59.73 -        -       
09/15/2004 07:31:30.048 -       Received IKE SA delete request -       Source:208.1.59.73 -       Destination:208.17.69.11 -        -       
09/15/2004 07:31:35.192 -       Web management request allowed -       Source:10.1.5.6, 2595, LAN -       Destination:10.1.1.254, 80, LAN -       Web (HTTP) -       
09/15/2004 07:31:35.192 -       Web access request dropped -       Source:10.1.5.6, 2595, LAN -       Destination:10.1.1.254, 80, LAN -       Web (HTTP) -       Rule 6
09/15/2004 07:31:54.032 -       IKE Initiator: Start Main Mode negotiation (Phase 1) -       Source:208.17.69.11 -       Destination:208.1.59.73 -        -       
09/15/2004 07:31:54.736 -       IKE Initiator: Main Mode complete (Phase 1) -
0
Comment
Question by:jlavetan
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 7
  • 5
13 Comments
 
LVL 1

Author Comment

by:jlavetan
ID: 12067105
Anyone???
0
 
LVL 7

Expert Comment

by:LimeSMJ
ID: 12072559
I have no experience with the newer SonicWall Ffirewall/VPN hardware but these may help if you haven't looked at them already:

Here's a SonicWall tech doc regarding IKE VPNs:
http://www.sonicwall.com/services/pdfs/technotes/Troubleshooting_Guide_IKE_VPN_Initialization_rev0.pdf

Excerpt from their Knowledgebase:
There was a problem noted in v6.4.2.0 firmware where IKE VPN tunnels could be dropped when using Dead Peer Detection. With this bug, Dead Peer Detection dropped VPN SAs at renegotiation of the tunnel due to the Invalid_Cookies error. This problem has been fixed in v6.5 firmware.
--> You might want confirm that your firmware update was successful since you did mention you upgraded it.

Hopefully these help...
0
 
LVL 1

Author Comment

by:jlavetan
ID: 12073719
Actually, it is failing at Phase 2 negotiation.  The SA lifetime on both units (Sonicwall on our side, Cisco 3005 on the other end) is set to 86400 (24 hours).  This happens to be the same time that the connection drops.  There is a problem when it starts to renegotiate the connection.
0
Surfing Is Meant To Be Done Outdoors

Featuring its rugged IP67 compliant exterior and delivering broad, fast, and reliable Wi-Fi coverage, the AP322 is the ideal solution for the outdoors. Manage this AP with either a Firebox as a gateway controller, or with the Wi-Fi Cloud for an expanded set of management features

 
LVL 5

Accepted Solution

by:
idyllicsys earned 175 total points
ID: 12204874
jlavetan,

 What it looks like from the logs is that the Cisco keeps sending an unencrypted packet during the negotiation.

Try the following. Reduce the SA lifetime to 28800. You won't notice a difference. See if it drops off at that point. Then try dumbing down the connection. Use DES, if possible. Also use SHA1. It is a better method than MD5.

If this doesn't work,  delete and recreate the SA. I have had trouble with some when I get the Invalid Cookies error and that is the easiest fix for it.

Let me know if it works. I don't have much experience with Cisco but I do with SonicWall

Ted
0
 
LVL 1

Author Comment

by:jlavetan
ID: 12307532
The Sonicwall is not renegotiating the connection.  The SA lifetime is set for 86400 (24 hrs), but is going down at 64800 (18 hrs).  The guy on the Cisco side has assured me that his lfetime is set to 86400.  When I manually renegotiate the connection by clicking the "Renegotiate" button on the Sonicwall, I get an INVALID_COOKIE error.  

When the connection goes down.....

If I change the Phase 2 Encryption/Authentication to anything other than

Strong Encrypt and Authenticate (ESP 3DES HMAC SHA1) -- the current setting--

and then ping the Cisco internal IP

then change the Phase 2 Encryption/Authentication back to Strong Encrypt and Authenticate (ESP 3DES HMAC SHA1)

then ping the Cisco internal IP

The tunnel comes back up for another 18 hours.....


Nothing seems to be working.......
0
 
LVL 1

Author Comment

by:jlavetan
ID: 12360100
The connection is still kind of unstable, but changing it to SHA1 does seem to be working better than MD5
0
 
LVL 5

Expert Comment

by:idyllicsys
ID: 12360329
Have you lowered the SA time yet? try it at 28800.  you won't notice it renegotiating. The only time you make the sa lifetime that long is on slower connections.
0
 
LVL 1

Author Comment

by:jlavetan
ID: 12360377
actually it's set at 46800 and seems to be staying up for now.  I think the problem was the Cisco side had a different lifetime and was closing the connection before the Sonicwall knew about it.  If the connection went down and I waited until the Sonicwall renegotiated it by itself it has no problem coming back up.
0
 
LVL 5

Expert Comment

by:idyllicsys
ID: 12360512
Glad to here. Let us know if you have anymore issues
0
 
LVL 1

Author Comment

by:jlavetan
ID: 12410852
OK, the tunnel is still going down....  

It seems like the Cisco is dropping the connection and the Sonicwall doesn't know about it. The Sonicwall will re-negotiate the connection at the end of the SA Lifetime and the tunnel comes back up.

I have tried to set the SA lifetime on the Sonicwall to different intervals, but the Cisco is always dropping the connection several hours before the SA lifetime expires.

No matter what the SA lifetime is set to, the Cisco drops the connection several hours before the end of the SA lifetime.

It also seems like the connection seems to slowly degrade until it finally fails.  Ping times get longer and longer until the connection finally drops.....

0
 
LVL 5

Expert Comment

by:idyllicsys
ID: 12418189
what is the lowest you have set the SA times?

Have you tried 3600 seconds?
0
 
LVL 1

Author Comment

by:jlavetan
ID: 12421296
I did lower the SA lifetime, but the Cisco dropped the tunnel 14 minutes before the renegotiation.  The tunnel was supposed to be valid from 7:37AM (EDT) to 8:37AM (EDT).... The Cisco dropped it at 8:23AM
0
 
LVL 5

Expert Comment

by:idyllicsys
ID: 12422358
Wow. What kind of connections are on both sides?

Try this. Keep the Cisco at 3600 and drop the SOnicWall to 1800. Can't hurt to try.
0

Featured Post

On Demand Webinar - Networking for the Cloud Era

This webinar discusses:
-Common barriers companies experience when moving to the cloud
-How SD-WAN changes the way we look at networks
-Best practices customers should employ moving forward with cloud migration
-What happens behind the scenes of SteelConnect’s one-click button

Question has a verified solution.

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

If you are like regular user of computer nowadays, a good bet that your home computer is on right now, all exposed to world of Internet to be exploited by somebody you do not know and you never will. Internet security issues has been getting worse d…
This article offers some helpful and general tips for safe browsing and online shopping. It offers simple and manageable procedures that help to ensure the safety of one's personal information and the security of any devices.
Exchange organizations may use the Journaling Agent of the Transport Service to archive messages going through Exchange. However, if the Transport Service is integrated with some email content management application (such as an antispam), the admini…
Attackers love to prey on accounts that have privileges. Reducing privileged accounts and protecting privileged accounts therefore is paramount. Users, groups, and service accounts need to be protected to help protect the entire Active Directory …

756 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