This applies to iptables-based security group implementation too. It is not specific to FWaaS.
Previously we have the similar issue in floating IP association, and it was fixed by clearing related conntrackd entries. I think it is worth investigate for iptables related implementations (both secgroup and fwaas). Akihiro 2015-04-09 7:47 GMT+09:00 Itsuro ODA <[email protected]>: > Hi, > > I think Kazuhiro's concern is that if one want to delete an "allow" rule > or change an "allow" rule to "deny" rule, it is not work correctly because > a conntrack entry made by previous communication is not deleted in the > current implementation. > > Thanks, > Itsuto Oda > > On Wed, 8 Apr 2015 11:37:29 -0700 > Rajesh Mohan <[email protected]> wrote: > >> Hi Miyashita, >> >> The second rule is 'accept' on state being 'established' or 'related'. In >> case of ICMP, if a request has gone out from inside network, then the reply >> to that will match this rule. A new ICMP message initiated from outside >> will not match this rule. >> >> I hope I understood your question correctly. Let me know if this addresses >> your concern. >> >> Thanks, >> -Rajesh Mohan >> >> >> >> On Mon, Mar 30, 2015 at 1:58 AM, Miyashita, Kazuhiro <[email protected]> >> wrote: >> >> > Hi, >> > >> > >> > >> > I want to ask about FWaaS iptables rule implementation. >> > >> > firewall rule are deployed as iptables rules in network node , and ACCEPT >> > target is set at second rule(*). >> > >> > >> > >> > ---- >> > >> > Chain neutron-l3-agent-iv431d7bfbc (1 references) >> > >> > pkts bytes target prot opt in out source >> > destination >> > >> > 0 0 DROP all -- * * 0.0.0.0/0 >> > 0.0.0.0/0 state INVALID >> > >> > 0 0 ACCEPT all -- * * 0.0.0.0/0 >> > 0.0.0.0/0 state RELATED,ESTABLISHED (*) >> > >> > 0 0 neutron-l3-agent-liA31d7bfbc tcp -- * * >> > 172.16.2.0/23 1.2.3.4 tcp spts:1025:65535 dpt:80 >> > >> > 0 0 neutron-l3-agent-liA31d7bfbc tcp -- * * >> > 172.16.6.0/24 1.2.3.4 tcp spts:1025:65535 dpt:80 >> > >> > 0 0 neutron-l3-agent-liA31d7bfbc tcp -- * * >> > 1.2.3.4 172.16.14.0/24 tcp spts:1025:65535 dpt:11051 >> > >> > 0 0 neutron-l3-agent-liA31d7bfbc tcp -- * * >> > 10.3.0.0/24 1.2.3.4 tcp spts:1025:65535 dpt:22 >> > >> > 0 0 neutron-l3-agent-liD31d7bfbc all -- * * >> > 0.0.0.0/0 0.0.0.0/0 >> > >> > ---- >> > >> > >> > >> > Why is ACCEPT rule set at second in iptables rule. Performance reason(ICMP >> > or other protocol such as UDP/TCP)? >> > >> > >> > >> > This causes some wrong scenario for example... >> > >> > >> > >> > [outside openstack cloud] ---> Firewall(FWaaS) --> [inside openstack cloud] >> > >> > >> > >> > 1) admin create Firewall and create Filrewall rule accepting ICMP request >> > from outside openstack cloud, and >> > >> > 2) ICMP request packets incoming from outside to inside, and >> > >> > 3) someday, admin detects that ICMP rule is security vulnerability and >> > create Firewall rule blocking ICMP request from outside. >> > >> > >> > >> > but ICMP request packets still incoming due to ACCEPT rule(*), because >> > ICMP connection still hit rule at second(*). >> > >> > >> > >> > Thanks. >> > >> > >> > >> > kazuhiro MIYASHITA >> > >> > >> > >> > >> > >> > __________________________________________________________________________ >> > OpenStack Development Mailing List (not for usage questions) >> > Unsubscribe: [email protected]?subject:unsubscribe >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> > > > -- > Itsuro ODA <[email protected]> > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Akihiro Motoki <[email protected]> __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
