1

Some of the SonicWalls that I have deployed for my organization’s remote locations rely on a cellular service provided by Sierra Wireless devices for an internet connection, since these locations are so remote the connection will drop obviously disconnecting the VPN tunnel. The internet will eventually reconnect itself but I must travel to the location, connect to the network, and ping back to the office to get the VPN to reconnect.

I have enabled Keep Alive on the remote SonicWall only and enabled Dead Peer Detection, the Sierra Wireless devices are configured for IP passthrough to to SonicWall’s WAN port but I’m unsure if this would prevent the VPN from reconnecting since the internet works every time I go onsite. Any suggestions for this issue are greatly appreciated

4 Spice ups
2

I’m not sure I follow the scenario, let me ask a couple clarifying questions as well as suggestion. You have remote sites with SonicWalls running site-to-site (IPSEC) tunnels, or client (SSL) connections?
Do you have any devices at these sites? I assume you do, otherwise why would you would not need to have connectivity.
When you go on site, physically plug in, and execute a ping back to HQ, the SonicWall reconnects and everything resumes normal operation? Can you set up a scheduled task to ping HQ from one of the devices on site? Perhaps every 5 minutes send a ping, that way your longest down time would be 5 minutes.

4 Spice ups
3

Sorry, I should have clarified. Yes, I am running site-to-site IPSEC tunnel connections from a NSa 2700 to the remote TZ80 sonicwalls. The devices connected to the sonicwalls are SCADA and metering equipment to allow system reporting and remote meter reading. You are correct, whenever I go and connect to the local network and ping back to our main office operations will immediately resume as normal. I must have misunderstood the function of keep alive as I thought the remote Sonicwall would ping back to the office to ensure the tunnel would stay operational, I can look at scheduling a ping every 5 minutes and see if that solves the problem.

2 Spice ups
4

I agree with you, the idea that the word ‘keepalive’ brings to mind is a method to keep the connection alive instead of letting it stagnate or drop. I admit I’ve never quite grasped the actual application of keepalive on SonicWall, so I can’t give you insight.
Try the ping, let us know. It feels like a hack, but it is simple and if it works then I guess that is good.

2 Spice ups
5

Is dead peer detection enabled on the central SW? this should clear the vpn when the remote site goes down.
On SW traffic is required to establish VPN. So you will need some regular traffic - do you monitor the remote sites etc?

3 Spice ups
6

I ensured that dead peer detection is on at the central SW, I would think that the normal SCADA and meter traffic from the LAN side of the remote SW would suffice to generate enough traffic to keep the tunnel alive but clearly I am wrong. I am looking at setting up a Network Monitor to ping the central SW through the VPN tunnel as @AdmiralKirk suggested but am having a hard time to get the traffic to route through the tunnel. Looking into it more and have found others with similar issues but have yet to find a definite resolution.

7

How does the SCADA traffic go through the tunnel but a ping does not? Or is that the million dollar question?
What device are you using to create those pings?

8

That is the million dollar question, whenever I use the Ping Diagnostic tool it shows that the central SW is currently alive and responding since it is online right now but when using the Network Monitor tool within the remote SW to schedule pings it shows failed. I have tried multiple routing options to solve this like many others have but it does not seems to change anything… I would try to generate pings from a normal computer system instead of the SW but since this equipment is in a field box bolted to a telephone pole there aren’t any typical computer systems at these locations. I’ll see if my engineer or meter guys can do any functions related to this with their equipment to see if that might solve the problem.

9

Yeah, dealing with flaky cellular links in remote areas can be a real pain. We’ve run into something similar on a few sites. One thing that helped was scripting periodic outbound traffic (like a curl to a known IP) from the SonicWall to keep the tunnel active when idle traffic wasn’t enough. You can also try setting up a cron job on a downstream device to ping the head-end to reinitiate the connection.

Sometimes with IP passthrough configs on Sierra Wireless gear, the modem might not fully re-establish the route properly after reconnecting; especially if the SonicWall has already marked the peer as dead. Might be worth checking if the cellular modem supports any sort of watchdog or link check feature that can trigger a full modem reset or DHCP refresh on drop.

Also, if you’re doing centralized management or logging, it helps to have the VPN config tied into something that can alert you or even auto-trigger reconnection logic remotely. There are some solutions out there that provide that layer of automation and secure oversight, which can make a big difference when physical access is a hassle. Let me know what kind of visibility you already have into those tunnels and I can share what we’ve tried.

1 Spice up
10

What Sierra Wireless devices are you using? I skimmed over that part of your initial post, focusing instead on the SonicWall. The idea I’m having here is can your Sierra device carry the VPN and eliminate the need for the SonicWall? I’m brand spanking new at my current role and I’m in charge of 200 Sierra devices, and it looks to me that they are capable of all your connectivity needs without having to add another device.

What is the target of your pings, both when you hook up your laptop and with your current test?

I’ve never tried this approach, but what if you set up the VPN to be a client instead of a site-to-site? I’m not even sure SonicWall supports that model.

11

It is tricky, I have now looked into numerous ways to automate outbound pings but each doesn’t seem to send traffic through the VPN which is very weird… I do believe that the Sierra Wireless devices have a watchdog function to them, I will have to check next time I’m am at the remote location. In the since of management I normally have the ability to access each SW remotely, this problem is only present on a few of our devices since so many are on our fiber network and most of the devices I’m speaking about now will be on fiber within the next year and half. I’ll need to look into those auto-trigger reconnection methods and see if I could implement something like that until we get a more dependable connection to these locations.

12

I have deployed the AirLink RV55X devices. I do know of a VPN function but was unsure of the security related to these, a big reason we are using the Sonicwalls at these remote locations as well is simply what I was trained to do. I got 4 days with the last IT guy before he left and he showed me very little, I’m alone IT wise so I stay pretty busy but have been slowly rolling out some improvements to how things are set up.

The target of my pings is the same, the LAN IP of the HQ sonicwall, works for the laptop ping and when using the ping diagnostic tool, not for network monitoring.

I can look into the client VS site-to-site options and see if that would make sense for our setup but I would need to travel to the remote location before I could implement that change.

13

I hear you about limited training time, and about being a one-man show.

Here’s a new angle: are your cellular IPs static or dynamic? If they are dynamic then your tunnel could drop at any time.

14

Sorry for the delay @AdmiralKirk other problems presented themselves that I have to take care of and in the time being the tunnels dropped! To answer your question, we have ensured to get static IP addresses for the Sierra Wireless devices and I have confirmed that these devices have been configured appropriately by the service provider to be static.

1 Spice up