Write X-Forwarded-For field with share-port option

[Florent Poinsaut]

I use OpenVPN with pfSense and with share-port option.
This is a very good idea to have implemented this possibility.
A little improvement can be done if OpenVPN writes the source's IP address in the X-Forwarded-For field in HTTP header when using share-port option.

More explanation : ​http://en.wikipedia.org/wiki/X-Forwarded-For

[David Sommerseth]

This is indeed a very good idea. But I believe this isn't so easy to fix in OpenVPN. Maybe even close to impossible to solve.

port-share is to be used against a HTTPS service, which implies passing on SSL traffic. If OpenVPN identifies the data stream as OpenVPN data it processes the traffic itself, otherwise it is sent to the configured port-share server:port.

The reason adding the X-Forwarded-For header is close to impossible, is that OpenVPN does not decrypt the SSL traffic with the HTTP request. In fact, OpenVPN does not even have the key files needed to do this. And this header information you point at is encrypted when you use HTTPS.

Another argument for not providing OpenVPN with your web servers SSL keys/certificates is that it can be a mess to get right, especially with multiple domains with separate keys/certificates. Further, as OpenVPN then needs to decrypt the SSL traffic, it gets in a ​MITM position. And then somebody would probably also like OpenVPN to do the SSL part for plain HTTP services in behind, becoming an alternative to ​stunnel ... and then OpenVPN is on the path to become a beast which does much more than it should do.

I am a strong believer in the Unix philosophy, where you have many small "modules" which do only a limited set of features - but does them very well. Then you combine the modules you need to solve your challenge. I would prefer OpenVPN to be a good VPN solution, and it should focus only on the VPN.

There are other solutions which might solve your challenge in a better way, like ​sslh. I know ​haproxy can be configured as a transparent proxy, which then provides the requesters IP address to the backend server when forwarding the traffic. Maybe something similar is possible with sslh? At least, I think that would be the proper place to start looking for a solution.

So the bottom line is that I believe a specially designed multiplexing-proxy in front of OpenVPN will do a much better job than what OpenVPN can do. This way the workload for OpenVPN is also only OpenVPN traffic and nothing else.