[Openstack] Lack of iptables rule in DVR network scenario when using floating IPs is causing packets' drop

Remo Mattei Remo at Italy1.com
Fri Apr 15 18:13:07 UTC 2016


It says default so that applies only to that network.  Just add a new rule icmp all source 0/0 then you can ping in and out. 

Same for  ssh which applies to floating ip as well. In mitaka it works a little differently. 

Ciao

Inviato da iPhone

> Il giorno 15 apr 2016, alle ore 10:50, Jorge Luiz Correa <correajl at gmail.com> ha scritto:
> 
> Thank you, Peter and Remo! Your answers guided me to better understand security groups and iptables rules. The problem was that I haven't understood very well the default security group created automatically, mainly the rules that seems to pass all traffic. Explained bellow. 
> 
> DVR is enabled.
> Version is Liberty.
> 1 hypervisor and router is OK on compute nodes and controller (snat).
> I had not assigned an ICMP rule on default security group neither other security group.
> 
> On default security group we can see these rules (dashboard):
> 
> Direction EtherType    IP Protocol Port Range       Remote IP Prefix    Remote Security Group Actions
> Egress    IPv6            Any             Any                ::/0                        -    
> Egress    IPv4            Any             Any                0.0.0.0/0                -    
> Ingress    IPv6            Any             Any                -                           default
> Ingress    IPv4            Any             Any                -                           default
> 
> I was thinking that the rule "Ingress IPv4 Any Any" could pass all the traffic, independently if we are using a private IP or a floating IP. But, when this rule is translated to iptables, neutron uses ipset and the configured set has just the private IP addresses. 
> 
> Chain neutron-openvswi-i7a7a669c-3 (1 references)
>  pkts bytes target     prot opt in     out     source               destination         
> .....
>     0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0            match-set NIPv43c228055-2735-4339-b9a8- src
> .....
> 
> And:
> 
> $ ipset list
> 
> Name: NIPv43c228055-2735-4339-b9a8-
> Type: hash:net
> Revision: 4
> Header: family inet hashsize 1024 maxelem 65536
> Size in memory: 512
> References: 1
> Members:
> 172.16.0.5
> 172.16.0.10
> 
> Name: NIPv63c228055-2735-4339-b9a8-
> Type: hash:net
> Revision: 4
> Header: family inet6 hashsize 1024 maxelem 65536
> Size in memory: 1152
> References: 1
> Members:
> 
> So, this rule is going to pass just packets that src is in 172.16.0.0/24, the private (tenant) network. 
> 
> Although the rules listed have 'IPv4 Any Any' as if passing anything, theses rules just permit packets from one VM to another in the same private network. 
> 
> To allow packets to a floating IP it's required other rules that pass to a specific floating IP address (or network, or all 0.0.0.0/0). As listed (dashboard), at right column 'Remote Security Group Actions' we shouldn't have 'default'.
> 
> Direction EtherType    IP Protocol Port Range       Remote IP Prefix    Remote Security Group Actions
> Ingress   IPv4            Any           Any                   -                           default <--- pass for the private network
> and 
> Ingress   IPv4            Any           Any                   0.0.0.0/0                -  <--- pass for floating ips 
> 
> Iptables is something like:
> 
> Chain neutron-openvswi-i7a7a669c-3 (1 references)
>  pkts bytes target     prot opt in     out     source               destination         
> .....
>     0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0           match-set NIPv43c228055-2735-4339-b9a8- src
>     0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0           
> .....
> 
> So, what I needed to do was create a new security group for traffic from external networks to internal networks, without use the "default security group" as destination, because this is translated to the ipset match-set rule. 
> 
> Thank you so much!
> 
> - JLC
> 
>> On Fri, Apr 15, 2016 at 11:30 AM, Remo Mattei <remo at italy1.com> wrote:
>> one more thing to know what version (liberty? Mitaka?)
>> 
>> The security rules don’t get set with the new Mitaka so just make sure that you do set them, I have seen issues where the instance does not behave well and if you do set the SG make sure you have the ports open as Peter stated below.
>> 
>> Remo
>> > On Apr 15, 2016, at 10:14, Erdősi Péter <fazy at niif.hu> wrote:
>> >
>> > 2016. 04. 15. 15:41 keltezéssel, Jorge Luiz Correa írta:
>> >> I think that in neutron-openvswi-i7a7a669c-3 should exist some RETURN rule using the 172.16.0.5 IP address.
>> > Just a fast thought:
>> > Did you assigned a security group with icmp enabled rule to your VM?
>> >
>> > I think, thats will made your exception to avoid DROP at the end...
>> >
>> > Regards:
>> > Peter
>> >
>> > _______________________________________________
>> > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>> > Post to     : openstack at lists.openstack.org
>> > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>> >
>> > 
>> >
> 
> !DSPAM:1,57112b1517039594946585!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20160415/5975f59c/attachment.html>


More information about the Openstack mailing list