Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

Turns out (for us) this was a symptom of an overzealous NAT rule in iptables. We're hiding all of our compute nodes behind our management node (aka cloud controller) on a private network and need to do NAT so our compute nodes can get updates and the like from the Internet.

These are the rules we used.

iptables -A FORWARD -i eth0 -o eth1 -s 192.168.2.0/24 -m conntrack --ctstate NEW -j ACCEPT iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT iptables -A POSTROUTING -t nat -j MASQUERADE

However if you look at the MASQUERADE rule the last command creates.

root@dair-ua-v01:~# iptables -t nat -L -n -v | grep MASQ 5071 700K MASQUERADE all -- * * 0.0.0.0/0 0.0.0.0/0

Covers all IPs including the VMs. A more sensible MASQUERADE rule is

iptables -t nat -A POSTROUTING -s 192.168.2.0/24 -j MASQUERADE

Which only covers NATing for the compute nodes. Once that rule was in place traffic from the outside world showed up with the proper IP address.