- CheckMates
- :
- Products
- :
- Harmony
- :
- SASE
- :
- Geo-location of Harmony SASE IP addresses is alway...
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Geo-location of Harmony SASE IP addresses is always Israel - can we change this?
Hi,
we are currently deep-dive evaluating P81/Harmony SASE. We deployed a network to the Frankfurt/Germany POP and noticed that while users are connected to it, their IP geo-location always resolves to Israel. This leads to all sorts of issues in web apps that make heavy use of geo-location. As an example, think Google Calendar (suddenly starting the week on Sundays and the weekends on Fridays).
While this might not sound like a big deal, it does disrupt some workflows of users.
I am guessing the P81 global network uses a single AS, which is pinned to Israel as its location, and that is what apps out there resolve.
I realize this might not be an easy fix, but I think it deserves a spot on Check Point's to do list 🙂
Thanks
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Already got a reply. Not much we or Check Point can do. I guess we have to live with it 🙂
Here is their full response:
This is regrettably a common issue with some new gateways, this issue stems from Google database that lists the wrong IP details. These databases are dynamic and will change over time. In order to resolve this issue you either need to wait on Google, or any other public service, to update their database for IPs or you can redeploy the gateway until you have an IP that shows the correct details and regional settings.
Cheers
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Interesting...one of my colleagues deployed it for the customer, will check with him if this is an issue.
Thanks for sharing.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Andy! If they are a Google Workspace user, one thing they can check and where it is immediately apparent is in Gmail's email snooze feature, where snoozing an email to "next week" results in a Sunday, not a Monday. And in Gmail's settings, the default phone number format changed to Israel.
We've seen it on other places as well, like opening Google Maps will center the map on Israel instead of your actual location.
BTW: Some geo-location services resolve correctly, as they are looking at the IP directly, other seem to be looking at the AS instead.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sounds good. Im also logged into our Perimeter81 lab, so will see if there is a setting for it. Did you open TAC case for it to confirm?
Best,
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
No TAC case yet, as I assumed this was just "how it is" and did not consider it a bug. I can go ahead and open one, if that helps?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Give me some time, I messaged my colleague about it, lets see what he says. We are both ill sadly, so just taking it easy lol
I will respond as soon as he gets back to me.
Best,
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
While I wait for my colleague to respond on this, I found something that might help, but not 100% sure. I see there is something called application policies and there you can add rules based on IP/country, like below...not sure if you tried that?
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The app policies only control access to internal applications (ZTNA), not internet access. Internet traffic routes straight through the P81 gateway (at whichever pop location your network is deployed to—Germany in our case).
And no worries, this isn't urgent. Take your time and get well! 🙂
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Its okay mate, I did way more when I had Covid and 40C fever, so this is nothing haha 🙂
Anyway, we will find out, because I know my colleague will have an idea, for sure. In the meantime, TAC case might not be a bad suggestion, as they can possibly verify this info internally.
Best,
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Could it be simple as this maybe? 🙂
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
My colleague just got back to me and he mentioned this is how you fix it on Fortinet side, but not sure if there is equivalent on CP end, maybe someone else can confirm.
Andy
Source IP anchoring policies | FortiSASE 24.1.56 | Fortinet Document Library
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The Google Search settings was a very plausible solution, but unfortunately not the right one. Interestingly enough, Google Search identifies location correctly as "Germany". I guess it differs across their many products.
I read the Fortinet thing as well, and there is nothing in P81 that would allow us to control this. The outgoing NAT IP is always that of the P81 gateway.
I'll open a support ticket, though. Let's see what they say 🙂
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Please let us know how it gets fixed, Im super curious, this is bugging me now, as it seems like there would be an easy fix, but maybe not, who knows 🙂
Best.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I don't think it will be that easy... it's probably related to P81 single AS. It's not a super big deal though, just a curious case 🙂 I'll keep you posted on the support ticket (I referenced this thread).
Thanks!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes please let us know, because I always like to find out the solution.
Cheers,
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Already got a reply. Not much we or Check Point can do. I guess we have to live with it 🙂
Here is their full response:
This is regrettably a common issue with some new gateways, this issue stems from Google database that lists the wrong IP details. These databases are dynamic and will change over time. In order to resolve this issue you either need to wait on Google, or any other public service, to update their database for IPs or you can redeploy the gateway until you have an IP that shows the correct details and regional settings.
Cheers
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Okay, thanks for the update.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This is the workaround that we are using now:
- Define affected services as FQDN address object (in our case, "mail.google.com" and "google.com".
- Set Split Tunneling mode to "Manual" and "Exclude", add the address objects as exclusions
This will route traffic to those addresses directly, bypassing the P81 tunnel.
Not ideal, but workable.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for sharing, will definitely keep that in mind if anyone else has the same problem.
Cheers mate.
Andy