Sophos Firewall Interview Questions — SFOS / XGS Answers & Exam Prep

① Architecture & Xstream — SFOS on XGS, streaming DPI and FastPath

Q: What is Sophos Firewall and what is the Xstream architecture?

Model answer: Sophos Firewall is the SFOS firmware (formerly branded XG Firewall) running on XGS hardware appliances, and also as a virtual / cloud firewall on VMware, Hyper-V, KVM, AWS and Azure. Its modern design is Xstream, which has three pillars: TLS 1.3 inspection performed once on the stream, a single streaming DPI engine, and FastPath hardware offload. The clean one-liner: Sophos Firewall = SFOS on XGS, with an Xstream pipeline that decrypts once, inspects once, and offloads the rest to hardware.

Q: What does the 'single streaming DPI engine' actually buy you?

Model answer: In older designs each security feature re-reads the packet — IPS reads it, then anti-malware reads it again, then web and app control. Xstream uses one streaming engine so the packet stream is scanned once and the result is shared by IPS, anti-malware, web filtering and application control together. That removes duplicate work, cuts latency, and is why Sophos can inspect TLS-decrypted traffic at higher throughput. It is a favourite 'why is it different' question.

Q: What is FastPath / the Xstream Flow Processor for?

Model answer: Not every flow needs full inspection forever. Once a flow is known and trusted, Sophos offloads it to FastPath — on XGS appliances this is dedicated Xstream Flow Processor hardware. The offloaded flow is forwarded in hardware, which frees the main CPU to do the expensive TLS decryption and DPI on the flows that still need it. So the architecture deliberately splits work: hardware fast-paths the trusted bulk, the CPU inspects the rest.

② Rules, NAT & inspection — the SFOS 18 split, TLS and the threat engines

Q: Since SFOS 18, what is the difference between a firewall rule and a NAT rule?

Model answer: This is the headline migration question. Before SFOS 18 a single rule did both jobs; SFOS 18 separated them into two tables. A firewall rule decides allow or deny between zones (LAN / WAN / DMZ / WiFi / VPN), and decides which protections apply (IPS, web, app control, TLS, ATP, traffic shaping); it is matched top-down, first-match and can be identity / user-based. A NAT rule only does address translation: SNAT (MASQ) for outbound, DNAT to publish an internal server, plus full NAT and loopback. Two separate tables, two separate jobs. The order matters: a firewall rule decides allow/deny first, then the NAT table is matched top-down, first-match — so a broad NAT rule placed above a specific one can translate traffic the wrong way before the specific rule is ever reached.

Q: Walk me through every SFOS NAT rule type — MASQ, SNAT, DNAT, full NAT, loopback, reflexive and linked NAT.

Model answer: This is the depth question that separates an L1 from an L2. SNAT (source NAT) rewrites the source address on the way out; MASQ (masquerade) is the special SNAT that translates the source to the IP of the outgoing (WAN) interface — the default outbound rule on every box is MASQ so the LAN reaches the internet. DNAT (destination NAT) rewrites the destination to publish an internal server to the WAN. Full NAT translates both source and destination in one rule — used when you must hide the original client from the server too. Loopback (hairpin) NAT lets an internal host reach a published server by its public IP/FQDN, so internal and external users use the same address — the classic 'works from outside, fails from inside' fix. A reflexive rule is the auto-created SNAT that pairs with a DNAT so the published server's replies go back out the matching public IP. A linked NAT rule is a SNAT created from a firewall rule and shown in the NAT table — keeping the translation tied to the rule that allowed it. Name all seven and explain MASQ-is-a-special-SNAT and loopback-for-hairpin, and you have aced it.

Q: When do you use Web Server Protection (WAF) instead of a plain DNAT business rule?

Model answer: A DNAT rule simply forwards WAN traffic to an internal server at layer 3/4 — fast, but the server is exposed and only IPS/app-control inspect it. Web Server Protection (WAF) makes the firewall a reverse proxy: you define a virtual web server that maps to the real one, and the firewall terminates the connection itself and applies a protection policy — OWASP-style rules against SQL injection / XSS, cookie and URL hardening, form-hardening, and optional reverse-proxy authentication (basic or form-based) in front of the app. Crucially, processing order is DNAT first, then the proxy — so if you DNAT the same traffic the WAF is bypassed; you protect or you DNAT, not both. Use WAF for an HTTP/HTTPS app that needs application-layer hardening or pre-auth; use a DNAT business rule for non-web services (RDP, SMTP, SQL) or when you just need straight port-forwarding. The interview line: DNAT = layer-3 forward and expose; WAF = reverse-proxy that inspects and hardens the app.

Q: How does TLS inspection work on Sophos Firewall?

Model answer: TLS / SSL inspection has its own separate rule table driven by decryption profiles. The firewall acts as a man-in-the-middle: it terminates the client's TLS, inspects, then re-encrypts to the server. Because it must present a trusted certificate, it re-signs with its own CA — so you must deploy that CA to every client, or browsers throw certificate errors. You also keep exclusions for traffic that breaks under inspection — banking, software updates and especially certificate-pinned apps. The interview point: re-sign CA on clients, exclusions for pinning.

Q: Explain the difference between IPS, ATP and Zero-Day Protection.

Model answer: Three different jobs. IPS matches SophosLabs signatures against traffic to block known exploits in flight. Advanced Threat Protection (ATP) watches for outbound connections to known command-and-control / botnet destinations — i.e. it catches a host that is already infected calling home. Zero-Day Protection (the cloud sandbox plus deep learning, formerly Sandstorm) detonates unknown files in the cloud before delivery to catch brand-new malware no signature exists for. Signature on traffic, callback detection, sandbox on unknown files — three layers.

③ VPN, ZTNA & Synchronized Security — connectivity and the Heartbeat

Q: Policy-based vs route-based IPsec — and why does the tunnel sometimes not come up?

Model answer: Policy-based IPsec binds 'interesting traffic' to fixed subnet selectors — simple but rigid. Route-based IPsec creates a tunnel interface (xfrm) so you steer traffic with routing — including dynamic routing and failover — which is cleaner and scales, the modern recommendation. The classic failure is a phase 1 / phase 2 mismatch: the two ends disagree on encryption, DH group, PFS, lifetime or the subnet selectors, so the tunnel never establishes or flaps. First thing to check when an IPsec tunnel is down.

Q: Set up a route-based IPsec VPN — what does SFOS create, and which proposal parameters must match the far end?

Model answer: When you choose route-based, SFOS auto-creates an xfrm interface (a virtual tunnel interface / VTI) shown as xfrmN under Network ▸ Interfaces; you then add a static, SD-WAN or dynamic route pointing the remote subnets at that xfrm interface — that routing decides what enters the tunnel, instead of fixed selectors. Policy-based instead writes the subnet selectors straight into the connection, so SFOS builds the IPsec routes for you. Either way, the IPsec profile (proposal) must match on both ends: IKE version, phase 1 encryption + hash + DH group + authentication (PSK / certificate) + lifetime, and phase 2 encryption + hash + PFS group + lifetime. The pro move for resilience: build it route-based and bind the route to an SD-WAN profile with an SLA so a probe failure fails the tunnel over automatically. Say 'route-based gives me an xfrm interface I route over, and the phase-1/phase-2 proposals must match' and you sound like you have actually built one.

Q: Compare the remote-connectivity options — Sophos Connect, SSL VPN, RED / SD-RED.

Model answer: Different tools for different jobs. Sophos Connect is the remote-access client for individual users — IPsec or SSL, provisioned by exporting a .scx / .pro provisioning file (or via the Sophos Connect portal) so users import one file instead of hand-configuring, and it supports MFA. SSL VPN is the legacy clientless/portal-based remote access, still used where IPsec is blocked. RED (Remote Ethernet Device) and SD-RED are small branch appliances that build a zero-touch, auto-provisioned layer-2/3 tunnel back to head office — you register the RED ID in SFOS, plug it in at the branch and it phones home through the Sophos provisioning service, so a non-technical person can deploy a branch with no on-site engineer. SD-RED adds dual-WAN and SD-WAN-style resilience. So: Sophos Connect = user client, SSL VPN = legacy portal, RED/SD-RED = zero-touch branch box, with site-to-site IPsec for firewall-to-firewall.

Q: What is the difference between VPN and Sophos ZTNA?

Model answer: A VPN puts the user on the network — broad access and real lateral-movement risk if the device is compromised. Sophos ZTNA grants access to one application at a time, checks identity AND device health every time, and the app is never exposed to the internet directly. So ZTNA replaces broad VPN with per-app, continuously verified access. For remote access today Sophos offers Sophos Connect (IPsec / SSL client), SSL VPN, clientless access, RED / SD-RED zero-touch branch tunnels, and MFA — with ZTNA as the zero-trust evolution.

Q: What is Synchronized Security and the Security Heartbeat?

Model answer: Synchronized Security means the firewall and the Intercept X endpoints talk to each other through Sophos Central. Each endpoint reports a health colour over the Security Heartbeat — green, yellow or red. A heartbeat policy can auto-isolate a red endpoint the moment it turns red; Lateral Movement Protection stops a compromised host talking to its peers; and Synchronized App Control uses what the endpoint sees to name 'Unknown' applications the firewall could not classify on its own. The value line: the firewall and endpoint defend together, doing what neither can do alone.

Q: Go deeper on Synchronized Security — what exactly happens when an endpoint turns red, and what data flows over the Heartbeat?

Model answer: The Heartbeat carries far more than a colour. Each Intercept X endpoint reports its health (green / yellow / red), its logged-in user, and the process/app behind every connection back to the firewall via Sophos Central. When a host goes red, a heartbeat firewall rule can limit or fully isolate it (drop or restrict its traffic) until it is clean; Lateral Movement Protection means even healthy peers refuse heartbeat traffic from the red host, so it cannot pivot east-west; and the firewall can use Source of Infection data to point you at the offending machine. Because the endpoint tells the firewall the process name, Synchronized App Control auto-classifies traffic the DPI engine alone marked 'Unknown'. There is also a 'Missing Heartbeat' condition — a managed endpoint that stops reporting can itself be treated as suspicious and restricted. The interview gold: it is bidirectional context-sharing, not just a status light — the firewall acts on who, what process, and how healthy.

④ Operations & scenarios — Sophos Central, logs and how to answer

Q: How do you manage a fleet of Sophos Firewalls?

Model answer: Sophos Central is the cloud console for the whole estate: device groups, firmware updates, backups, zero-touch provisioning and group policies pushed to many firewalls at once. Central Firewall Reporting (CFR) keeps logs and reporting in the cloud so you do not depend on each box's local storage, and Sophos MDR adds managed detection and response. Each firewall still has its local web admin and SFOS console; Central is the single pane for fleet operations.

Q: How do you give Sophos Firewall user identity — STAS, AD SSO, captive portal, hotspot — and build identity-based rules?

Model answer: Identity turns rules and logs from IP addresses into users and groups. The main methods: STAS (Sophos Transparent Authentication Suite) — an agent installed on the Active Directory domain controllers that watches Windows logon events and tells the firewall 'this user is now on this IP', giving transparent SSO with no client and no prompt. AD / Kerberos & NTLM SSO silently authenticates domain-joined browsers. The captive portal is a web login page for users the firewall cannot identify transparently (BYOD, non-domain). A hotspot is a guest portal — voucher / password / terms-acceptance — for visitor Wi-Fi, separate from staff identity. There is also the Authentication Agent (a client on the PC) and clientless static IP-to-user mappings. Once a user is mapped to an IP, you tick 'Match known users' on a firewall rule and pick AD groups, so the rule (and the web policy and the logs) is by identity, not subnet. The line: STAS = transparent SSO from the DC, captive portal = fallback login, hotspot = guests, and identity-based rules match users/groups instead of IPs.

Q: Configure Sophos HA — Active-Passive vs Active-Active, the HA link, monitored ports and what triggers failover.

Model answer: Two appliances of the same model and firmware form a cluster joined by a dedicated HA link (a directly cabled port) over which they exchange heartbeat packets (VRRP-based, ~every 250 ms) and sync config/sessions. In Active-Passive one unit (the primary, which also holds the licences) carries all traffic while the auxiliary stands by fully synced, ready to take over — the standard, recommended mode. Active-Active additionally load-balances sessions across both units for more throughput, but it is stricter (e.g. not supported when WAN interfaces are DHCP/PPPoE). You designate monitored ports; if any one monitored interface goes down — or the peer misses the consecutive-heartbeat threshold (16 by default) on the HA link, or a unit reboots/loses power — the cluster fails over to the other unit. The answer they want: same model + dedicated HA link + heartbeats, A-P for HA / A-A adds load-balancing, and failover fires on a monitored-port down, a missed heartbeat, or device failure.

Q: What are the classic Sophos Firewall 'gotchas' an interviewer will fish for?

Model answer: Hit the ones that trip real engineers: (1) rule order — firewall and NAT tables are both top-down first-match, so a broad rule above a specific one silently wins; (2) the TLS re-sign CA not pushed to clients (cert errors) and missing exclusions for certificate-pinned apps and updates; (3) loopback/hairpin NAT missing, so a published server works from outside but not from the LAN; (4) DNAT vs WAF — DNAT is processed before the proxy, so DNAT-ing WAF traffic bypasses protection; (5) IPsec phase 1/2 proposal mismatch as the default tunnel-down cause; (6) DHCP/PPPoE WANs blocking Active-Active HA; and (7) over-broad VPN access where ZTNA per-app would be safer. Naming two or three of these unprompted signals real hands-on time.

Q: A published web server is unreachable from the internet. How do you troubleshoot it?

Model answer: Work the stages in order and prove each from logs. First check the NAT rule — is the DNAT publishing the right internal host and port? Then the firewall rule — because rules are top-down first-match, a broad WAN deny rule sitting above the published-server rule will swallow the traffic before it is ever allowed, so confirm the published-server rule is matched. Then check TLS inspection (a re-sign breaking a pinned client) and IPS / ATP in case a signature dropped it. Use the Log Viewer to see exactly which rule matched and packet capture / the connection table to see where the packet stopped. The interview gold line: check NAT then rule order in the Log Viewer first, confirm with a packet capture — never guess.