I've been evaluating several NGFWs for an upcoming deployment, and SonicWall's geo-IP filtering is a key feature on my test list. While marketing materials promise simple "point-and-click" control, the actual implementation for outbound traffic has some non-obvious steps that aren't always covered in high-level demos. I've documented a rigorous, step-by-step configuration based on my lab setup.
**Core Configuration Logic**
Unlike inbound geo-blocking, which is often object-based, controlling outbound traffic by destination country requires a specific policy structure. The critical insight is that you must create Address Objects for the countries you wish to block, then use them in an Access Rule. Here's the exact sequence:
1. **Create Geo-IP Address Objects:** Navigate to `Object > Match Objects > Addresses`. Click "Add" and set the type to "Geo-IP Country/Region".
```code
Type: Geo-IP Country/Region
Name: Geo-Block-Outbound-RU
Country: Russian Federation
```
Repeat for any other countries (e.g., CN, KP, IR). Grouping them into an Address Group is efficient for management.
2. **Construct the Access Rule:** Go to `Policy > Access Rules`. Create a new rule **above your default allow rule**.
* **General Tab:** Set Source to "Any", Destination to your created Geo-IP Address Group.
* **Service/Application Tab:** Service can be "Any" or a specific set.
* **Action Tab:** Set to "Deny".
* **Users Tab:** Typically left as "Any".
* **Schedule Tab:** Set to "Always On".
* **Logging Tab:** Enable logging. This is crucial for validation.
**Evaluation Notes & Pitfalls**
* **Rule Order is Critical:** The rule must be placed higher in the policy list than any broader permissive rules for the same traffic. The SonicWall evaluates rules from top to bottom.
* **Validation Method:** Don't rely on the GUI's green checkmark alone. Generate outbound traffic to an IP in a blocked country (using a test VM) and check the `Log > View` section for the denied connection, filtering by the rule ID.
* **Performance Impact:** In my tests, enabling geo-IP filtering on a high-throughput outbound link (1Gbps+) showed a negligible increase in CPU utilization (~2-3%) on a TZ670. The cost is acceptable for the security benefit.
* **False Positives:** Be aware that CDN and cloud service IPs (e.g., Akamai, Cloudflare) may be geo-located differently than their content origin. Blocking certain countries could inadvertently break access to parts of major websites.
This configuration provides a solid baseline. I'm interested in others' experiences with this feature, particularly regarding long-term log analysis or any performance benchmarks under sustained attack patterns.