Geo-location of Harmony SASE IP addresses is always Israel - can we change this?

[cryptochrome]

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

[the_rock]

Interesting...one of my colleagues deployed it for the customer, will check with him if this is an issue.

Thanks for sharing.

Andy

[cryptochrome]

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. 

[the_rock]

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

[cryptochrome]

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?

[the_rock]

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

[the_rock]

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

 

[cryptochrome]

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! 🙂

[the_rock]

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

[the_rock]

@cryptochrome 

Could it be simple as this maybe? 🙂

Andy

https://support.perimeter81.com/docs/en/fix-location-and-language-for-accurate-google-search-results...

[the_rock]

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

[cryptochrome]

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 🙂

[the_rock]

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

[cryptochrome]

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!

[the_rock]

Yes please let us know, because I always like to find out the solution.

Cheers,

Andy

[cryptochrome · Accepted solution]

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

[the_rock]

Okay, thanks for the update.

Andy

[cryptochrome]

This is the workaround that we are using now:

1. Define affected services as FQDN address object (in our case, "mail.google.com" and "google.com".
2. 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. 

[the_rock]

Thanks for sharing, will definitely keep that in mind if anyone else has the same problem.

Cheers mate.

Andy