Issue LiteSpeed Enterprise – Original Client IP Not Displayed Behind WAF

[Thomas Oryon]

Server operating system version

RHEL 9

Plesk version and microupdate number

18.0.81

Hi Support Team,

We are experiencing an issue with LiteSpeed Enterprise running on our Plesk server, where the web server access logs are recording the WAF's private IP address instead of the original visitor's public IP address.

Server Environment:

• Control Panel: Plesk
• Web Server: LiteSpeed Enterprise 6.3.7
• WAF / Reverse Proxy IP: <WAF_PRIVATE_IP>
• Plesk Server IP: <PLESK_PRIVATE_IP>
• Test Domain: ad-ww1.srv.asia

Issue Description:

Our Plesk server is hosted behind a WAF. Currently, all incoming requests are recorded with the WAF's private IP address instead of the actual public IP addresses of visitors.
We would like LiteSpeed to correctly identify and record the original client IP addresses in the website access logs and Plesk Log Browser.

Troubleshooting Performed:

1. Verified that Apache's mod_remoteip module is installed and enabled.
2. Confirmed that Apache has RemoteIPHeader X-Forwarded-For configured.
3. Verified that LiteSpeed Enterprise is actively handling HTTP/HTTPS traffic.
4. Confirmed the following configuration:
   <useIpInProxyHeader>2</useIpInProxyHeader>
5. Added the WAF IP to LiteSpeed's trusted proxy configuration:
   <allow>127.0.0.1T,<WAF_PRIVATE_IP>T,ALL</allow>
6. Restarted the LiteSpeed service and confirmed that the configuration syntax check completed without reporting errors.

Current Result:

Despite these changes, LiteSpeed continues to record the WAF's private IP address instead of the original visitor's public IP address.

Request for Assistance:
Could you please advise on the following?

1. Are additional LiteSpeed Enterprise settings required to retrieve the original client IP from the X-Forwarded-For header?
2. Is the trusted proxy configuration correct for LiteSpeed Enterprise 6.3.7 running with Plesk?
3. Are any additional settings required to ensure the original client IP appears in both LiteSpeed access logs and the Plesk Log Browser?
4. What is the recommended method to verify whether LiteSpeed is receiving and correctly processing the forwarded client IP headers?
   
   NOTE : We are using Fortigate firewall.

We would appreciate your guidance on resolving this issue without impacting the existing hosted websites or WAF protection.

Thank you for your assistance.

 

[tessa67]

Hi,

LiteSpeed doesn’t use Apache modules, so mod_remoteip and RemoteIPHeader won’t do anything here. Only LiteSpeed’s own settings count. Your approach (Use Client IP in Header set to Trusted IP Only, plus the WAF IP marked with T in the Allowed List) is the right one, so the problem is probably somewhere else. Two usual suspects:

• The WAF isn’t actually adding an X-Forwarded-For header (plain NAT doesn’t).
• The T entry doesn’t match the IP LiteSpeed sees as the connecting peer, for example if the WAF does source NAT.

Quick way to find out: put this test file on the site and open it through the WAF.

<?phpecho "REMOTE_ADDR: " . $_SERVER["REMOTE_ADDR"] . "\n";echo "XFF: " . ($_SERVER["HTTP_X_FORWARDED_FOR"] ?? "not set") . "\n";

If XFF says "not set", the fix is on the WAF side. If XFF shows the public IP but REMOTE_ADDR is still the WAF IP, LiteSpeed isn't applying the trusted-proxy setting. In that case, set it in the WebAdmin console instead of only in the XML and do a graceful restart. Once LiteSpeed resolves the client IP, the access log should pick it up, and the Plesk Log Browser reads from that log (I haven't tested that on Plesk myself). Can you post the test output (IPs masked) and tell us which Fortinet product and mode the WAF runs in? Then we can narrow it down further.

Regards
Tessa