Support Proxy Protocol
The current Azure Load Balancer implementation does not support the Proxy Protocol as AWS does (https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/enable-proxy-protocol.html).
This makes implementing Openshift on Azure troublesome as the real client IP is not available to backends (https://docs.openshift.com/container-platform/3.9/install_config/router/proxy_protocol.html).
The proxy protocol allows pass through of real client IP's to the backend application for TCP load balancer setups. This may be particular important for Openshift deployments or alike, where the certificate management should be done in the PaaS platform (on the router) and not on the ELB.
Right now the Openshift template from MS (https://github.com/Microsoft/openshift-origin) uses TCP proxy setup. Without proxy protocoll support, the real client IP's would never be visible, making advanced analytics and visualization troublesome.
Also log integration is troublesome, as one can not focus on the PaaS but needs to deal with cloud provider specifics (e.g. like collecting Load Balancer logs).
Thank you for your feedback.
Azure Load Balancer does not terminate connections, it is not a proxy, and does always preserve the source IP address of the inbound flow.
We don’t provide logging from the Load Balancer resource itself, but you can use NSG flow logs to retrieve flow information as needed.
John Woe commented
Azure LB, if it's at least a thin firewall-like layer, it is a proxy, a tcp socket proxy, that is. As such , it can/does rewrite the source, destination headers in the TCP packets. And it can also insert the proxy v1 or v2 TCP headers just fine, fairly simple to implement (about the level of a final year high school or first year college student , in IT). That leaves the admin of the forum is not a technical person, just a community manager . May need to escalate your requests to a higher ranking engineer, i'm afraid.
Azure requires virtual machines to be connected to an Azure Virtual Network. A virtual network is a logical construct built on top of the physical Azure network fabric. Each virtual network is isolated from all other virtual networks https://www.tutuapp.software/
You should think twice (no, 3 times) before declining the user's request. There are a lot of use cases where proxy protocol can be useful, and knowing source IP address is less than half of this use cases. There are a lot of cases, when it is more important to know destination IP/port and your solution is not allowing this, while pp2 @AWS does.
So, if you really want seriously compete with AWS you should not decline requests that light. A lot of companies have their application based on pp2 and with these decision you just telling all these potential customers - no, we don't want you as a customer.
Robert Heinzmann commented
- AWS Proxy Protocol - https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/enable-proxy-protocol.html
- Openshift Proxy Protocol - https://docs.openshift.com/container-platform/3.9/install_config/router/proxy_protocol.html