Geolocation Exceptions for inbound SMTP
I would like to clarify that I have the use of exceptions correct in the Geolocation service. I have an SMTP proxy for inbound email (port 25) and using the Geolocation service I have blocked most countries other than North America and some other countries in the world with which we do business. In certain cases we have a vendor or customer, located in North America or not, who uses email hosting services from a country that is not where they reside and which is on our block list of countries. We have seen this where the user is on Microsoft 365 in some way and although their corporate offices may be in France which is allowed on our Geolocations list, their email originates from a Microsoft server in a different country which is on our block list. To allow this I have set up an exception for a FQDN of (example) sendfromhere.com. So is this the correct formation of the exception or should it be @sendfromhere.com or *@sendfromhere.com? to allow all emails from that domain to pass through the firewall. The Watchguard documentation seems to indicate that the first format is correct but I am not sure of this and it is difficult to test as I am located in North America.
A follow up question is whether I can see the domains of the senders of emails that have not passed through to our mail server as a result of Geolocation filtering in logs
Thank you
David
Answers
sendfromhere.com is a valid domain name.
The other 2 are not.
Incoming packets have a source IP addr. It is the source IP addr that is being checked by Geo.
So the denies are based on IP addrs, not on domain names, so no, you can't see the SMTP sending domain name being blocked.
Bruce: I almost have it. I get that there is no domains coming through to the logs, but the exceptions allow for FQDN so am I good to make an exception on the domain as the documentation offers even though I cannot see it via the logs? It seems odd that the filter would be able to allow it through based on a domain that it doesn't pass along to the logs, but I can live with that. I am referring to this page that discusses exceptions - https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/services/geo/geo_exceptions_c.html
Thank you for responding.
David
You need to understand what XTM does with a FQDN entry:
https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/policies/fqdn_about_c.html
XTM tries to resolve the FQDN entry and saves the IP addr related to that FQDN in an internal table, and that IP addr is used for comparisons for the Geo execeptions because TCP/IP packets have source IP addrs, not domain names in them.
Totally clear now. Since DNS forward lookup only grabs the A and CNAME records and really has no idea that holder of the domain is using a Microsoft 365 system there is no correlation between the two and what I was hoping would be helpful is totally useless in this instance. Only if the domain had its own exclusive IPs for sending emails could I be certain that Geolocation filtering would be helpful, otherwise many domains could be originating from an IP and I would have no way of parsing the ones I want from the ones I do not want.
Thank you kindly Bruce for guiding me on this.
I guess we have to talk to everyone and filter on things further along in the conversation as a result of this - unless you have other useful concepts in mind.
Correct me if I am wrong, but I think that the point is that "their email originates from a Microsoft server" and not from their own server behind an IP address associated with the example sendfromhere.com domain. An exception for sendfromhere.com won't match any IP from Office 365 servers.
Gregg Hill
Gregg: Exactly and that is why the whole concept fails. I was incorrectly assuming that more than the IP address was inspected by the firewall in this process - but seemingly it is not.
David
It has to be looking at more than the IP address, otherwise domain or FQDN exceptions ALL would fail for Geo exceptions in SMTP and all other traffic. In my mind, tiny as it is, it looks at the IP address and compares it to domain and FQDN exceptions, cannot match the IP, THEN proceeds to block it.
I think that the problem is not that the domain or FQDN is ignored; it is that the sender's email domain name will never match the Office 365 servers' IP addresses so the IP gets blocked.
Gregg Hill
I have been struggling with this too. I don't use office 360. I use UNIX-based mail, but customers often use Office365. Even though they live in the same suburb as my business their mail appears to come from places like Hong Kong or India. Aaaarrrrrgggghhhhh.. I really like the Geolocation feature, but it sue is hard work keeping on top of the "globalisation"..