Ask Your Question
0

iptables issue between spawned instance and compute host

asked 2013-10-01 11:58:13 -0500

jholmes gravatar image

I've used packstack for a single node (allinone) install on a VM (VMware Fusion) using grizzly, nova networking.

My problem is that a spawned instance cannot communicate with the openstack compute API or any other tcp/http service on the single controller/compute node (I have no problem pinging the spawned instance or ssh'ing to it). This is necessary because I'm installing cloud foundry on top of openstack ( http://docs.cloudfoundry.com/docs/running/deploying-cf/openstack/ ) and there is a step where a bosh (like puppet) instance is spawned and must coordinate the install of cloud foundry services across a number of additional spawned instances, which requires use of the Compute API (these spawned services requires communication with controller/compute node as well).

On the spawned instance a process attempts to send a http request to the compute API running on 192.168.1.150, but gets a EHOSTUNREACH no route to host error, error Error 100: Unable to connect to the OpenStack Compute API.

My controller/compute node (192.168.1.150) is Fedora 18, is using a static ip and has named configured for DNS.

I can log on to spawned instance and verify that:

-- curl fails to controller/compute node:

vcap@bm-76db0be2-7803-47da-9d8a-1848b5e024e0:~$ curl http://192.168.1.150:35357/v2.0
curl: (7) couldn't connect to host

-- nmap shows only ports 22 and 53 open on controller/compute host

vcap@bm-76db0be2-7803-47da-9d8a-1848b5e024e0:~$ nmap -PN 192.168.1.150

Starting Nmap 5.00 ( http://nmap.org ) at 2013-09-21 08:42 UTC
Interesting ports on 192.168.1.150:
Not shown: 998 filtered ports
PORT STATE SERVICE
22/tcp open ssh
53/tcp open domain

Nmap done: 1 IP address (1 host up) scanned in 5.33 seconds

-- the spawned instance can ping 192.168.1.150 fine.

-- the spawned instance can successfully connect to http services running externally ( http://google.com or another machine on my network); i.e. curl http://google.com and curl 192.168.1.3:9080 gets a response for example.

I was able to isolate that iptables on 192.168.1.150 is blocking traffic and if I add a rule to allow all tcp traffic to be accepted by 192.168.1.150 I can temporarily get things to work (nmap works, curl works, my install proceeds a bit further). Here's the command I run on controller/compute node (host0/192.168.1.150):

[root@host0 cf-release(keystone_admin)]# iptables -A nova-network-INPUT -i br100 -p tcp -m tcp -j ACCEPT
[root@host0 cf-release(keystone_admin)]# iptables --list-rules | grep nova-network-INPUT -A nova-network-INPUT -i br100 -p udp -m udp --dport 67 -j ACCEPT
-A nova-network-INPUT -i br100 -p tcp -m tcp --dport 67 -j ACCEPT
-A nova-network-INPUT -i br100 -p udp -m udp --dport 53 -j ACCEPT
-A nova-network-INPUT -i br100 -p tcp -m tcp --dport 53 -j ACCEPT
-A nova-network-INPUT -i br100 -p tcp -m tcp -j ACCEPT

and resulting success using curl on spawned instance:

vcap@bm-76db0be2-7803-47da-9d8a-1848b5e024e0:/var/vcap/store ...
(more)
edit retag flag offensive close merge delete

2 answers

Sort by ยป oldest newest most voted
0

answered 2013-10-02 07:05:43 -0500

medhat gravatar image

what about adding the rule in input chain directly instead of adding it to nova chains

iptables -A INPUT -i br100 -p tcp -m tcp -j ACCEPT

edit flag offensive delete link more

Comments

that did occur to me (eventually) and what I found out is that adding the rule to INPUT instead of nova-network-INPUT does survive a openstack-nova-network restart, but unfortunately doesn't impact what the instance can connect to...for example, using nmap on instance still shows all but two tcp ports filtered...thx for suggestion though

jholmes gravatar imagejholmes ( 2013-10-02 14:09:12 -0500 )edit
0

answered 2013-11-02 02:24:49 -0500

NetCubist gravatar image

I had the same issue. If you cannot curl the compute node or the controller from the micro-bosh (Or any VM for that matter), you need to add a route to the URL in the router connecting the private network that the VM is on to the Compute networks URL.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Get to know Ask OpenStack

Resources for moderators

Question Tools

1 follower

Stats

Asked: 2013-10-01 11:58:13 -0500

Seen: 1,476 times

Last updated: Nov 02 '13