ICMP packet to FIP is blocked

[Yuli]

Hello

By default, when adding a new VM, default SG is applied to this new VM.
If found the following problem.

When sending ping to FIP, the default rules added to table 77 block the icmp request.

These are the default rules created when adding new VM:

 table=77, n_packets=2, n_bytes=247, priority=65534,ct_state=-new+est-rel-inv+trk actions=goto_table:78
 table=77, n_packets=0, n_bytes=0, priority=65534,ct_state=-new+rel-inv+trk actions=goto_table:78
 table=77, n_packets=0, n_bytes=0, priority=65534,ct_state=+new+rel-inv+trk,ip actions=ct(commit,table=78,zone=NXM_NX_CT_ZONE[])
 table=77, n_packets=0, n_bytes=0, priority=65534,ct_state=+inv+trk actions=drop
 table=77, n_packets=0, n_bytes=0, priority=3,conj_id=1,ip actions=ct(commit,table=78,zone=NXM_NX_CT_ZONE[])
 table=77, n_packets=0, n_bytes=0, priority=3,ip,nw_src=10.0.0.3 actions=conjunction(1,2/2)
 table=77, n_packets=0, n_bytes=0, priority=3,ct_state=+new-est-rel-inv+trk,reg7=0x6 actions=conjunction(1,1/2)
 table=77, n_packets=1400, n_bytes=137200, priority=1 actions=drop

As you can see priority=3,ip,nw_src=10.0.0.3 actions=conjunction(1,2/2) is rule is wrong.
There should be no ip address here.

When creating new SG ad adding inside it a rule to allow ICMP-ANY the following rules acre created:
 table=77, n_packets=130, n_bytes=12791, priority=65534,ct_state=-new+est-rel-inv+trk actions=goto_table:78
 table=77, n_packets=0, n_bytes=0, priority=65534,ct_state=-new+rel-inv+trk actions=goto_table:78
 table=77, n_packets=0, n_bytes=0, priority=65534,ct_state=+new+rel-inv+trk,ip actions=ct(commit,table=78,zone=NXM_NX_CT_ZONE[])
 table=77, n_packets=0, n_bytes=0, priority=65534,ct_state=+inv+trk actions=drop
 table=77, n_packets=2, n_bytes=196, priority=4,conj_id=2,ip actions=ct(commit,table=78,zone=NXM_NX_CT_ZONE[])
 table=77, n_packets=0, n_bytes=0, priority=4,icmp actions=conjunction(2,2/2)
 table=77, n_packets=0, n_bytes=0, priority=4,ct_state=+new-est-rel-inv+trk,reg7=0x6 actions=conjunction(2,1/2)
 table=77, n_packets=1888, n_bytes=185024, priority=1 actions=drop

Now everything works.

[Yuli (stremovsky)]

When tracing this bug I found the following.

Sometime in database in secgroup table in rule record, the remote_group_id has the same value as a secgroup id

For example:

------------------------------------------------------------
Table = secgroup
------------------------------------------------------------
Key = a79c9d00-e2ca-4107-a008-16a3f57e309e , Value = {"topic": "fbb212277633433d980dc71fa0bb6321",
"rules": [
{"direction": "ingress", "protocol": null, "description": "",
"port_range_max": null, "topic": "fbb212277633433d980dc71fa0bb6321",
"id": "6835b015-1211-4d7a-bdad-c2cd74d93150",
"remote_group_id": "a79c9d00-e2ca-4107-a008-16a3f57e309e", "remote_ip_prefix": null, "security_group_id": "a79c9d00-e2ca-4107-a008-16a3f57e309e", "port_range_min": null,
"ethertype": "IPv4"},

the Key = rules[0]['remote_group_id']

[Li Ma (nick-ma-z)]

The ICMP to subnet gateway is also blocked in my latest devstack environment. I think it was working.

[Yuli (stremovsky)]

Hello

It turns out that it is a default behavior.

When creating Default security group the Ingress rules
has 2 rules : allow any traffic from "default" security group.

The default security group entity refers only to VMs that has
this default group. It does not refers to all IPs !

As a result we have this specific rule and when sending packet
from outside it got blocked.

So, by creating a new SG and specifying all CIDR of 0.0.0.0/0
for Ingress rule we can actually allow specify what ports/protocol
to allow for all other IPs from outside world.

[Yuli (stremovsky)]

Closing this bug as invalid.