VMware Cloud Community
bercheg
Contributor
Contributor

vCloud edge gateway loadbalancer for HTTPS traffic not propagating original source IP

Hello,

I'm trying to use vCloud edge gateway load balancer in front of a pool of nginx server performing SSL termination. However, from what I see in the nginx http/https access logs, the source ip is always the external IP of the

The VCD load balancer is configured with two services enabled: http and https, with respectively none and sessionId persistence method (as to preserve https resumed handshakes).

Here is the nginx configuration made to verify this

log_format main '$remote_addr - $remote_user [$time_local] "$request" '

'$status $body_bytes_sent "$http_referer" '

'"$http_user_agent" "$http_x_forwarded_for"';

For HTTPS traffic I see $remote_addr always being the IP of egde gateway on the organization network it is connected to, instead of being the original ip of the http client.

For HTTP traffic, I see $remote_addr always being the IP of egde gateway on the organization network it is connected to, and the X-Forwarded-For header is not completed with the IP of the edgegateway.

Is it a known limitation ? I could not find anything mentionned into  VMware vCloud Networking and Security 5.1.4 Release Notes

Versions used: vCloud Director (version 5.1.3) and vCloud Networking and Security (Version 5.1.4).


Thanks in advance,


Guillaume.

Reply
0 Kudos
3 Replies
arzoum1
Contributor
Contributor

Hi,

If you are still looking for an answer to this question, this might help.

In order for ANY Load Balancer (or reverse proxy) to add the X-Forwarded-For header to a request for the backend to read/log, the Load Balancer has to decrypt the request first. That's because the headers are part of the encrypted request and not the transport layer. That's why your backend (nginx) will see the client IP in the X-Forwarded-For header for only HTTP and not HTTPS requests.

For the time being, the only way to fix this is to NOT use the Edge Gateway Load Balancer service for HTTPS requests and create your own VM that will do the Load Balancing for all incoming HTTPS connections, offload the SSL and add the X-Forwarded-For header. I suggest to simply use your existing nginx to handle all your HTTPS requests. If you want faileover & redundancy, then you have to create 2 or more VMs that are doing the Load Balancing for you and team them up (Google up "NIC Bonding").

HTH,

- A

Reply
0 Kudos
Sreec
VMware Employee
VMware Employee

Hi,

    X forwarder header is Supported in  NSX edges.

NSX 6 Documentation Center

Cheers,
Sree | VCIX-5X| VCAP-5X| VExpert 6x|Cisco Certified Specialist
Please KUDO helpful posts and mark the thread as solved if answered
Reply
0 Kudos
TomasFojta
VMware Employee
VMware Employee

Edge Gateway currently cannot do SSL termination. So your LB is just doing passthrough and therefore X-Forwarded-For header cannot be added. This will be possible with NSX Edges when they will fully integrate with vCloud Director. New Networking Services Open Door to the Hybrid Cloud | VMware vCloud Blog - VMware Blogs

I have described here how NSX Edge deployed outside of vCloud Director can be utilized for load balancing VCD Cells with the X-Forwarded-For option: https://fojta.wordpress.com/2014/07/08/load-balancing-vcloud-director-cells-with-nsx-edge-gateway/

Tomas

Reply
0 Kudos