Backend Servers with client transparency cannot get out to internet themselves

Help!
1

We have two backend IIS servers which are load balanced and working fine for HTTP and HTTPS passthrough traffic perfectly. They are configured for clientip transparency so their default gateway is necessarily set to the haproxy server (v 1.6.8 on CentOS7). They each have an ip address mapped to a public ip also. When we try to connect via RDP it times out. Then we noticed that we cannot originate traffic from the backend servers to the internet (smtp, smtps, http) and can only ping the local private LAN.

We are using a singe NIC on the haproxy for the listening ips (eth0, eth0:1, eth0:2…) and are using firewalld configured for the transparency to work.

Has anyone else seen this issue? If we change back the default gateway to the Juniper FW the backend servers behave normally. It is the haproxy server that seems to be discarding the packets destined for the internet.

Thanks.

2

If you want the box haproxy runs on to behave as a router, then you need to configure it that way (i mean the Linux OS, not haproxy).

Enable ip_forwarding, check firewall rules, routes and NAT necessities.

3

Thanks for pointing me in the right direction. I have modified the haproxy firewalld rules with:

firewall-cmd --add-masquerade --zone=public --permanent
firewall-cmd --zone=public --add-rich-rule ‘rule family=“ipv4” source address=192.168.11.3 accept’ --permanent
firewall-cmd --zone=public --add-rich-rule ‘rule family=“ipv4” source address=192.168.11.4 accept’ --permanent

192.168.11.3 and .4 being the IIS backend servers. That works for letting the IIS servers get out to the internet but I have lost the clientIP transparency in the IIS site logging (clientIP is the IP of the haproxy server now).

Is there a different set of rules to get the IIS servers to access the internet and allow haproxy to pass the real clientIP to the IIS servers?

Thanks.

4

I don’t know what this has to do with clientIP transparency, that would be the other direction so this doesn’t make sense.

The IIS servers are webservers, not forward proxy servers, right? So why would permitting the reverse direction change the behavior of incoming request?

5

I have tried various combinations for firewalld and as soon as I run “firewall-cmd --add-masquerade --zone=public” I break the clientIP transparency. But if I don’t have that enabled I break internet access for the IIS back end servers. It seems like the two functions are mutually exclusive unless there is a way to specify tighter rules.

I think what I need is to tell firewalld to masquerade the IIS servers except incoming connections to ports http and https.

6

I found a solution by having an ip on the backend IIS servers that is used only for all originating outbound traffic. All the other ip addresses had to be reinstalled with the “SkipAsSource” option set. No need for masquerading on the haproxy firewall at that point and it worked fine.