Sign up ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I set up an OpenStack Folsom (2012.2) multi-node, single-network infrastructure. Everything runs fine, instances are running good on any compute node, private network works like a charm and all instances are reachable via Floating IPs from the outside and can reach the outside.

But when trying to perform a network request from a VM to itself via it's Floating IP it fails.

Neither ping nor ssh are working.

Security Groups are all open.

Ping works via Floating IPs from one VM to another but SSH don't.

Some data for one example

  • is the private network
  • is the controller
  • is the Floating IP network
  • the VM with has the Floating IP

iptables entries (regarding on the controller (all services including network):

-A nova-network-2.7-OUTPUT -d -j DNAT --to-destination
-A nova-network-2.7-PREROUTING -d -j DNAT --to-destination
-A nova-network-2.7-float-snat -s -o eth0 -j SNAT --to-source

iptables entries on the compute node:


-A nova-compute-2.7-local -d -j nova-compute-2.7-inst-143

regarding nova-compute-2.7-inst-143:

-N nova-compute-2.7-inst-143
-A nova-compute-2.7-inst-143 -m state --state INVALID -j DROP
-A nova-compute-2.7-inst-143 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A nova-compute-2.7-inst-143 -j nova-compute-2.7-provider
-A nova-compute-2.7-inst-143 -s -p udp -m udp --sport 67 --dport 68 -j ACCEPT
-A nova-compute-2.7-inst-143 -s -j ACCEPT
-A nova-compute-2.7-inst-143 -p tcp -m tcp --dport 22 -j ACCEPT
-A nova-compute-2.7-inst-143 -p tcp -m tcp --dport 3389 -j ACCEPT
-A nova-compute-2.7-inst-143 -p tcp -m multiport --dports 1:65535 -j ACCEPT
-A nova-compute-2.7-inst-143 -p udp -m multiport --dports 1:65535 -j ACCEPT
-A nova-compute-2.7-inst-143 -p icmp -j ACCEPT
-A nova-compute-2.7-inst-143 -j nova-compute-2.7-sg-fallback

Any suggestions where to search for the problem are welcome. Of course I will provide any necessary data to solve the problem. Currently I am not quite sure which data would help.

share|improve this question

migrated from Dec 23 '12 at 2:41

This question came from our site for professional and enthusiast programmers.

You can try to change the configuration of compute node to solve the iptables rules problem by: $ echo 1 > /proc/sys/net/bridge/bridge-nf-call-iptables – user208896 Feb 11 '14 at 7:58

2 Answers 2

up vote 2 down vote accepted


This is captured pretty well in, and patches are currently in progress for nova ( as of today (Jan 7th, 2013).

The full fix also goes with bug 1096987 ( and 1096985 ( to cover the more common deployment scenarios where you are using either a predefined external gateway or taking advantage of the nova-network linux/iptables networking public bridge setup.

share|improve this answer

Okay, I have found the problem:

All packets to Floating IPs ( in my case) are DNATed to private network destination ( in my case). The ssh packets go round via the controller and come right back to the VM. The ssh server answers but sends the packet with it's private address as source (of course - it has no other). So the ssh client gets a packet from as answer to a request to which it ignores.

Well, so when sending packets from Private to Floating IPs not only the destination has to be NATed but the source, too. But that's not straight forward because the DNAT is in PREROUTE while the SNAT is in POSTROUTE. It can be done using the connection tracking module:

iptables -t nat -A nova-network-2.7-float-snat -s -d -j SNAT --to-source -m conntrack --ctstate DNAT

This did the trick for me (for every single Floating IP of course). It mangles every packet from private to private which was already DNATed (then it should go to Floating IP), to make it seem to come from a Floating IP.

In my ssh scenario now happens the following:

  • client sends from to
  • packet is DNATed to
  • packet is SNATed to
  • server answers packet to
  • packet is DNATed to
  • packet is SNATed to
  • client gets answer from and is happy

This works as well for ping and also for traffic between different VMs.

Looks like I have to patch the nova-network code and submit it to the openstack project :-/.

share|improve this answer
nova-network is frozen at this point. quantum should be taking over and the deprecated nova-network project will eventually be removed. – Matt Joyce Dec 22 '12 at 1:53
Okay, but do you know if quantum has such issue? – Tilo Prütz Dec 22 '12 at 7:00

Your Answer


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.