By default, the firewall records the IP address
of a proxy server between users on your network and your firewalls
as the Source Address in URL Filtering, Traffic, Threat, or WildFire
Submissions logs. However, if you need to investigate a log event,
knowing the specific user that initiated an HTTP/S request and the
proxy server IP address may be insufficient. To simplify the process
of debugging and troubleshooting log events, you can configure your
firewall to log the client IP address in the X-Forwarded-For (XFF)
HTTP header in various logs.
Logging the original client IP
address enables you to identify the device that corresponds to the
event you want to investigate. Specifically, you can open the detailed
log view for a Traffic, Threat, or Wildfire Submissions event and
locate the related URL Filtering log. You can use the recorded XFF
IP address to center your investigation on the specific device that
triggered the event in question. For example, you notice malicious traffic
in a Threat log. To begin your investigation, you could find the
URL Filtering log associated with the Threat log and identify the
infected client.
Before you can use the client IP address
to troubleshoot events, you’ll need to enable the X-Forwarded-For
option in a URL Filtering profile. Then, attach the URL Filtering
profile to Security policy rules that allow access to web-based
applications. The proxy server remains as the Source Address for
all traffic that matches these rules.
URL Filtering
logs do not display the X-Forwarded-For IP column on the web interface.
To view recorded X-Forwarded-For IP addresses, you must export the
logs to comma-separated value (CSV) files.
Enabling
the X-Forwarded-For option in a URL Filtering profile does not enable
user mapping of the source address. To populate the Source User
fields with the username of the person who originated an HTTP request,
you need to configure the firewall to
use
XFF values for User-ID purposes.