Sonicwall firewalls are all capable of supporting site-to-site VPN connections to other firewalls and each firewall model has a specified maximum number of tunnels that it can support.  From 5 tunnels on a TZ105 through to 10,000 on the SuperMassive Series (ooooo, I want one of these for Christmas!!!!), they all work in the same fashion.  For the rest of this discussion I’ll focus on Sonicwall-to-Sonicwall VPN’s but the gist holds true regardless.

When you create a site-to-site VPN connection (VPN Policy) between Sonicwalls you define the subnets behind each Sonicwall that will be accessible over the VPN connection.  Each Sonicwall needs to understand what subnets are available over the VPN connection from the other Sonicwall.  This is pretty straightforward and it is configured as part of the VPN policy on the Network tab within the Policy itself.  What may be a bit surprising is that the VPN link that is created *might* actually be displayed as more than one VPN tunnel on each Sonicwall.  In essence, there is a “tunnel” created on each Sonicwall between each network on the local Sonicwal that is included in the VPN policy and each network on the remote Sonicwall that is included in the policy.  This means that you might see a whole bunch of tunnels listed on a Sonicwall when you might only have one site-to-site VPN Policy in place between two Sonicwalls with multiple networks involved on each side of the VPN.  This is important to keep in mind as it is the total number of tunnels that you need to track; it is this number that you have to line up against the maximum number of tunnels that a given Sonicwall model supports.  You can end up with no where to go and your cap in hand having to beg for more money for a bigger firewall if you don’t plan your capacity correctly.

Case in point:  I have a customer that has 4 locations;  there are now four Sonicwalls in place; one in Victoria, one in Richmond, one in Nanaimo and one at the owner’s house.  From the point of view of Victoria (main office with a NSA 250MW) that means there are three VPN policies in place, one to each of the remote sites and that is indicated in the VPN Policies listing:

image

But, as you can see, two of those sites have multiple networks that are available across the VPN; Richmond has three and Nanaimo has two.  Keep in mind that Victoria offers up two networks across the VPN back to all the other sites and you can do the math.  There should be:

  • 2 tunnels to Home — 2 [Victoria] x 1 (House]
  • 6 tunnels to Richmond — 2 [Victoria] x 3 [Richmond]
  • 4 tunnels to Nanaimo – 2 [Victoria] x 2 [Nanaimo]

And that adds up to 12 tunnels in all.  Not surprisingly, that is what we see under the Active Tunnels list:

image

Each tunnel lists the associated local and remote networks.  There is a reverse-match on the appropriate remote Sonicwall.  As this particular unit is an NSA250MW it supports 50 tunnels so I have used up 12 of those 50 tunnels. Lots of headroom left on this box.  But keep in mind I used up 12 tunnels provisioning 3 site-to-site VPN policies.

However, in Nanaimo I have a TZ105W which supports 5 tunnels and I have used 4 up already and I have only provisioned one site-to-site VPN policy!  If the customer wanted me to plug in Richmond to this site and provision similar connections as between Richmond and Victoria I would be dead in the water as I simply would not have the headroom on the box to do it.  Thankfully that is not an issue as that is not something my customer wants to do.

I think you can see where this is going … you need to give consideration to what your overall connectivity plans are when you are spec’ing your firewall choice.  While you might have a small office with limited devices behind the firewall and, therefore, you lean towards a smaller box (say a TZ105), you should think about the bigger picture.  In other words, don’t just think of the firewall as a mere “security endpoint”, think about how it fits into your overall plans.  It is cheaper and better to “do it once and do it right” up front than to end up scrambling and have to replace a relatively new firewall because you didn’t do your sizing calculations.

Sonicwall Site-to-Site VPN Tunnel Counts–Something to keep in mind when you are sizing the firewall
Tagged on:     

2 thoughts on “Sonicwall Site-to-Site VPN Tunnel Counts–Something to keep in mind when you are sizing the firewall

  • I am not sure if this is still accurate. I have a NSA 2600 which is supposedly locked at 75 tunnels max when I read this article. But I am now using 85 tunnels since I have multiple locations linked to each other and many networks on each locations. What I see in the VPN section on my sonic wall is this: Site To Site Policies: 10 Policies Defined, 8 Policies Enabled, 75 Maximum Policies Allowed. It seems each of my VPN policies count and not necessarily the numbers of tunnels in each policy. My appliance reports this amount of tunnels: 85 Currently Active VPN Tunnels.

    That is a big relief as we “downgraded” from a NSA 3500 to an NSA 2600 and I never thought that this issue could come up…

    1. Lauren:
      Thanks for your comments!

      It may depend on how you set up the VPN’s, to be honest. Policy based routing seems to do the tunnels thing quite a bit differently from the way things are handled doing it the “quick and dirty” way that I describe in this article. I also never get to touch the bigger models (like your 2600, biggest I have in my fleet are NSA250MW’s and now some of the new TZ300’s and 400’s. Maybe things license differently on the bigger boxes.

      Robert

Leave a Reply

Your email address will not be published. Required fields are marked *