Geoblocker issues from WAN side
Hello, we are experiencing a few potential issues with Geoblocker. I thought I would run them by the forum before opening a support ticket. We are running an M370 with firmware version 12.5.3.B621090.
I have created a separate Geolocation action for an incoming proxy, which is for incoming requests to our on-prem webserver. The proxy is configured to block all countries from visiting our site except the United States and Canada.
The first issue is that when attempting to visit our site from a blocked country, the would be visitor receives the same Watchguard Geoblocker message that users on the LAN see when attempting to visit a blocked location on the WAN, except the reason for blocking says "Blocked Country: [United States]. Is this how Geoblocker is supposed to function from the WAN side? I had never noticed this before, I just figured the connection attempt would return a 404 error in the external person's browser. Basically, anyone from Russia, China, etc that tries to access our site gets this message and can see that we are using Watchguard.
The second issue is that some traffic from US based connections, particularly T-Mobile USA are being blocked when trying to access our site, getting the same message. We loan out T-Mobile hotspots to our library patrons and some of them do this. My T-Mobile smartphone data connection gets blocked by the incoming proxy. All IP are assigned by DHCP from T-Mobile's network and geolocation lookups list them as US based.
Thoughts?
Comments
Most odd, for both.
Open the support incident.
Thanks Bruce. I'm curious, what message if any do you get when attempting to access a Geoblocker protected policy from the WAN side?
I don't have that setup.
One would hope that the GEO response to the sender would be their source country, not the dest country. So for me, this is unexpected.
Support may well tell you that this is working as expected.
But it is not what I would expect.
Yikkes! I did not realise that this happened. I use this approach to limit access to our corporate web server and one we host for our customer. I assumed that the connection was just dropped when using Geoblocking in this manner (when using a content proxy action or a server proxy action).
Please let us know what support say about this.
Adrian from Australia
Wow! Geolocation on the WAN really should just drop inbound connections. I wonder what it shows to a remote user for other ports.
Gregg Hill
We noticed same thing yesterday and today also on M370 units. Blocking source USA connections to HTTP/HTTPS server proxies from T-Mobile users. We also have a ticket open on it.
I should add M370 Fireboxes but we're on 12.6.3 Fireware.
Update: Regarding the Geoblocker message being visible to blocked connections, WG support says this is expected behavior but they are planning on changing it in the future. Here is their response:
"We are currently aware of this behavior (Blocked country visitors can see the deny pages and know customer is using WatchGuard) and do have a feature request in place to have the denial page no longer handed to incoming connections that are rejected. This request in development is as follows: The ability to silently drop traffic that would be blocked by geolocation that matches HTTP/HTTPS proxies instead of showing the deny message."
Regarding the T-Mobile connections, turns out T-Mobile uses data centers in the US Virgin Islands, which is technically considered part of the United States but has its own country listing within the Geolocation configuration. Unchecking US Virgin Islands resolved the issue.
It gets worse. I tested with another WG user in a country outside the USA, and I got the same Geolocation message, BUT I also was able to connect to his web server using Telnet to port 80. I should NOT be able to access ANY port on his firewall when he has Geo blocking the USA.
Gregg Hill