Our Openfire server (v 3.9.3) lies behind a load-balancer and has an internal private IP of the form 192.168.0.x. We saw in OF-650 ([OF-650] Add support for X-Forwarded-For (XFF) headers from proxied BOSH clients - Jive Software Open Source ) that support for the X-forwarded-for header has been implemented, albeit for the HTTP binding only. Our load balancer (we host our systems @ Rackspace) supports this header for all protocols, however we cannot find a way to enable it for XMPP. As a result, all connected clients show the internal IP of the load balancer.
Is there a way by which Openfire can retrieve the information emerging from the X-forwarded-for header for XMPP unencrypted or encrypted (SSL/TLS) connections?
You’d need to inject the client IP within the plain XML connection as XML data, before TLS is negotiated - this may be tricky. There are no HTTP headers. And then patch Openfire to fetch the IP from there.
A better way may be using direct server return: Client–>LB–>Openfire && Openfire–>Client
The first part (include the IP address as a XML tag within the XML conversation) is clear.
The second however I cannot seem to follow, that is the direct server return you mention… Let’s say that we have the setup you indicate, that is:
Client -> LB -> Openfire Server
The Openfire Server recognizes only the internal private IP of the LB as the IP of the client. As such, how can the OF server reply direct to the client if the client’s public IP is unknown? What feature/setting should I look for in Rackspace LB?
Maybe Rackspace as a cloud provider does not support DSR? The feature is called direct server return and makes sure that the server replies directly to the client.