Amazon ELB
Running behind the Amazon ELB has certain requirements.
Ensure the PMTUD is enabled
As detailed http://www.daemonology.net/blog/2012-11-28-broken-EC2-firewall.html and http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/network_mtu.html#path_mtu_discovery, Amazon does not allow MTU negotiation in the default firewall setting. This leads to random packet loss and connection failures.
You MUST set this on the security groups for your instances and ELBs.
Proxy Protocol support
Running the ELB in a TCP mode (rather than HTTP) means that the normal headers detailing the remote user connection (X-Forwarded-For etc) are no longer available.
If one still needs to identify these values then Amazon details that the configuration for the LB should be set to provide Proxy Protocol support (V1).
This is detailed http://www.haproxy.org/download/1.5/doc/proxy-protocol.txt and Amazon’s guide is here http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/enable-proxy-protocol.html.
The Proxy Protocol spec does not define how the headers are translated to something like HTTP headers (as it is not explicitly created for HTTP). Rubris translates the headers in the spec into the following HTTP headers:
- The layer 3 source address is provided as “x-forwarded-for”
- The TCP source port is provided as “x-forwarded-for-port”
- The layer 3 destination address is provided as “x-forwarded-by”
- The TCP destination port is provided as “x-forwarded-port”
- The proxied INET protocol is provided as “x-forwarded-proto-type”
These headers are accessible in both the ConnectionHandler and UserConnectionHandler interfaces.
This is configured using the proxyProtocolVersion setting on the ModuleConfig. The default of 0 turns off this feature.
It is important to realise that the endpoint does NOT support both Proxy Protocol and basic HTTP on the same endpoint as the spec explicitly prohibits this. The endpoint must be configured to run in one or the other modes and cannot support both.