Solved

Sonicwall PRO 330 dropping VPN connection at Phase 2 Negotiation

Posted on 2004-09-15
13
13,602 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
MIM Survival Guide for Service Desk Managers

Major incidents can send mastered service desk processes into disorder. Systems and tools produce the data needed to resolve these incidents, but your challenge is getting that information to the right people fast. Check out the Survival Guide and begin bringing order to chaos.

 
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

When ransomware hits your clients, what do you do?

MSPs: Endpoint security isn’t enough to prevent ransomware.
As the impact and severity of crypto ransomware attacks has grown, Webroot fought back, not just by building a next-gen endpoint solution capable of preventing ransomware attacks but also by being a thought leader.

Question has a verified solution.

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

Wikipedia defines 'Script Kiddies' in this informal way: "In hacker culture, a script kiddie, occasionally script bunny, skiddie, script kitty, script-running juvenile (SRJ), or similar, is a derogatory term used to describe those who use scripts or…
To setup a SonicWALL for policy based routing to be used with the Websense Content Gateway there are several steps that need to be completed. Below is a rough guide for accomplishing this. One thing of note is this guide is intended to assist in the…

738 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