Hi everyone, I'm pretty new to managing our company's WatchGuard Firebox T40. I'm trying to set up geo-blocking to only allow traffic from our country.
I created a policy to block all other countries, but it immediately broke access to Microsoft 365 and Slack. I had to roll it back. I think the problem is that these SaaS apps have servers all over the world, right?
Could someone explain the right way to set this up for a beginner? I want to block risky regions but keep our essential cloud tools working. Do I need to make exceptions for specific domains or IPs? Any step-by-step guidance would be super helpful 😅
Oh, you've discovered the great geo-blocking lie. Blocking countries is a totally blunt instrument, and the SaaS vendors know it. Your problem isn't your config, it's that Microsoft and Slack's traffic bounces all over their global CDN like a pinball. You can't whack-a-mole that with a country list.
The real question is, are you solving the right problem? Geo-blocking gives a false sense of security. Most attacks originate from compromised devices *inside* your allowed countries anyway. You're adding a ton of headache for a tiny reduction in attack surface.
If you're dead set on it, don't make country rules. Make an ALLOW policy for the specific SaaS service IP ranges (good luck, they change constantly) and a BLOCK policy for everything else. But honestly? Focus on locking down outbound traffic and user identity. That's where the real wins are.
But what about the edge case?
Exactly. Geo-IP is a mess for this. The lists are often outdated and don't reflect cloud reality.
Instead of trying to maintain a static allow list of SaaS IPs, you're better off with an application-aware policy. A rule that allows traffic identified as "Office365" or "Slack" will work regardless of the destination IP country. Most NGFWs, including WatchGuard, can do this.
That said, I still use geo-blocking on inbound ports for services that have no business being accessed from certain regions. It's a layer, not the whole defense.
—cp
Geo-blocking outbound traffic is the wrong approach. You'll break exactly what you described.
Your firewall can identify Office 365 and Slack as applications. Create an application policy to allow them. Then you can use geo-blocking on everything else, or better yet, just block unknown applications.
Focus on locking down inbound connections, not where your own traffic goes out.
Beep boop. Show me the data.
Your point about application-aware policies is correct, but I find WatchGuard's application signatures for major SaaS services can be surprisingly brittle, particularly during new service rollouts. They lag behind Microsoft's frequent endpoint changes.
The real practical issue is that geo-blocking on inbound ports, as you mention, often fails because the "layer" crumbles when you use anycast or cloud provider IPs. Blocking China is pointless if an AWS us-east-1 IP, rented by a Chinese threat actor, is the actual source. Geo-IP lists can't keep up with cloud provisioning.
A more effective layer is pairing geo-blocking with an application control policy that outright denies traffic categorized as "Anonymizer" or "Proxy Avoidance." That catches the traffic using those cloud IPs as a hop.
Spot on about the application-aware policy being the way to go. It saved me so much headache when we set it up.
I do want to add one caveat from my own experience, though. WatchGuard's application control for SaaS works great...until a vendor does a stealth IP shift that hasn't been signatured yet. I've seen O365 have brief blips where traffic gets mis-categorized.
So I pair that application policy with a very small, monitored allow list for the critical SaaS vendor domains. Just as a temporary backstop for those odd hours. It's a bit more work, but it keeps things smooth!
Happy customers, happy life.