SonicShield security appliances in the Server Room open into a full management GUI running ShieldOS, reached over HTTPS the way you would reach a real appliance. It is the console you use when a problem is a policy problem rather than a client problem: a service that is blocked, a subnet with no route, a tunnel that is down, or a guest network behaving as though it can see something it should not.
The appliance opens on system information — model, serial, firmware version, uptime, appliance health, the WAN interface address, and how many VPN tunnels are currently up. This is the same orientation step a technician takes on real hardware, because the firmware version and the tunnel count answer a surprising number of questions before you touch anything.
What the appliance exposes
- Interfaces — the physical and logical interfaces, their zone, address, and speed and duplex.
- Zones — traffic is organised into zones such as WORKSTATIONS, SERVERS, WLAN and GUEST, which is what makes an access rule readable rather than a list of raw addresses.
- Access Rules — the ordered allow and deny policy, with source, destination, service and state.
- Routing — the static routes, each with its destination, subnet mask and gateway.
- VPN — site to site tunnel policies, including their negotiation settings and current state.
- Users and Administrators — the accounts that can authenticate to the appliance.
- Directory server — the LDAP integration, including the bind account used to look users up.
- Threat log — recent security events, such as an inbound TCP SYN scan that was blocked on the WAN interface.
Access rules are editable, not just readable. You can add a rule with its own name, source and destination, service and action, and you can enable or disable an existing rule to test whether it is the one causing a symptom. Routing works the same way: you can add a static route or delete one that is sending traffic to a gateway that no longer exists. VPN policies can be brought up or taken down so you can see the effect on the tunnel count and on the sites behind it.
The most important behaviour in this console is that changes are staged rather than applied instantly. Editing a rule or a route puts the appliance into a state where the running configuration has uncommitted changes, and the header says exactly that. Nothing takes effect until you commit the configuration, at which point the header switches to showing when the configuration was last committed. This mirrors how real appliance management works, and it means an unfinished edit cannot silently become production policy while you are still thinking about it.
Committing is also where authorisation applies. The commit control is disabled unless the incident linked to that appliance is assigned to you, and hovering it explains that you need to assign the linked incident before changes can be made. You can therefore always inspect an appliance to understand a problem, and you can only change one when a ticket gives you a reason to. That distinction between looking and changing is deliberate, and it is the same boundary the directory and endpoint consoles enforce.
Quality of service settings are present as well, including voice priority and guaranteed bandwidth, which matters because the estate contains IP phones. A call quality complaint is not automatically a phone fault, and this console is where the alternative explanation lives.
Everything here is the same simulated state the rest of the product reads. A deny rule you add genuinely blocks the traffic it describes, a route you delete genuinely breaks the path it served, and a workstation affected by either will show the symptom to the user sitting at it. That is what makes the console worth using rather than reading: the policy is not an illustration of a policy, it is the thing actually deciding what works.