The new configuration parameters in server.properties are the following:

# Decides if we should consider X-Forward-Headers that reach the backend.
# Those can be spoofed by clients so we have to make sure to consider the headers only if the proxy/proxies reliably override those
# headers for incoming requests.
# Default value: false
com.openexchange.server.considerXForwards = false

# The name of the protocolHeader used to identify the originating IP address of
# a client connecting to a web server through an HTTP proxy or load balancer.
# This is needed for grizzly based setups that make use of http proxying.
# If the header isn't found the first proxy in front of grizzly will be used
# as originating IP/remote address.
# Default value: X-Forwarded-For
com.openexchange.server.forHeader=X-Forwarded-For

# A list of know proxies in front of our httpserver/balancer as comma separated IPs e.g: 192.168.1.50, 192.168.1.51
com.openexchange.server.knownProxies =

The behaviour is the following:

remotes as presented in x-forwarde-for header by proxy = 192.168.32.50, 192.168.33.225, 192.168.33.224
known proxies as configured in server.properties = 192.168.33.225, 192.168.33.224
resulting remoteIP = 192.168.32.50

The backend detects the first IP that isn't one of our known proxies and represents our new remoteIP. This is done by removing all known proxies from the list of the x-forwarded-for header beginning frome the right side of the list. The rightmost leftover ip is then seen as our new remote ip as it represents the first IP not known to us, not part of our proxy chain.

This behaviour has to be manually enabled via the com.openexchange.server.considerXForwards parameter after the administrator verified that the the configured header is set by the proxy.

If this behaviour isn't enabled we'll fall back to the original behaviour of using the ip of the balancer as the remote address.