Site Localization
Geolocation
Geolocation refers to the identification of the geographic location of a user's device, usually via an IP address. When traffic goes through a proxy server, the source IP address is replaced with that of the proxy's IP address. To address this problem for HTTPS (web) requests, the X-Forwarded-For (XFF) request header field was created. When HTTPS traffic goes through a web proxy server like the Secure Connect Secure Web Gateway (SWG), the proxy server will add the originating IP address of a client to the XFF header field. This allows websites that support XFF to identify the proper geolocation of the client.
Secure Connect has data centers across the globe, and there are instances where users from one country may be accessing cloud using data centers in another country. In these instances, it is critical to maintain the original client IP inside XFF header. If the original XFF header is replaced the user's browser may show undesired search and language results. This document will cover requirements required to maintain originating client IP address in XFF header when connecting to Secure Connect fabric, as well as list of any caveats related to geolocation identification.
Requirements
Secure Connect requires following to be configured for maintaining originating client IP address:
-
Meraki Auto-VPN or manual Secure Internet IPSec tunnel (Meraki or Non-Meraki)
-
Web policy with HTTPS inspection and TLS decryption enabled
-
QUIC disabled in web browser
How to Disable QUIC
QUIC is a general-purpose transport layer protocol. Unlike TCP and UDP, QUIC is secure by default. One of QUIC’s main goals is to speed up HTTP traffic. It achieves this by multiplexing connections between two endpoints into a single flow and reducing the connection overhead associated with TCP. To enable QUIC to work with existing network equipment and systems, it utilizes UDP as its underlying layer.
In Secure Connect, the XFF header is added or edited by the Secure Web Gateway (SWG). Like most web proxies, the SWG is built around HTTP over TCP. Because of this, QUIC traffic bypasses the SWG, and therefore the XFF header is not added or updated.
Most browsers support QUIC. Google Chrome, Chromium-based browsers such as Edge, Opera, and Brave, as well as Mozilla Firefox, have QUIC enabled by default. It is recommended that you disable QUIC in the browser if you are experiencing problems with geolocation.
To disable QUIC in Chrome browser type "chrome://flags" and search for QUIC. Manually disable QUIC protocol.
Similar steps can be done for other browsers that support QUIC.
Verification
There are few web sites that can help identify if originating client IP address is maintained inside XFF header. We can see in the below example that origin XFF field is combined of public IP address 134.19.189.156 where client connects and Secure Connect proxy IP 155.190.118.67 of one of the data centers. The curl command was executed on the client machine. Note that X-Forwarded-For extended HTTP header should be formatted as {client1, proxy1, proxy2, ...}, where the first IP is client originating IP followed by list of all proxy services on the path.
client@ip-10-10-20-3:~$ curl -k -X GET "http://httpbin.org/ip" -H "accept: application/json"
{
"origin": "134.19.189.156, 155.190.118.67"
}
Limitations
- Each browser may work differently when identifying the location and language of the client. HTTP header have field called "Accept-Language". Generally this field would be a language set on the client end point. Firefox will read this field and use it as client language when listing pages and web sites. Chrome doesn't have language field and would use different ways to identify language of the client machine.
- Server must support extended XFF header and must honor the first IP address as originating client IP address. X-Forwarded-For extended HTTP header should be formatted as {client1, proxy1, proxy2, ...}.
- Server must have up to date IP location database to correctly identify location of client IP address. Some ISPs "recycle" IPs across single country and customers, which can cause the identification of the location to be incorrect. Example, IP assigned by ISP may point inside database to location that is in different city.
- Some servers may use IPv6 for communication which doesn't use XFF.