In haproxy 1.4.x, the "option forwardfor" feature's lack of an ACL to control its application is causing me to have an ugly and confusing haproxy configuration.
The issue has come up recently while attempting to configure the proxy to accept connections from trusted upstream proxies (a CDN) while also accepting connections from untrusted clients. The issue is that traffic from a trusted proxy already includes the X-Forwarded-For header which needs to be preserved while traffic from untrusted clients needs to strip any existing XFF header(s) and add our own. The best solution I've been able to come up with is to not have "option forwardfor" in the defaults and to duplicate the web frontend. One of the frontends is used for public traffic and strips and sets the XFF header and the other preserves existing XFF header after verifying the source. This works but all the rest of the front end login is now duplicated. This solution means that I have to live with duplicated code in two frontend section or write a configuration assembly application to assemble a valid haproxy configuration from multiple file snippets. Neither of these are very desirable. There is an SSL terminator (nginx) in front of haproxy which complicates matters further. What are my other options? There are multiple backends so having one shared front end and duplicating the backend sections and putting the XFF handling there isn't any better. Routing connections through the proxy twice for every hit isn't very nice either since the number of hits isn't low (not high by Willy's standards though) and it really pollutes the logs which we do analyze. Thanks in advance for any help or suggestions. -Bryan
