SonicWall Interview Questions — Gen 7 / SonicOS 7 Answers & Prep

① Platforms & RFDPI — the Gen 7 range and the scan engine

Q: What are the SonicWall Gen 7 platforms and what OS do they run?

Model answer: Gen 7 firewalls run SonicOS 7 across four families. TZ is the desktop / small-and-branch range; NSa is mid-market to enterprise; NSsp is the high-end, data-centre and high-throughput tier; and NSv is the virtual firewall for VMware, Hyper-V and the public clouds. They share the same SonicOS 7 feature set and the same RFDPI engine, so you scale by model, not by changing the software story. A nice extra: SonicOS 7 ships in two modes — Classic (the familiar Access Rules + separate NAT tables) and Policy mode (one unified Security Policy table that bundles access, NAT, content-filter and inspection in a single rule). Knowing both modes exist is a current-2026 detail interviewers like.

Q: What is RFDPI?

Model answer: RFDPI — Reassembly-Free Deep Packet Inspection — is SonicWall's on-box, single-pass stream scanner. It inspects every byte of a flow as it passes, without proxying or buffering whole files, which keeps latency low and removes file-size limits. One engine simultaneously powers Gateway Anti-Virus (GAV), IPS, anti-spyware, Application Control and DPI-SSL — that is the clean one-liner: RFDPI is the single stream engine that feeds all the on-box security services.

Q: RFDPI vs RTDMI vs Capture ATP — how do they differ?

Model answer: RFDPI is the on-box real-time scanner. RTDMI — Real-Time Deep Memory Inspection — is a patented cloud engine that inspects suspicious code in memory to catch fileless, encrypted and zero-day malware that signatures miss. Capture ATP is the cloud multi-engine sandbox service that RTDMI lives inside; with Block Until Verdict, the firewall holds a file at the gateway until the cloud returns a clean/malicious verdict. So: RFDPI scans on the box, RTDMI/Capture ATP sandbox in the cloud.

Q: Explain SonicOS zones and their security types, and how interface-to-zone assignment drives the default access rules.

Model answer: A zone is a logical grouping of one or more interfaces, and every zone has a security type that sets its default trust posture: Trusted (LAN — highest trust), Untrusted (WAN — the internet, lowest trust), Public (a DMZ — semi-trusted, lower than LAN so a compromised DMZ host cannot freely reach the LAN), Encrypted (the VPN zone for IPsec/tunnel traffic) and Wireless (WLAN/SonicWAVE, which also gates traffic through the wireless guest/WiFiSec logic). The moment you assign an interface to a zone, SonicOS auto-generates the default Access Rules for every zone-pair involving it. The classic defaults are: Trusted → Untrusted allow (LAN can reach the internet), Untrusted → Trusted deny (the internet cannot initiate into the LAN), and intra-zone allow (hosts in the same zone talk freely unless you tighten it). So the security type is not cosmetic — it literally writes the starting rule set, and you only add explicit rules where you want to deviate (e.g. publishing a DMZ server).

Q: What is Capture Client, and how does it relate to Capture Security Center (CSC)?

Model answer: Capture Client is SonicWall's endpoint protection (EDR/next-gen AV) agent — built on the SentinelOne engine — that adds behavioural, rollback and threat-hunting protection on the device, beyond what the firewall sees on the wire. It also enforces the DPI-SSL trust by deploying the firewall's inspection CA to managed endpoints. Capture Security Center (CSC) is the cloud management umbrella: it hosts Network Security Manager (NSM) for firewalls, the Capture Client console for endpoints, Capture ATP results and Analytics — one tenant pane for firewall + endpoint + threat data. The interview point: Capture Client = endpoint, CSC = the cloud console that ties firewalls and endpoints together.

② Policy, NAT & inspection — zones, Access Rules vs NAT Policies, DPI-SSL

Q: How do zones, Access Rules and NAT Policies fit together?

Model answer: Every interface belongs to a zone (LAN, WAN, DMZ, VPN, SSLVPN, WLAN, MULTICAST) with a security type (Trusted, Untrusted, Public, Encrypted, Wireless). Access Rules decide whether traffic is allowed and are evaluated per zone-pair, top-down, first-match (e.g. LAN > WAN). NAT Policies are a separate table that decides how addresses are translated. They are two different decisions — allow versus translate — and you almost always configure both.

Q: How do you publish an internal server to the internet?

Model answer: You need two objects: a NAT policy (inbound, translating the public IP/port to the server's private IP/port) and a matching access rule (WAN > DMZ or WAN > LAN) permitting the service to the server. A NAT policy without the access rule is dropped by policy; an access rule without NAT has nothing to forward to. The Public Server Wizard creates the address object, the NAT policy and the access rule together — naming all three is a strong interview answer.

Q: What NAT policy types does SonicOS support, and how do you build NAT loopback so internal users can reach a published server by its public IP?

Model answer: SonicOS NAT is just a set of Original → Translated mappings, and the type is named for the cardinality. Many-to-one is standard outbound PAT — a whole private subnet hides behind the WAN interface IP (X1); this is the auto-created default outbound rule. One-to-one maps a single private host to a single public IP (a dedicated public address for a server, in both directions). One-to-many distributes one public IP across several internal servers for inbound load balancing. And the publish-a-server case is a (many-to-)one inbound policy mapping public IP/port to the private server. When you tick Create a reflexive policy, SonicOS auto-builds the matching mirror (the outbound counterpart) so you do not hand-craft both directions. NAT loopback / reflection (hairpin) fixes the classic gotcha where internal users cannot reach the server by its public IP/FQDN (they can use the private IP, externals use the public IP, but not internal-via-public). You add a loopback NAT policy: Original Source = the internal zone (LAN/DMZ subnet), Original Destination = the public IP, Translated Destination = the server's private IP, Translated Source = the firewall interface IP (so the return traffic comes back through the firewall), plus a matching loopback access rule. That source translation is the part candidates forget — without it the server replies directly and the session breaks.

Q: How does Content Filtering Service (CFS) differ from App Control, and what do Geo-IP and Botnet filtering do?

Model answer: CFS (Content Filtering Service) classifies traffic by website category / URL / domain — it answers "is this site Gambling, Malware, Social Media?" using SonicWall's rated database, and you allow/block/confirm per category in a CFS policy. App Control classifies by application signature regardless of port — it answers "is this BitTorrent, TikTok, a risky file transfer?" — so it can throttle or block an app even when CFS would let the site through. Use CFS for web policy, App Control for application policy; they overlap but answer different questions. Geo-IP filtering blocks by country / geolocation (tick the countries to block, or block all connections to unknown/uncategorised IPs). Botnet filtering blocks by reputation — connections to/from known command-and-control servers on SonicWall's dynamic botnet list. Both Geo-IP and Botnet act early and independently of the full inspection chain (with a shared exclusion group for IPs you must always allow), so they are cheap pre-filters that drop bad sources before deep inspection even runs.

Q: DPI-SSL Client vs Server — what is the difference, and which services run on RFDPI?

Model answer: DPI-SSL Client inspects outbound HTTPS from your users: the firewall acts as a man-in-the-middle and re-signs sessions with its own CA, so that CA must be deployed to client devices, with exclusions for cert-pinned apps. DPI-SSL Server inspects inbound HTTPS to your own servers using the real server certificate and key. Both feed decrypted traffic to RFDPI, which runs GAV, anti-spyware, IPS, App Control, Botnet Filter, GeoIP and Content Filtering Service (CFS) — all fed by SonicWall Capture Labs.

③ VPN & HA — IPsec phases, remote clients and high availability

Q: Walk me through a site-to-site IPsec VPN and the two phases.

Model answer: A site-to-site tunnel uses IPsec, normally IKEv2. Phase 1 (IKE) builds the secure control channel — peers authenticate (pre-shared key or certificate) and agree encryption, hash and DH group. Phase 2 (IPsec) builds the actual data tunnel (the SAs that encrypt user traffic). You can build a policy-based tunnel (local/remote network selectors) or a route-based tunnel interface steered by routing — the latter scales better for many subnets and dynamic routing. The classic failure is a Phase 1 or Phase 2 mismatch — mismatched proposals, PSK or selectors.

Q: How do you configure a route-based (tunnel interface) IKEv2 VPN, and which proposal parameters must match end to end?

Model answer: A route-based VPN uses Policy Type = Tunnel Interface instead of Site-to-Site. SonicOS creates a VPN Tunnel Interface (VTI) — a logical interface in the VPN (Encrypted) zone — and instead of binding the tunnel to fixed local/remote network selectors, you steer traffic into it with routing (a static route, or a dynamic protocol like OSPF/BGP/RIP over the VTI). That is why it scales: add a subnet later and you just add a route, you don't edit the tunnel's selectors. The negotiation still has the two phases, and the proposals must match on both peers: Phase 1 (IKEv2) — IKE version (IKEv2 on both — it is not backward-compatible with IKEv1), DH (Diffie-Hellman) group, encryption (e.g. AES-256), authentication/hash (e.g. SHA-256), the authentication method (same PSK or matching certificates), and lifetime. Phase 2 (IPsec) — protocol (ESP), encryption, authentication, Perfect Forward Secrecy (PFS) DH group, and lifetime. For a tunnel interface the protected networks are 0.0.0.0/0 to 0.0.0.0/0 (routing decides what enters), unlike a policy-based tunnel where the selectors themselves must match. The interview gold line: route-based = VTI steered by routing, and any mismatch in the Phase 1 or Phase 2 proposal (DH, cipher, hash, PFS, lifetime, IKE version or auth) stops the tunnel — Phase 1 down points at IKE/auth, Phase 1 up but Phase 2 down points at the IPsec proposal or PFS.

Q: NetExtender vs Mobile Connect vs GVC — when is each used?

Model answer: For remote access: NetExtender is the SSL VPN full-tunnel client for Windows / macOS / Linux; Mobile Connect is the SSL VPN app for mobiles and desktops; GVC (Global VPN Client) is the legacy IPsec client; and the clientless Virtual Office portal gives browser access with no install. All of them should sit behind MFA. The one-liner: NetExtender/Mobile Connect/Virtual Office are SSL VPN, GVC is the older IPsec client.

Q: Active/Standby vs Active/Active HA — what is the difference?

Model answer: Active/Standby is a two-unit pair sharing a virtual MAC over an HA link; with stateful synchronization the connection table is replicated so existing sessions survive a failover instead of resetting (with monitoring and optional preempt). Active/Active DPI (clustering) lets the standby also process DPI, adding inspection capacity rather than sitting idle. So Active/Standby is redundancy; Active/Active adds throughput — and stateful sync is why a failover does not drop user sessions.

④ Management & troubleshooting — NSM and finding the drop

Q: How do you manage many SonicWalls centrally?

Model answer: With Network Security Manager (NSM), SonicWall's cloud / on-prem central manager that replaces the older GMS. NSM, part of Capture Security Center (CSC), gives one console for many firewalls: policy templates, zero-touch deployment, multi-tenant administration, config backups and compliance reporting. The interview point: name NSM (not GMS) as the current single pane of glass.

Q: Walk me through SD-WAN on SonicOS 7 — groups, path selection / probes, and failover vs load-balancing.

Model answer: SonicOS 7 SD-WAN is built from a few objects under Network ▸ SD-WAN. First an SD-WAN Group — a logical bundle of two or more WAN-side paths (physical WAN interfaces or tunnel interfaces; one interface can only belong to one group). Then SLA Probes (Performance Probes) — ICMP or TCP probes that continuously measure latency, jitter and packet loss on each path. An SLA Class object sets the thresholds (e.g. latency < 100 ms, loss < 1%). A Path Selection Profile (PSP) ties probes + SLA class together and decides which path qualifies. Finally an SD-WAN Rule (a policy-based route) matches application/traffic and sends it via the PSP. Failover vs load-balancing: with failover, traffic prefers the primary path and only moves when its probe breaches the SLA; with load-balancing, when more than one path meets the SLA, SonicOS spreads sessions across the qualifying paths (per-connection round-robin / ratio / spillover). The headline answer: SD-WAN = group the links, probe their real-time quality against an SLA class, and a path-selection rule routes each app to the best-performing link, failing over or load-balancing automatically. A common use case is keeping VoIP on the lowest-latency/jitter path while bulk traffic uses the cheaper broadband.

Q: What are Policy-Based Routes (PBR) / route policies, and when do you use them over the routing table?

Model answer: SonicOS routing is itself policy-based — under Policy ▸ Rules and Policies ▸ Route Policy you can route on more than just the destination: source, destination, service/port, and interface, plus a metric/priority and an optional probe so a route only stays active while its next hop is reachable. That lets you do things ordinary destination routing can't — e.g. send this department's traffic out a second ISP, force a particular service down a VPN tunnel interface, or override the default route for one subnet. PBR is the engine underneath SD-WAN path selection and is also how you pin traffic to a route-based VTI. When the routing table alone can't express the policy (because the decision depends on source or service, or you need probe-driven failover), you reach for a PBR. SonicOS also supports ECMP when multiple equal-metric routes exist, spreading flows across them.

Q: A user says 'my traffic is being blocked by the firewall.' How do you troubleshoot it?

Model answer: Use Packet Monitor first — filter on the exact source, destination and port and it shows whether packets arrive and, if dropped, the drop reason (for example 'Dropped by policy' or a NAT/route problem). That immediately separates an access-rule / NAT issue from a routing or security-service block. Confirm with the log, the Connections table (is a session being built?), and the access-rule and NAT-policy hit counters. For an escalation, generate a Tech Support Report (TSR) for support. The gold line: Packet Monitor first to see the drop reason, then logs and the Connections table to confirm.

Gotchas worth naming: (1) a flow can be allowed by the access rule but still dropped by a security service (IPS/GAV/App Control/Botnet/Geo-IP) — the log entry, not the access rule, will say why, so always check both. (2) Asymmetric routing trips stateful inspection: if the reply comes back on a different path the firewall never saw the SYN for, it drops as out-of-state — common after a NAT-loopback or PBR mistake. (3) Rule order matters — Access Rules are first-match top-down within a zone-pair, so a broad deny above your allow silently wins; check the hit counter to see which rule actually matched. (4) DPI-SSL errors usually mean the firewall CA isn't trusted on the client or the app is cert-pinned — add an exclusion rather than disabling inspection.