Connecting
your SonicWall.

01 / Before configuration

Gather the service details.

Confirm the handoff location, port and optic requirements, cable, operational speed, and any specified VLAN, MTU, negotiation or FEC settings. Obtain the actual address, prefix or mask, gateway and routed-block instructions from the service order. Confirm which team manages each device.

Virtual wire or transparent modes, dynamic routing, multiple providers, and upstream routers require different steps. This guide does not replace the organization’s approved design.

02 / Physical connection

Check the link first.

Connect the agreed data port using supported optics and cabling. Compare operational link state and speed on both sides. If a switch or router sits between the firewall and provider, check each interface on that path. A link can be up while VLAN, MTU, or routing settings are wrong.

03 / WAN interface

Assign the external interface.

For a SonicOS 7 example, open Network → System → Interfaces, edit the agreed WAN data interface, and confirm the WAN zone and static IP assignment. Enter the provider-assigned address and subnet mask. X1 is commonly used for WAN but is only an example; check your device and service handoff.

Configure the internal interfaces and address ranges according to the existing LAN design. If the handoff uses a VLAN, use the agreed tagging and interface design rather than assuming an untagged port.

04 / Routing

Set the path to the provider.

In a static-WAN design, the interface setup includes the provider’s default gateway. For illustration only, the firewall might use 198.51.100.2/30 with 198.51.100.1 as gateway. These are reserved documentation addresses, not usable Stealth assignments. Enter the actual IP, subnet mask, and gateway from the service order.

Review active routes, policy routing, failover, and load balancing before changing an existing gateway. A DHCP service may obtain its addressing differently. IPv6 has separate addressing and routing requirements; follow the provisioned design and the documentation for the appliance.

05 / Security policy and NAT

Allow the intended traffic.

In SonicOS 7, review Policy → Rules and Policies → Access Rules for the intended source and destination zones, addresses, and services. An appropriate access rule is distinct from routing or NAT. Scope access to business needs and keep logging and security services aligned with policy.

Private IPv4 clients commonly need outbound source translation. SonicWall documents preconfigured outgoing NAT policies in common deployments; inspect the actual Policy → Rules and Policies → NAT Rules before adding another rule. Routed public subnets, inbound services, and IPv6 may require a different design. NAT does not itself authorize traffic.

Check the actual rule order, translation, and return path for a representative flow. Avoid broad allow rules or disabling inspection merely to make a test pass.

06 / Verify the result

Work outward from the handoff.

1. 01

   Review and apply

   Confirm the intended interface, zone, address, gateway, route, access rule and translation. Apply changes through the correct management workflow and retain rollback access.

2. 02

   Check link and gateway

   Verify the operational interface speed and state, then test the gateway from the appropriate source where permitted. An unanswered ping alone does not prove all traffic is blocked.

3. 03

   Check a client

   From an authorized wired client, test DNS, an approved external destination, and a business application. Confirm the return path and repeat for IPv6 where used.

4. 04

   Record the baseline

   Record the time, interface counters, test direction, and results for later comparison.

07 / Troubleshooting

Follow the evidence.

If the WAN link is up but users cannot connect, examine the actual WAN address and gateway, routes and any SD-WAN or failover policy, LAN-to-WAN access rule, outbound NAT where required, DNS, and the return path. Firewall diagnostic tests and client traffic may use different sources or paths.

show interface X1

diag show debug interface "X1"

> show interface X1
[illustrative summary]
Interface:  X1
Zone:       WAN
Address:    198.51.100.2/30

Compare physical and logical errors or discards over time on the firewall and each device through the circuit handoff. A rising counter is a reason to investigate, not proof of where a fault occurred. Record values before clearing counters; coordinate captures and keep sensitive diagnostic data in approved support channels.

Review the relevant logs and session or policy decisions for a specific authorized flow, and verify which device and path carry the return traffic. For name-resolution symptoms, see our business DNS guide.

08 / Capacity and performance

Check the whole path.

Interface speed is not the same as throughput with inspection, VPN, logging, and the business’s traffic profile enabled. Check the model’s documented capabilities and resource use during the issue. A five-minute average can hide short bursts.

Use capable, separate client and server systems for a throughput test across the path. Coordinate high-speed tests to avoid disrupting production. Our performance guide covers iperf3, latency, loss, and the limits of the measurement.

09 / Escalation

What to have ready.

• Service address, circuit identifier, handoff, and affected interface.
• When the issue began, time zone, affected applications, and recent changes.
• Operational link speed and state, plus counter changes at accessible devices along the path.
• Source, destination, address family, test results, and whether the client used Wi-Fi or a VPN.
• Relevant route, security-policy, and NAT evidence without passwords or private keys.

For Stealth service, contact support@stealth.net or +1 212 232 2020. Your firewall administrator and vendor support can assist with device and policy behavior.