Configurable Client IP Header Support
Applies to: Activate 8.3.13 and later Component: Activate Anywhere Audience: System Administrators, Infrastructure Engineers, Support
Overview
When Activate Anywhere is deployed behind a reverse proxy (for example Azure App Proxy, Cloudflare Tunnel, or load balancers), the IP address seen by Activate is typically the proxy server’s IP rather than the original client device.
Most modern proxies forward the original client IP address via an HTTP header such as:
- CF-Connecting-IP (Cloudflare)
- X-Forwarded-For
- True-Client-IP
- Other custom headers
From Activate 8.3.13, administrators can configure which HTTP header Activate Anywhere should use to determine the client IP address.
This ensures correct behaviour for:
- Audit logging
- Computer name resolution
- Computer-based services
- IP-based bad password lockouts
- IP-based security controls
Why This Feature Is Needed
With an elevated Trace level, Activate logs the connecting device’s IP address at the start of each request. This is visible in web.log via the telemetry pipeline.
This works correctly when:
- Users connect directly to Activate Anywhere
- Activate Anywhere is the only reverse proxy
However, when Anywhere sits behind another proxy (for example Cloudflare Tunnel), the connected IP becomes the proxy server’s IP rather than the end user’s.
This breaks:
- Accurate auditing
- IP-based lockouts
- Computer/IP-based services
- Security analysis
This enhancement allows administrators to nominate the header that contains the true client IP.
Configuration
Step 1 – Open Activate Studio
Navigate to Resources > Configuration > External Web
This resource contains the configuration for Activate Anywhere.
Step 2 – Edit Security Settings
- Open the SecuritySettings parameter (XML parameter).
- Locate the proxy-related configuration.
Previously, Activate supported a lightweight setting:
<EnableProxyMode>0|1</EnableProxyMode>- 0 = Default behaviour (use connected IP)
- 1 = Activate is behind a proxy (previously assumed X-Forwarded-For)
From 8.3.13, a new parameter is available:
Example:
<EnableProxyMode>1</EnableProxyMode> <ProxyModeHeader>CF-Connecting-IP</ProxyModeHeader>
Example using a custom header:
<EnableProxyMode>1</EnableProxyMode> <ProxyModeHeader>Custom-IP</ProxyModeHeader>
Step 3 – Configure Trusted Proxy IPs (Whitelist)
When using proxy mode, add the proxy server IP addresses to the whitelist.
This ensures proxy servers are excluded from:
- IP-based password lockouts
- IP limiting
- Security rules based on client IP
If multiple proxies exist in the chain, all intermediary proxy IPs should be added.
How It Works
When EnableProxyMode = 1:
- Activate reads the nominated HTTP header.
- The value from that header is treated as the client IP.
- That IP is used throughout the system for:
- Logging (web.log)
- Telemetry pipeline
- IP-based lockouts
- Computer/IP mapping
- Security enforcement
If the header is not present, the system falls back to the connected IP.
Supported Header Scenarios
Common examples:
Proxy Type | Header Name |
|---|---|
Cloudflare | CF-Connecting-IP |
Standard Proxies | X-Forwarded-For |
Akamai / Others | True-Client-IP |
Custom | Any nominated header |
Notes:
- X-Forwarded-For may contain a chain of IP addresses.
- Some proxies pass only the original client IP.
- Behaviour depends on upstream infrastructure.
Security Considerations
Proxy mode is a global boolean setting.
You are either:
- Running behind a proxy (EnableProxyMode = 1)
- Not running behind a proxy (EnableProxyMode = 0)
Both behaviours cannot operate simultaneously.
Risk of Header Spoofing
If users can access Activate Anywhere directly (bypassing the proxy), they could manually inject the configured header and spoof their IP address.
This can impact:
- IP-based lockouts
- Security logging
- Audit trails
Recommended Deployment Model
When enabling proxy mode:
- Ensure Activate Anywhere is only reachable via the proxy
- Block direct access at the firewall or network layer
- Use DNS to ensure all traffic routes through the reverse proxy (for example Cloudflare)
This is standard best practice for reverse proxy deployments.