Ask Your Question
0

neutron security group entry only works after iptables alteration on instance

asked 2015-10-21 08:23:10 -0500

hyperhead gravatar image

updated 2015-10-22 02:24:14 -0500

Hi

I have openstack implementing Neutron with existing external network from the RDO website.

It all works well, except for the neutron security groups. They seem to be a bit inconsistent without a bit of manual tweaking in iptables on the instance to make them work)

I only have one group default, so there is no confusion about what group is applied to an instance. However I have two default groups showing with different ids.

neutron security-group-list
+--------------------------------------+---------+----------------------------------------------------------------------+
| id                                   | name    | security_group_rules                                                 |
+--------------------------------------+---------+----------------------------------------------------------------------+
| 271d9b55-a800-4840-8965-3e1998461537 | default | egress, IPv4                                                         |
|                                      |         | egress, IPv6                                                         |
|                                      |         | ingress, IPv4, remote_group_id: 271d9b55-a800-4840-8965-3e1998461537 |
|                                      |         | ingress, IPv6, remote_group_id: 271d9b55-a800-4840-8965-3e1998461537 |
| eeeae8af-1ef9-4809-9861-013fdf1ada4e | default | egress, IPv4                                                         |
|                                      |         | ingress, IPv4, 22/tcp, remote_ip_prefix: 0.0.0.0/0                   |
|                                      |         | ingress, IPv4, 2222/tcp, remote_ip_prefix: 0.0.0.0/0                 |
|                                      |         | ingress, IPv4, 3306/tcp, remote_ip_prefix: 0.0.0.0/0                 |
|                                      |         | ingress, IPv4, 4444/tcp, remote_ip_prefix: 0.0.0.0/0                 |
|                                      |         | ingress, IPv4, 54321/tcp, remote_ip_prefix: 0.0.0.0/0                |
|                                      |         | ingress, IPv4, 9191/tcp, remote_ip_prefix: 0.0.0.0/0                 |
|                                      |         | ingress, IPv4, 9520/tcp, remote_ip_prefix: 0.0.0.0/0                 |
|                                      |         | ingress, IPv4, icmp, remote_ip_prefix: 0.0.0.0/0                     |
+--------------------------------------+---------+----------------------------------------------------------------------+

[ root@testcloud /~ ]# nova secgroup-list-rules default
+-------------+-----------+---------+-----------+--------------+
| IP Protocol | From Port | To Port | IP Range  | Source Group |
+-------------+-----------+---------+-----------+--------------+
| icmp        | -1        | -1      | 0.0.0.0/0 |              |
| tcp         | 22        | 22      | 0.0.0.0/0 |              |
| tcp         | 9520      | 9520    | 0.0.0.0/0 |              |
| tcp         | 3306      | 3306    | 0.0.0.0/0 |              |
| tcp         | 4444      | 4444    | 0.0.0.0/0 |              |
| tcp         | 2222      | 2222    | 0.0.0.0/0 |              |
| tcp         | 54321     | 54321   | 0.0.0.0/0 |              |
| tcp         | 9191      | 9191    | 0.0.0.0/0 |              |
+-------------+-----------+---------+-----------+--------------+

So all these ports are contactable over tcp from my external network to the instances they are applied because I added the following IP tables rules to the running instance. (except SSH, this was always working)

[root@instance1cloud]# iptables -A IN_public_allow -p tcp -m tcp --dport <port number> -m conntrack --ctstate NEW -j ACCEPT

So if I add a new rule via the openstack UI (take the entry 54321) above.

So I can see on the compute node an iptables entry for the neutron openswitch has been created (twice??)

[ root@testcloud /~ ]# iptables-save | grep 54321
-A neutron-openvswi-i59920dce-a -p tcp -m tcp --dport 54321 -j RETURN
-A neutron-openvswi-i5cbe0f2a-d -p tcp -m tcp --dport 54321 -j RETURN

On the instance itself, nothing

[root@instance1cloud ]# iptables-save | grep 54321

However if I add the rule here on the instance

[root@instance1cloud]# iptables -A IN_public_allow -p tcp -m tcp --dport 54321 -m conntrack --ctstate NEW -j ACCEPT

Then check with netcat the tcp socket is active

nc -nv 10.10.9.215 54321
nc: connect to 10.10.9.215 port 54321 (tcp) failed: Connection refused

Thats ok there is nothing listening there, but at least its showing as closed. If the rule is removed it goes back to being filtered and netcat just times out.

 nc -nv 10.10.9.215 54321
nc: connect to 10.10.9.215 port 54321 (tcp) failed: Connection timed out

My point is, it seems that the security-group rules are not being implemented ... (more)

edit retag flag offensive close merge delete

1 answer

Sort by ยป oldest newest most voted
1

answered 2015-10-22 11:53:17 -0500

OpenStack leaves the instance alone. It puts a firewall around the instance that you can configure via security groups, it provides services like dhcp or metadata, but it won't interfere with the instance internals.

edit flag offensive delete link more

Comments

Hi.

Thanks. I must have missed in the documentation about adding specific iptables rules in an instance after adding the rules to security groups and applying them to an instance.

hyperhead gravatar imagehyperhead ( 2015-10-23 01:30:42 -0500 )edit

It would be a good idea to mention it in the documentation if it's not there. In any case, you own your instance 100% and can't expect anybody else, including OpenStack, to modify files on it.

Bernd Bausch gravatar imageBernd Bausch ( 2015-10-23 20:33:58 -0500 )edit

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: 2015-10-21 08:23:10 -0500

Seen: 1,097 times

Last updated: Oct 22 '15