Why support.paloaltonetworks.com shows up as geolocated in Singapore (SG)
17311
Created On 01/28/21 18:19 PM - Last Modified 02/03/21 17:08 PM
Question
what can be done if support.paloaltonetworks.com resolves to Singapore with a GEO IP (SG) and there is a Geo IP block for SG
Environment
Any environment going through a Palo Firewall trying to reach the Customer Support Portal (CSP) at support.paloaltonetworks.com resolving to Singapore with a GEO IP block for SG.
Answer
Palo Alto turned on Akamai's IP Prolexic protection service for all Customer Service Portal servers on 1/8/2021 to prevent DDOS attacks.
Prolexic provides global data cleansing stations where traffic is analyzed, and malicious traffic (DDoS, known vulnerabilities, and exploits) is removed.
To allow the traffic from these cleansing stations, customers should add the IPs 103.41.68.129 to the allow lists on their firewalls.
This address was recently being tagged with an incorrect Geolocation of Singapore. Akamai has corrected this but it may be some days before this information has spread to other Geolocation providers.
Our Engineering team reached out to Akamai and they confirmed that Akamai has recently updated the geo-location for IP that was showing Singapore when evidence pointed to this traffic ending much closer.
The IP address space is anycast traffic routed by Akamai Prolexic. This is locationless traffic and will be delivered through the optimal route based on the connection location.
Akamai has multiple scrubbing centers in the US. If the connecting IP address is US based, the expectation should be to see the address terminate within the US.
In other geographic regions, you will see the traffic choose the optimal country for that traffic delivery.
It has been observed that some of the other network provider hops in the routes have also been inaccurately geotagged by third-party geolocation services.
Akamai publishes Their IP geolocation data in a feed, in accordance with RFC 8805.
This is public and consumable by third-party geolocation services in order to provide better accuracy to their services.
https://ipgeo.akamai.com/akamai-geofeed.csv
Akamai has made the decision to tag their anycast traffic as the Akamai headquarters in Cambridge Massachusetts.
This aligns with what other large providers do and is designed to help address the inconstancy in third party geolocation services for traffic that is locationless anycast traffic.
PaloAlto's Third-Party service for GeoIP has confirmed that they will be making this change in their databases on Tuesday, February 9th 2021. Other third-party Geo-IP providers may take more or less time depending on their update schedules.
As can be seen in this TraceRt the hops and the ping times are too short to be Singapore.
This test was run from a computer not on the Palo Alto network but behind a Palo Firewall.
C:\WINDOWS\system32>tracert support.paloaltonetworks.com
Tracing route to support.paloaltonetworks.com [103.41.68.129]
over a maximum of 30 hops:
1 2 ms 1 ms 1 ms 192.168.0.1
2 15 ms 11 ms 12 ms 142.254.131.189
3 36 ms 30 ms 22 ms tge0-0-8.mckntxwf01h.texas.rr.com [24.28.88.145]
4 16 ms 22 ms 23 ms agg23.plantxmp01r.texas.rr.com [24.175.49.225]
5 12 ms 15 ms 14 ms agg27.crtntxjt01r.texas.rr.com [24.175.36.177]
6 14 ms 14 ms 14 ms agg21.dllatxl301r.texas.rr.com [24.175.49.0]
7 14 ms 11 ms 13 ms bu-ether24.dllstx976iw-bcr00.tbone.rr.com [66.109.6.52]
8 12 ms 14 ms 11 ms 209-18-43-77.dfw10.tbone.rr.com [209.18.43.77]
9 * * * Request timed out.
10 45 ms 43 ms 41 ms ae2.cs1.dfw2.us.zip.zayo.com [64.125.26.202]
11 * 50 ms 49 ms ae3.cs1.lax112.us.eth.zayo.com [64.125.29.53]
12 43 ms 48 ms 43 ms ae13.mpr1.lax12.us.zip.zayo.com [64.125.28.231]
13 44 ms 46 ms 46 ms 128.177.68.30
14 47 ms 44 ms 48 ms po110.bs-a.sech-lax.netarch.akamai.com [23.57.96.243]
15 * * * Request timed out.
16 47 ms 44 ms 44 ms ae120.access-a.sech-lax.netarch.akamai.com [23.57.96.249]
17 51 ms 43 ms 43 ms 103.41.68.129
Trace complete.
