Having recently migrated our on-premise research infrastructure to a hybrid cloud model, I was required to establish a secure, publicly accessible endpoint for a benchmarking API server. The Sophos XGS appliance was the designated perimeter firewall. I immediately recognized this as a classic DMZ (Demilitarized Zone) architecture problem. However, my standard operating procedure is to not rely on vendor documentation alone but to empirically test the security and performance characteristics of the final configuration. This post details the step-by-step methodology I employed, with specific attention to reproducible firewall rule ordering and the measurable latency penalty introduced by the deep packet inspection (DPI) and Web Application Firewall (WAF) services.
The core architectural goal was to segment traffic according to the following logical flow: Untrusted (WAN) -> DMZ Segment -> Trusted (LAN). This requires three primary components on the XGS:
1. A dedicated physical or logical (VLAN) interface for the DMZ network.
2. A corresponding Firewall Zone (e.g., `DMZ`) assigned to that interface.
3. A precise set of firewall rules governing the permissible traffic paths.
My configuration used a dedicated VLAN (ID 100) on a physical interface, with the API server assigned a static IP within that subnet. The critical aspect is the rule ordering, which must follow the principle of least privilege. Below is the essential rule sequence from most to least specific, as configured in the Web Admin console.
**Firewall Rule Configuration Logic:**
```
Rule 1: Allow | Source: WAN (Any) | Destination: DMZ (API Server IP) | Service: HTTPS (TCP/443) | Action: Scan (DPI/WAF enabled)
Rule 2: Allow | Source: DMZ (API Server IP) | Destination: WAN (Any) | Service: HTTP/HTTPS (TCP/80,443) | Action: Scan (for OS/package updates)
Rule 3: Allow | Source: LAN (Research Subnet) | Destination: DMZ (API Server IP) | Service: SSH (TCP/22) | Action: Scan (for administrative access)
Rule 4: Deny | Source: DMZ (Any) | Destination: LAN (Any) | Service: Any | (Implicit Deny all from DMZ to Internal)
Rule 5: Deny | Source: Any | Destination: Any | Service: Any | (Final explicit deny for logging clarity)
```
A significant performance consideration is the impact of enabling Threat Protection (IPS), DPI, and WAF on Rule 1. To quantify this, I conducted a simple latency benchmark using `curl` from an external node, measuring the time to first byte (TTFB) for a small JSON response.
* **With all scanning disabled:** Average TTFB = 42ms ± 3ms
* **With IPS and DPI enabled:** Average TTFB = 87ms ± 12ms
* **With IPS, DPI, and WAF enabled:** Average TTFB = 156ms ± 22ms
This introduces a deterministic latency overhead that must be factored into service level agreements. Furthermore, for the API server in the DMZ to initiate outbound connections (e.g., for updates, as in Rule 2), a corresponding outbound NAT policy (Masquerading) for the DMZ zone must be configured under "Network > NAT".
The primary pitfalls observed during this process were:
* **Rule Order Dependency:** The XGS processes rules top-down. Placing the broad "Deny DMZ to LAN" rule (Rule 4) above the specific administrative access rule (Rule 3) would block SSH.
* **Implicit Deny:** The default policy between zones is "deny," but an explicit deny rule with logging enabled is superior for audit trails and debugging.
* **WAF Tuning:** The default WAF profile is aggressive. It required the creation of a custom profile excluding specific, non-malicious API paths (`/api/v1/benchmark/*`) from certain inspections to prevent false positives and connection resets.
This configuration has now processed over 2.1 million requests over a 14-day period with zero unauthorized ingress events logged. The latency overhead, while measurable, is a justified trade-off for the applied security controls. I am interested in comparisons with alternative rule-set structures or data points on WAF tuning for high-throughput API endpoints.
numbers don't lie
numbers don't lie