SonicWall SonicOS Configuration Guide

This is an original planning guide. It is not a vendor manual, an official standard, or legal advice. Example addresses use documentation ranges. Review every command before you paste it.

Where SonicWall SonicOS sits

SonicOS is a zone-based firewall configured in its web administration. Interfaces are X0, X1, and so on, and each belongs to a zone. Policy is from zone to zone. The lab is a hostname, an admin restriction to the management prefix, one LAN zone, one WAN zone, and one narrow rule. Publish the configuration backup before you experiment. The backup is a file you can put back. The running GUI is not a backup.

A CLI from a different firewall will not apply here. The generators on this site describe console steps for this product. Follow the steps as a checklist, not as a paste into an SSH session that does not want them.

Use a lab or the first closet, not the core, for the first week you touch SonicWall SonicOS. The change window still needs a ticket, a test host, and the rollback above. Automation comes after you can do the boring change by hand and get back. The automation guide is that sequence. This page is the dialect.

Management belongs on a prefix you named, over SSH or the platform's equivalent, from a jump host. The hardening guide is the standard. This page does not open Telnet, does not permit the world, and does not put a password in the clear for you to copy. If a generator shows a placeholder password, replace it before the device is reachable.

A lab change, one step at a time

Step 1 on SonicWall SonicOS is about the hostname. The lab text is: Set the hostname to edge-01 in the platform's own command or screen. Logs and VPN peers use this name. This is a starter for a firewall you change in a window with a console path. It uses documentation addresses where an address appears, and it uses the token prompt-for-this wherever a secret would go. Replace that token. Do not save a secret from a guide. After the step, check: The login banner or the prompt shows edge-01.. If the check fails, stop. The way back is: the previous policy you exported, or the platform rollback you have used in a lab. Do not type the next step on top of a failed one. SonicWall SonicOS only keeps a change the way its own save model describes: the platform's commit or save, practised, and not a Cisco write memory unless this platform is the one that uses it. A neighbouring vendor's save command is not this one. The generators linked from this page draft the same kind of starter in the browser. They do not log in. Read their banner, then read this step, then decide. A line that looks familiar from Cisco IOS is not a reason to paste it into SonicWall SonicOS.

Step 2 on SonicWall SonicOS is about management from one prefix. The lab text is: Allow SSH or the admin UI only from 192.0.2.0/24 in this lab, and from your real management prefix in production. A firewall you can administer from the Internet is a firewall you will lose. This is a starter for a firewall you change in a window with a console path. It uses documentation addresses where an address appears, and it uses the token prompt-for-this wherever a secret would go. Replace that token. Do not save a secret from a guide. After the step, check: A test from outside that prefix is refused.. If the check fails, stop. The way back is: the previous policy you exported, or the platform rollback you have used in a lab. Do not type the next step on top of a failed one. SonicWall SonicOS only keeps a change the way its own save model describes: the platform's commit or save, practised, and not a Cisco write memory unless this platform is the one that uses it. A neighbouring vendor's save command is not this one. The generators linked from this page draft the same kind of starter in the browser. They do not log in. Read their banner, then read this step, then decide. A line that looks familiar from Cisco IOS is not a reason to paste it into SonicWall SonicOS.

Step 3 on SonicWall SonicOS is about zones or interfaces. The lab text is: Name the inside and the outside. Do not leave an interface in a zone you did not choose. Policy attaches to zones on the platforms that use zones. A nameless interface is an accident. This is a starter for a firewall you change in a window with a console path. It uses documentation addresses where an address appears, and it uses the token prompt-for-this wherever a secret would go. Replace that token. Do not save a secret from a guide. After the step, check: Each interface is in the zone the ticket names.. If the check fails, stop. The way back is: the previous policy you exported, or the platform rollback you have used in a lab. Do not type the next step on top of a failed one. SonicWall SonicOS only keeps a change the way its own save model describes: the platform's commit or save, practised, and not a Cisco write memory unless this platform is the one that uses it. A neighbouring vendor's save command is not this one. The generators linked from this page draft the same kind of starter in the browser. They do not log in. Read their banner, then read this step, then decide. A line that looks familiar from Cisco IOS is not a reason to paste it into SonicWall SonicOS.

Step 4 on SonicWall SonicOS is about a narrow policy. The lab text is: Permit one inside prefix to one destination and one port. Deny the rest. Any-to-any is not a lab success. It is the absence of a policy. This is a starter for a firewall you change in a window with a console path. It uses documentation addresses where an address appears, and it uses the token prompt-for-this wherever a secret would go. Replace that token. Do not save a secret from a guide. After the step, check: A host outside the rule cannot pass, and a host inside the rule can pass to that one destination.. If the check fails, stop. The way back is: the previous policy you exported, or the platform rollback you have used in a lab. Do not type the next step on top of a failed one. SonicWall SonicOS only keeps a change the way its own save model describes: the platform's commit or save, practised, and not a Cisco write memory unless this platform is the one that uses it. A neighbouring vendor's save command is not this one. The generators linked from this page draft the same kind of starter in the browser. They do not log in. Read their banner, then read this step, then decide. A line that looks familiar from Cisco IOS is not a reason to paste it into SonicWall SonicOS.

Step 5 on SonicWall SonicOS is about a route. The lab text is: Route the inside prefix and a default, or the specific prefix the ticket names, via the next hop you can ping. A policy that permits a prefix you do not route is a policy that never fires. This is a starter for a firewall you change in a window with a console path. It uses documentation addresses where an address appears, and it uses the token prompt-for-this wherever a secret would go. Replace that token. Do not save a secret from a guide. After the step, check: The route matches a test address.. If the check fails, stop. The way back is: the previous policy you exported, or the platform rollback you have used in a lab. Do not type the next step on top of a failed one. SonicWall SonicOS only keeps a change the way its own save model describes: the platform's commit or save, practised, and not a Cisco write memory unless this platform is the one that uses it. A neighbouring vendor's save command is not this one. The generators linked from this page draft the same kind of starter in the browser. They do not log in. Read their banner, then read this step, then decide. A line that looks familiar from Cisco IOS is not a reason to paste it into SonicWall SonicOS.

Step 6 on SonicWall SonicOS is about logs. The lab text is: Log the denies you care about to a server that is not the firewall. A deny you cannot see will be called a routing bug. This is a starter for a firewall you change in a window with a console path. It uses documentation addresses where an address appears, and it uses the token prompt-for-this wherever a secret would go. Replace that token. Do not save a secret from a guide. After the step, check: A test deny produced a log line.. If the check fails, stop. The way back is: the previous policy you exported, or the platform rollback you have used in a lab. Do not type the next step on top of a failed one. SonicWall SonicOS only keeps a change the way its own save model describes: the platform's commit or save, practised, and not a Cisco write memory unless this platform is the one that uses it. A neighbouring vendor's save command is not this one. The generators linked from this page draft the same kind of starter in the browser. They do not log in. Read their banner, then read this step, then decide. A line that looks familiar from Cisco IOS is not a reason to paste it into SonicWall SonicOS.

Step 7 on SonicWall SonicOS is about the save. The lab text is: Commit or save with the platform's command, then export a backup. An uncommitted candidate is not a change. A committed change you cannot restore is a trap. This is a starter for a firewall you change in a window with a console path. It uses documentation addresses where an address appears, and it uses the token prompt-for-this wherever a secret would go. Replace that token. Do not save a secret from a guide. After the step, check: The backup opens on another machine.. If the check fails, stop. The way back is: the previous policy you exported, or the platform rollback you have used in a lab. Do not type the next step on top of a failed one. SonicWall SonicOS only keeps a change the way its own save model describes: the platform's commit or save, practised, and not a Cisco write memory unless this platform is the one that uses it. A neighbouring vendor's save command is not this one. The generators linked from this page draft the same kind of starter in the browser. They do not log in. Read their banner, then read this step, then decide. A line that looks familiar from Cisco IOS is not a reason to paste it into SonicWall SonicOS.

# SonicOS lab checklist, not a paste.
# Hostname edge-01
# Admin from 192.0.2.0/24
# Zones LAN and WAN
# One allow rule, then deny
# Export the settings file before you continue.

After the lab is boring

When the lab hostname, the management address, one user VLAN, and one route or one policy all behave, write the rollback and the save command on a card next to the console. The on-call will not reread this pillar at 2 a.m. They will read the card. If the card disagrees with this page, fix the card after you confirm which one matches the software version you run. Versions drift. A command that worked on the previous train may be refused or may mean something narrower.

Back up the configuration once you have saved it the platform's way. Keep that backup off the device. A device you can rebuild from a backup is a device you can harden without fear. A device whose only configuration is the running memory is a device people are afraid to secure, so they leave extra services on. The hardening pass comes after the backup exists, not before.

Compare the generator's draft to this lab before you point the generator at a real site. The draft should be smaller than your wish list. A VLAN, a management restriction, and a route are enough for a first production use. A draft that also turns on every feature the form offered is a draft to trim. The diff is the change. The vendor guide is not a reason to apply every example in one window.

Document the software version, the save command, and the out-of-band path in the same inventory line as the hostname. Migrations fail when that line is missing. The migration guide assumes you can still reach the box when the new path is wrong. SonicWall SonicOS does not suspend that rule.

SonicWall SonicOS checks before the first production save

Confirm this before you call the change done: The lab is not the production core. prompt-for-this was replaced and the secret is not in the ticket. Management is limited to a named prefix. The save command on the card matches SonicWall SonicOS, not a different vendor. A backup exists off the device before you harden it. The test host is in the VLAN you built, and a host outside it was not accidentally included. The rollback was used once in the lab. The generator draft was trimmed to the ticket. No route or policy permits the world as a convenience. Documentation prefixes are gone before production cutover. The software version is written next to the hostname. Out-of-band access was tested. A second person read the allowed VLAN or the policy aloud. And telnet and any wide web management stay off. If one of those fails, stop.

Tools for this guide

These tools run in the browser on this site. They do not log into your machines.

Guides in this cluster

These supporting pages belong to this pillar.