Skip to content
Notifications
Clear all

Anyone actually using SonicWall in production for a 5-site deployment?

2 Posts
2 Users
0 Reactions
6 Views
(@terraform_tinkerer_2026)
Eminent Member
Joined: 2 months ago
Posts: 11
Topic starter   [#2653]

Okay, I'll admit I'm coming at this from a bit of a different angle. My usual world is defining infrastructure declaratively with Terraform, where everything is reproducible and version-controlled. So when we had to standardize firewalls across five regional offices (roughly 200 users total), the idea of manually configuring each SonicWall via the GUI felt...archaic. But management was set on SonicWall, so I dove in.

We went with NSa 2700s at the main site and smaller 270s at the branches. The goal was a hub-and-spoke VPN (Site-to-Site IPsec) with consistent security policies. Here’s the raw experience:

**The Good:**
* **VPN Mesh was surprisingly smooth.** Once the main site was configured, bringing up tunnels to the four branches was straightforward. The built-in wizard gets you 80% there.
* **Hardware is solid.** No complaints on throughput or uptime. They just run.
* **Centralized Management (NSM) is a lifesaver.** This is non-negotiable for a multi-site setup. Being able to push policy updates, firmware, and monitor all boxes from one pane is essential. Without it, you'd be SSH-ing into each one individually.

**The Pain Points (where my IaC soul aches):**
* **Configuration Drift is a real threat.** There's no native "configuration-as-code" for the devices themselves. I've resorted to a manual process of exporting the `.exp` (export) config files from each appliance after any change and storing them in a Git repo. It's a poor man's version control, but it's saved us a few times.
* **API is...limited.** They have a REST API, but it's not fully featured for all configuration aspects. I tried writing some Terraform provider integrations for basic tasks, but it felt like pushing a boulder uphill. Most complex objects still require the GUI or their CLI.
* **The CLI is its own beast.** It's not SSH; it's a proprietary serial-like interface. You can script some things, but it's not like working with a Linux box. Example of a simple CLI snippet to check a tunnel status (you'd need to expect-style script this):

```
show vpn ipsec sa
```

**The Big Question:**
For anyone else running a similar setup: **how are you handling configuration consistency and drift?** Are you using NSM exclusively and trusting its templates? Have you found a way to properly version-control your SonicWall configs, or are we all just crossing our fingers and keeping good backups?

The Terraform part of me dreams of a day where I could define a security rule like this and have it apply to all my firewalls:

```hcl
resource "sonicwall_security_rule" "allow_web" {
name = "Allow_HTTPS_Outbound"
source_zone = "LAN"
dest_zone = "WAN"
service = "HTTPS"
action = "Allow"
}
```

But we're definitely not there yet. The operational overhead of managing five sites is manageable, but it feels inherently fragile compared to my cloud-native workflows.



   
Quote
(@tom_w_analytics)
Eminent Member
Joined: 4 months ago
Posts: 19
 

Hold up. You're praising NSM as a lifesaver? That's the part I need to see proof on.

From where I'm standing, NSM is the thing that *creates* the IaC problem you're hinting at. It's another proprietary, GUI-heavy layer that locks you in further. You can't diff configs meaningfully, rollbacks are a nightmare, and good luck scripting a complex policy change across those five sites without clicking through a dozen wizards.

If your configs are "reproducible" in NSM, show me the git repo. Otherwise, you've just traded five CLI boxes for one CLI box that happens to have a web interface for managing the other five.


Tom W.


   
ReplyQuote