Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

neutron security group entry only works after iptables alteration on instance

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. However if I add a new one via the openstack UI (take the entry 54321) above. It will not be accessible until this rule is put in place on the instance.

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 (based on the original SSH port 22 rule I found)

[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 in the actual instance without me going and manipulating iptables on the instace, although the host is part of that security group which contains the rules.

Has anybody come across this problem before? Its is my bad configuration?

neutron security group entry only works after iptables alteration on instance

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. However 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 one rule via the openstack UI (take the entry 54321) above. It will not be accessible until this rule is put in place on the instance.

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 (based on the original SSH port 22 rule I found)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 in the actual instance without me going and manipulating iptables on the instace, although the host is part of that security group which contains the rules.

Has anybody come across this problem before? Its is my bad configuration?

neutron security group entry only works after iptables alteration on instance

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=""> number> -m conntrack --ctstate NEW -j ACCEPT

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 in the actual instance without me going and manipulating iptables on the instace, although the host is part of that security group which contains the rules.

Has anybody come across this problem before? Its is my bad configuration?