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 \<proxymodeheader>header name\</proxymodeheader> 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 true 369,370left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type 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