Why will NAT IP addresses be seen in fireglass activity logs instead of the internal IP addresses, with THE X-Forwarded-For (XFF) header implemented on the Proxy?

Products

• Web Isolation Cloud

Issue/Introduction

The customer has configured forwarding XFF from the proxy on prem to the Fireglass cloud.

On the Fireglass activity log, there are still a lot of source IP as the NAT & not the internal IP address. Why?

Environment

Web Isolation Cloud

Resolution

Yes, X-Forwarded-For (XFF) header: Contains the originating IP address for which the request was forwarded. The downstream proxy adds the XFF header to the request before forwarding it to the Web Isolation Proxy.

Now, if those internal IP addresses are NATed on the network, you should expect to  see the NAT addresses of those internal IP addresses in fireglass.

The presence of NATed IP addresses (Network Address Translation IP addresses) instead of the actual client IP addresses in the activity logs of Fireglass (Symantec Web Isolation) can be attributed to the network configuration and the role of NAT in your infrastructure, especially with the setup involving Clients, an On-premise ProxySG, and Fireglass. Here's a detailed explanation:

• NAT Functionality: NAT's primary purpose in a network is to modify network address information in the IP header of packets while they are in transit across a traffic routing device. In simpler terms, NAT translates the private IP addresses of devices within your network to a public IP address before packets are sent out to the internet. This is crucial for conserving global IP addresses, allowing multiple devices to share a single IP address.

• jNetwork Configuration with ProxySG and Fireglass: In your setup, clients first connect to the on-premise ProxySG, which then forwards requests to Fireglass for web isolation. Here's how NAT influences what IP addresses appear in logs:

• • Clients to On-premise ProxySG: When clients inside your network make requests, these requests are routed through your internal network's infrastructure. If NAT is implemented at any point before the traffic reaches ProxySG (such as at the edge router or firewall), the internal IP addresses of the clients are translated to a NATed IP address.

• • ProxySG to Fireglass: ProxySG, acting as an intermediary, forwards these requests to Fireglass. If the requests received by ProxySG already have the NATed IP addresses due to NAT occurring upstream, ProxySG forwards these NATed addresses. ProxySG can also be configured to add or modify the X-Forwarded-For header, but if it simply forwards the IP addresses it receives, then Fireglass will log the NATed addresses.

• X-Forwarded-For (XFF) Header: Although the XFF header is designed to identify the originating IP address of a client connecting through an HTTP proxy or a load balancer, its effectiveness can be limited by NAT. If the NAT translation occurs before the XFF header is applied or if the XFF header does not accurately reflect the original internal IP due to network configurations, the result is that the Fireglass logs will show the NATed IP addresses instead of the actual client IPs.

• Implications for Logging and Tracking: This behavior impacts how you track and log client activity. Since Fireglass logs the NATed IP addresses, you might not see the actual internal IP addresses of the clients. This scenario is typical in networks where NAT is used extensively for internal traffic management and external traffic routing.

In conclusion, the appearance of NATed IP addresses in your Fireglass activity logs instead of the direct client IP addresses is a direct consequence of how NAT operates in your network, particularly with the traffic flow from clients through the ProxySG and then to Fireglass. To address this, you might need to adjust your network's NAT configuration, or employ additional internal tracking mechanisms that can map NATed addresses back to their original internal IPs.