Routing, firewall and HAproxy
I have a small issue that baffles me:
I have a WAN, LAN and OPT1 interface and only running NAT outbound on WAN.
I have installed HAproxy and it is bound to the Loopback adapter where it reverse proxi's several Websites on LAN servers. I have made a NAT port forward on my WAN interface to the loopback adapter for publishing the websites. That works great.
But: If i create a simple allow all rule from OPT1 to LAN (simple routing, no HAproxy or NAT) i can access all the servers and services on LAN with the exception of the website ports (80 and 443) on the specific servers that HAproxy publishes.
HAproxy should not be involved in this traffic, and if I activate logging on the "allow rule" from OPT1 to LAN I get a PASS entry for TCP:S but i never get a completed session setup (TCP:ACK)
I'm just guessing here, but since it only happes for the ports HAproxy also publishes, I'm gussing the issue is with PFSENSE/HAPROXY even though this should be simple routing and firewall rules.
I think you are using the 'Transparent ClientIP' feature? That creates a 'ipfw' rule to catch all 'reply traffic' and send it to the local system.. Not caring about if it was send out through haproxy or not..
I have been unable 'fix' this other than creating a portforwarding rule also for the lan to opt traffic also and process it through haproxy..
A workaround might be to make the webserver listen on 2 ip addresses and use the 2nd one for forwarding connections with haproxy. the first when directly accessing from the lan..
Am i correct in that you use above feature?
If you do find another way to make this work without the mentioned drawback please let me know..
I am using the transparent client IP feature, so you might be right. But I don't really need to, so are you saying that if I disable that and let the proxy act as the client to the internal servers, I might resolve this issue?
It's currently bound to the loopback adapter, and from your response I take it there's nothing gained from binding it to the WAN interface directly?
If your currently binding on localhost, you need a pass-rule and a natting-rule, while when haproxy uses a WAN-ip directly only a pass-rule is needed. This probably requires slightly less overhead. But i don't think you would actually be able to notice or measure the difference..
As for the ClientIP feature it is very likely to be the cause of the problem of not being able to directly contact the server from OPT1 to LAN..
Thanks for the excellent advise. It was in fact the "Transparent Client IP" feature that caused the issue. As soon as I disabled that feature and restarted HAproxy, things started working from my OPT1 Interface.
I have enabled the X-Forward header instead to allow me to log the clients on the real backend server.
Thanks for your help :-)