[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1363
  • Last Modified:

Dropped packets over established VPN's on Sonicwall NSA 240 renegotiate fixes the problem

I have two NSA 240 Sonicwall's on version 5.X OS. These SonicWalls are configured for High Availability and are using stateful failover and also have the Virtual MAC option on so they share the same MAC address.  I have over 80 of these in our network but this specific site is giving me problems.

The issue is every 9 to 13 hours traffic stops flowing over the VPN connections. The VPN's are up (Green ball) and there are not eroneous log message at all to indicate a problem. Pings stop going through and so does other traffic. If I simply renegotiate the VPN's traffic picks up again for another 9 - 13 hours. The failure is anywhwere in that time frame.

I ran a packet capture an I can tell that the packets are definatley being dropped. I have attached the packet trace that I did, where I issued pings from the remote end to the destination where these 240's are and than reset the VPN connections in the middle of the trace. Packets . You'll see packets 1 thru 12 are prior to the VPN renegotiation and packets 13+ are immediatley after the renegotiation when things start to go through again.  The only thing that looks suspicious to me is the mac addresses during the drop and the 'HP' switch that is involved in the drop. I am wondering is using virtual mac'ing could be causing this or if anyone has seen this before.  These devices are a customer location and I do not control the HP switch. I only terminate into in on the X0(Lan side)

Strange that it's every 9 - 13 hours randomly. Wondered if anyone had any suggestions or has seen this before.

PacketCap-04262009.txt
0
svasilakos
Asked:
svasilakos
  • 2
4 Solutions
 
KevinCovertCommented:
do you have 'enable keep alive' enabled on this tunnel?  I've had to use that setting when connecting my NSA 2400's to Cisco PIX/ASA's.

I've not seen this, but I would check that first.

This is an odd one, is sonicwall tech support any assistance?

I'd like to hear the end of this story, got my interest peaked.

KMC
0
 
apostle12Commented:
When doing site to site VPN's you have to use the "unique indentifier" as the name of the tunnel. In other wordsthe sonic wall you are sitting at make the name of the tunnel the unique name of the sonicwall you are connecting to. Next you need to change the mode of the tunnel to aggressive, set the default gateway's ip to 0.0.0.0 and do the same on the other end. In the box that says local IKE put your sonicwall unique name and the remote IKE put the remotes sonicwall unique name.
0
 
QlemoC++ DeveloperCommented:
apostle12,
a site-to-site tunnel is almost never in aggressive mode. Aggressive mode is useful only if you have no static IP addresses available, and in most cases it doesn't work with dynamic IP on both sides.
Is that a special "feature" of SonicWall?
0
 
QlemoC++ DeveloperCommented:
svasilakos,
I don't know for SonicWall devices, but that symptom normally is a sign of missing renegotiation of expired SAs, because SA lifetime option is not honoured. Sounds strange, if both sides are using a SonicWall. But you could try out by setting a shorter lifetime on both sides (some minutes, e.g.). This should lead to packet drop much earlier.
0

Featured Post

A Cyber Security RX to Protect Your Organization

Join us on December 13th for a webinar to learn how medical providers can defend against malware with a cyber security "Rx" that supports a healthy technology adoption plan for every healthcare organization.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now