Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Here's the setup:

  • 2 servers running CentOS 5.6 (hostnames = "master1" and "master2")
  • "master1" LAN IP is 10.224.45.130 and WAN IP is 184.107.x.1
  • "master2" LAN IP is 10.224.45.131 and WAN IP is 184.107.x.2
  • Apache + Heartbeat installed on both, with "master1" as primary for httpd service in haresources.
  • Apache binds to virtual IP 10.224.45.135 (started through heartbeat)
  • iptables NAT PREROUTING from port 80 -> 10.224.45.135:80 on both servers.

(Note: I am logged into a VPN so I have access to the LAN)

I have heartbeat working fine. It will correctly create the virtual IP address on "master1" and start apache. When I stop heartbeat on "master1" to simulate a server failure heartbeat properly notifies "master2", which takes over the virtual IP and starts apache. This is all working fine.

I can point to the LAN IP for either server and it will load the site no matter which server is currently running apache (since both have an iptables NAT PREROUTING port 80 to the virtual IP address). I can also load the site when I point my browser to the virtual IP address itself.

However, if I call the public WAN IP for either server, the site will only load when I call the IP for the server that is currently running apache. For instance, if master1 is currently running apache, I can load the site by calling any three of the LAN IP addresses or the WAN IP for master1. But the site will not load if I call the WAN IP for master2. However, if I stop heartbeat on master1 so that apache starts on master2, I can then load the site by calling the WAN IP for master2 but not master1.

I'm not sure why iptables would properly route packets to the virtual IP when I access the site through the LAN IP and the WAN IP for the server running apache but not the WAN IP for the other server, even though they both point port 80 to the virtual IP. I also noticed that I can only ping the virtual IP (10.224.45.135) from the server currently running apache (and therefore the server that currently has the VIP configured on it). It was my assumption that I would be able to ping the VIP from either server. I'm not sure if this has anything to do with the reason that the WAN IP does not get routed to the VIP properly though.

Here is my iptables setup:

*filter
:FORWARD DROP [0:0]
:INPUT DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -i tun0 -j ACCEPT
-A INPUT -i tap0 -j ACCEPT
-A INPUT -i br0 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 20 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 21 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 25 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 106 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 110 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 143 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 389 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 465 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 587 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 636 -j ACCEPT
-A INPUT -p udp -m udp --dport 694 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 843 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 873 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 953 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 993 -j ACCEPT
-A INPUT -p udp -m udp --dport 993 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 995 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 1194 -j ACCEPT
-A INPUT -p udp -m udp --dport 1194 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 3000 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 3306 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 5901 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 7025 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 10000 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 11211 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 11511 -j ACCEPT
-A FORWARD -i br0 -j ACCEPT
-A FORWARD -o br0 -j ACCEPT
-A FORWARD -p tcp -m tcp --dport 80 -j ACCEPT
COMMIT
*mangle
:PREROUTING ACCEPT [30383:12077327]
:INPUT ACCEPT [30381:12077231]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [26362:10490359]
:POSTROUTING ACCEPT [26362:10490359]
COMMIT
*nat
:PREROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A PREROUTING -p tcp -m tcp --dport 80 -j DNAT --to 10.224.45.135:80
-A PREROUTING -p tcp --dport 443 -j DNAT  --to 10.224.45.135:443
-A POSTROUTING -s 10.8.0.0/255.255.255.0 -o venet0 -j MASQUERADE
COMMIT
share|improve this question
    
After further inspection by setting up logging in iptables, I've verified that the packets are properly being forwarded from master1 to master2 with DST=10.224.45.135 and DPT=80. I thought at first that maybe it was entering an infinite loop at that point since my PREROUTING was set up to forward all incoming packets from port 80 to the VIP, so I thought maybe it was continually trying to forward to the VIP. I added another condition to the PREROUTING so it would only forward to the VIP when the DST is the WAN IP, but that still doesn't work. –  Sarah Ryan May 12 '11 at 21:37

1 Answer 1

up vote 0 down vote accepted

I found the answer!

I needed to add a POSTROUTING rule to the NAT table set to Masquerade for packets with a DPT of 80 or 443.

Found the answer here: http://www.debian-administration.org/articles/73#comment_22

In addition to the rules in the article, you need a POSTROUTING rule to enable masquerading if the redirection goes to another machine. For example:

iptables -t nat -A POSTROUTING -j MASQUERADE -o eth0

Otherwise, the response doesn't get back to the original machine and the connection appears to be filtered. At least this is what I found when trying to do forwarding. I appreciate that this is a few years too late to help but it might help someone else.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.