Just for reference, placing the iptables rule mentioned below into /usr/local/zenloadbalancer/config/zlb-start completely worked: iptables -t nat -A POSTROUTING -s $internal_IP$ -j SNAT --to-source $external_IP$
I did not have to run the sysctl (the setting was already 1) or the MASQUERADE commands, neither did I have to resort to having to add route rules. Thank you very much On 15/04/15 04:19, West, Adam C. wrote: > I believe I have done something similar for my TFTP farm. My problem was > that the TFTP service initiated a connection to the client but when the > client received the connection the IP was not the same as the initial > connection IP which resulted in a "Sorry, wasn't talking to you" error. > > I had to change ephemeral ports in the TFTP daemon to be hard set and I chose > 59000 to59499 > 192.168.84.0 is my inside VLAN > 172.16.2.0 is my outside VLAN > > In /usr/local/zenloadbalancer/config/zlb-start I added: > # NAT for TFTP > iptables -t nat -A POSTROUTING -s 192.168.84.21 -p udp --sport 59000:59499 -j > SNAT --to-source 172.16.2.88 > iptables -t nat -A POSTROUTING -s 192.168.84.22 -p udp --sport 59000:59499 -j > SNAT --to-source 172.16.2.88 > > Now, I also added these lines; something tells me that I should not have had > to, but I haven't tested without them... I could be wrong... > sysctl -w net.ipv4.conf.all.forwarding=1 > iptables -t nat -A POSTROUTING -s 192.168.84.0/24 -j MASQUERADE > > > Running iptables -t nat -L > Chain POSTROUTING (policy ACCEPT) > SNAT udp -- 192.168.84.21 anywhere udp > spts:59000:59499 to:172.16.2.88 > SNAT udp -- 192.168.84.22 anywhere udp > spts:59000:59499 to:172.16.2.88 > MASQUERADE all -- 192.168.84.0/24 anywhere > > Hope that helps. > > -----Original Message----- > From: Chris Neilson [mailto:[email protected]] > Sent: Monday, April 13, 2015 8:10 PM > To: [email protected] > Subject: [Zenloadbalancer-support] Outbound routing from real servers > > I have my Zen Load Balancer set-up similar to the following: > eth0 - 10.0.0.5 (management interface - the only other IP in this range is my > desktop PC) > eth1 - 172.16.0.5 (back-end interface - network that connects to real > servers) > eth2 - 1.1.1.5 (public IP interface) > eth2:1 - 1.1.1.213 (the public IP address I want to have for the FTP farm) > > I have 2 farms configured: > publictoftp - virtual IP = 1.1.1.213, virtual port = *, profile = l4xnat, NAT > type = DNAT, real IP servers = 172.16.0.13 (my FTP server) internetaccess - > virtual IP = 172.16.0.5, interface = eth1, profile = datalink, real IP > servers = 1.1.1.1 (gateway to my ISP) > > DNS is configured like this: > ftp.domain.com = 1.1.1.213 > > under this setup passive FTP connections (where the client connects to a > predefined port range as directed by the server) work fine. > active FTP connections (i.e. where the server connects to a port on the > client) initially connect, but hang as soon as you try to pass a LIST > command. This behaviour is consistent with any situation where the FTP server > is not able to open a connection to the client. > > If I browse to whatismyip.com from the real FTP server my IP shows up as > 1.1.1.5, which tells me that outbound traffic initiated from the FTP server > is passing via the internetaccess farm. > > In the case of active FTP this would mean the client is connecting to the > virtual IP 1.1.1.213 and telling the FTP server to connect to say port 1000, > but the client will see the connection to port 1000 coming from 1.1.1.5 and > reject it (like it should). > > What I would really like to do is say that any outbound connections initiated > by the real FTP server are routed out via the virtual interface eth2:1 (i.e. > IP 1.1.1.213), while any outbound connections initiated by any other real > server (say the web server) continue to route out eth2 (i.e. 1.1.1.5). Under > redhat/centos you could accomplish this by adding a file > /etc/sysconfig/network-scripts/rule-eth1 > containing something like: > from 172.16.0.13 priority 100 table tbl_ftpserver and then telling table > tbl_ftpserver to route out via eth2:1 instead of eth2. > > I am unsure how to accomplish what I am trying to do (or even if its > possible) in Zen Load Balancer. > > > ------------------------------------------------------------------------------ > BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT > Develop your own process in accordance with the BPMN 2 standard > Learn Process modeling best practices with Bonita BPM through live exercises > http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ > source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF > _______________________________________________ > Zenloadbalancer-support mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support > > ------------------------------------------------------------------------------ > BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT > Develop your own process in accordance with the BPMN 2 standard > Learn Process modeling best practices with Bonita BPM through live exercises > http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ > source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF > _______________________________________________ > Zenloadbalancer-support mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support ------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ Zenloadbalancer-support mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support
