Solved

Sonicwall PRO 330 dropping VPN connection at Phase 2 Negotiation

Posted on 2004-09-15
13
13,494 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
  • 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
 
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
PRTG Network Monitor: Intuitive Network Monitoring

Network Monitoring is essential to ensure that computer systems and network devices are running. Use PRTG to monitor LANs, servers, websites, applications and devices, bandwidth, virtual environments, remote systems, IoT, and many more. PRTG is easy to set up & use.

 
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

PRTG Network Monitor: Intuitive Network Monitoring

Network Monitoring is essential to ensure that computer systems and network devices are running. Use PRTG to monitor LANs, servers, websites, applications and devices, bandwidth, virtual environments, remote systems, IoT, and many more. PRTG is easy to set up & use.

Question has a verified solution.

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

Suggested Solutions

Title # Comments Views Activity
assessing firewall rules 3 81
can't ping datacenter from only one server in office 10 71
increase internet speed 3 83
SQL Server Firewall Rules... what am I missing here? 3 59
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.
This Micro Tutorial will give you a basic overview how to record your screen with Microsoft Expression Encoder. This program is still free and open for the public to download. This will be demonstrated using Microsoft Expression Encoder 4.
With the power of JIRA, there's an unlimited number of ways you can customize it, use it and benefit from it. With that in mind, there's bound to be things that I wasn't able to cover in this course. With this summary we'll look at some places to go…

896 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

Need Help in Real-Time?

Connect with top rated Experts

11 Experts available now in Live!

Get 1:1 Help Now