Clone the default LAN to WAN rule? Sure, but treat it as a lab specimen, not your real config. Don't touch your main network yet.
Get a cheap router or a spare machine, set up a mini test lab. Build two rules from scratch there: one allow for your test machine to Google DNS with every single security service checkbox cleared. One deny rule below it.
That's your first working policy. It proves you can make traffic flow and stop on command. Then you can graft on the real services like Geo-IP filtering.
The gotcha is thinking you need a "starter set" of 5 security services right away. You don't. Get the traffic routing correct first, then add one service at a time and test. Your Slack will thank you.
Demo or it didn't happen
You're getting a lot of good, fundamental advice here. But coming from an automation background, you're probably itching for a repeatable, atomic test you can script later. Let me give you a concrete, three-line config you can literally copy tomorrow morning.
My first working policy was just this:
* **Rule 1:** Allow from `MyLaptop_IP` to `8.8.8.8`. Security Profile: `None`.
* **Rule 2:** Deny from `MyLaptop_IP` to `1.1.1.1`. Security Profile: `Default`.
* **Rule 3:** Allow from `LAN Subnet` to `WAN`. Security Profile: `Default`.
The magic isn't in the rules, it's in what you do next. You watch the live logs and confirm Rule 1 and 2 hit, in that order, and Rule 3 is never touched for your test IP. That validates precedence. *Then* you add a single security service like Geo-IP to Rule 2 and see the log reason change.
That's your foothold. It's a unit test for the policy engine itself. Once that passes, you can start building your real policies for Slack and Google, knowing the foundation is sound. Skip cloning a template until you've passed this test - otherwise you're debugging on a house of cards.
pipeline all the things
You're getting great advice about building from zero to understand the flow. For someone with an automation background, I'd actually skip the GUI for the first test.
Can you SSH into the SonicWall? Set up those two tiny rules via the CLI first, a simple allow and a deny. Then immediately tail the logs. Seeing the policy lookup happen in real-time gives you a much clearer mental model of the rule engine than clicking through menus. The GUI makes everything look like a monolithic block, but the CLI shows you the discrete checks.
That initial "working config" is just proving the policy tree evaluates in order. Once you've seen that, you can script the rest.
Automate everything.
That CLI point is a game changer for understanding the flow. I would've never thought to start there. It's the difference between reading a flowchart and watching the machine execute each step.
But I'm curious about the real-world transition. How do you map the clean mental model from the CLI back to the GUI's security profiles? Is it just a case of knowing each checkbox is one of those discrete checks you saw, or do things get grouped together differently?