In OpenStack/Contrail, Security Groups (SG) are a security mechanism that are used to control both inbound and outbound VM traffic. Without proper settings of the SGs, network traffic between the VMs will get disrupted.
In this article, the behavior of Security Groups is explained based on an example where one VM is able to ping the other, whereas a ping in the opposite direction fails.
A Security Group is a set of rules that is used to filter traffic to or from VM instances. Any incoming or outgoing traffic that is not matched by the associated rules will be denied. Newly spawned VM instances are assigned to the default Security Group if not explicitly specified. There is no limitation on outgoing traffic from the VM instances with the default Security Group. However, VM instances with the default Security Group allow incoming traffic only from instances with the same Security Group and reject traffic from other SGs.
Default Security Group Rules and Details
Example
Assume that there are two VMs:
VMa has IP address 10.10.10.3 in node14.
VMb has IP address 10.10.10.4 in node15.
VMa is attached to the default Security Group.
VMb is attached to a custom Security Group " sg_any ," which has no constraints on both ingress and egress traffic.
Since there is no limitation on egress traffic from VM instances with the default Security Group, ping from VMa to VMb succeeds.
$ ping 10.10.10.4 -c 6 PING 10.10.10.4 (10.10.10.4): 56 data bytes 64 bytes from 10.10.10.4: seq=0 ttl=64 time=12.462 ms 64 bytes from 10.10.10.4: seq=1 ttl=64 time=1.239 ms 64 bytes from 10.10.10.4: seq=2 ttl=64 time=7.619 ms 64 bytes from 10.10.10.4: seq=3 ttl=64 time=2.990 ms 64 bytes from 10.10.10.4: seq=4 ttl=64 time=11.452 ms 64 bytes from 10.10.10.4: seq=5 ttl=64 time=1.185 ms --- 10.10.10.4 ping statistics --- 6 packets transmitted, 6 packets received, 0% packet loss round-trip min/avg/max = 1.185/6.157/12.462 ms
The flows are installed in both vRouters and Action is set to F (Forward).
node14
root@node14:~# flow --match 10.10.10.4 Flow table(size 80609280, entries 629760) Entries: Created 2181 Added 2180 Deleted 48 Changed 50 Processed 2181 Used Overflow entries 0 (Created Flows/CPU: 60 78 36 34 743 34 28 34 18 28 907 36 49 27 30 39)(oflows 0) Action:F=Forward, D=Drop N=NAT(S=SNAT, D=DNAT, Ps=SPAT, Pd=DPAT, L=Link Local Port) Other:K(nh)=Key_Nexthop, S(nh)=RPF_Nexthop Flags:E=Evicted, Ec=Evict Candidate, N=New Flow, M=Modified Dm=Delete Marked TCP(r=reverse):S=SYN, F=FIN, R=RST, C=HalfClose, E=Established, D=Dead Listing flows matching ([10.10.10.4]:*) Index Source:Port/Destination:Port Proto(V) ----------------------------------------------------------------------------------- 182344<=>484956 10.10.10.3:43777 1 (1) 10.10.10.4:0 (Gen: 1, K(nh):24, Action:F, Flags:, QOS:-1, S(nh):24, Stats:6/588, SPort 62723, TTL 0, Sinfo 4.0.0.0) 484956<=>182344 10.10.10.4:43777 1 (1) 10.10.10.3:0 (Gen: 1, K(nh):24, Action:F, Flags:, QOS:-1, S(nh):32, Stats:6/588, SPort 55915, TTL 0, Sinfo 10.168.10.15)
root@node14:~# flow --match 10.10.10.4
Flow table(size 80609280, entries 629760) Entries: Created 2181 Added 2180 Deleted 48 Changed 50 Processed 2181 Used Overflow entries 0 (Created Flows/CPU: 60 78 36 34 743 34 28 34 18 28 907 36 49 27 30 39)(oflows 0) Action:F=Forward, D=Drop N=NAT(S=SNAT, D=DNAT, Ps=SPAT, Pd=DPAT, L=Link Local Port) Other:K(nh)=Key_Nexthop, S(nh)=RPF_Nexthop Flags:E=Evicted, Ec=Evict Candidate, N=New Flow, M=Modified Dm=Delete Marked TCP(r=reverse):S=SYN, F=FIN, R=RST, C=HalfClose, E=Established, D=Dead Listing flows matching ([10.10.10.4]:*) Index Source:Port/Destination:Port Proto(V) ----------------------------------------------------------------------------------- 182344<=>484956 10.10.10.3:43777 1 (1) 10.10.10.4:0 (Gen: 1, K(nh):24, Action:F, Flags:, QOS:-1, S(nh):24, Stats:6/588, SPort 62723, TTL 0, Sinfo 4.0.0.0) 484956<=>182344 10.10.10.4:43777 1 (1) 10.10.10.3:0 (Gen: 1, K(nh):24, Action:F, Flags:, QOS:-1, S(nh):32, Stats:6/588, SPort 55915, TTL 0, Sinfo 10.168.10.15)
node15
root@node15:~# flow --match 10.10.10.3 Flow table(size 80609280, entries 629760) Entries: Created 87 Added 87 Deleted 128 Changed 128 Processed 87 Used Overflow entries 0 (Created Flows/CPU: 8 14 20 5 22 3 1 2 0 2 1 6 2 1 0 0)(oflows 0) Action:F=Forward, D=Drop N=NAT(S=SNAT, D=DNAT, Ps=SPAT, Pd=DPAT, L=Link Local Port) Other:K(nh)=Key_Nexthop, S(nh)=RPF_Nexthop Flags:E=Evicted, Ec=Evict Candidate, N=New Flow, M=Modified Dm=Delete Marked TCP(r=reverse):S=SYN, F=FIN, R=RST, C=HalfClose, E=Established, D=Dead Listing flows matching ([10.10.10.3]:*) Index Source:Port/Destination:Port Proto(V) ----------------------------------------------------------------------------------- 103984<=>334404 10.10.10.3:43777 1 (2) 10.10.10.4:0 (Gen: 1, K(nh):37, Action:F, Flags:, QOS:-1, S(nh):26, Stats:6/588, SPort 63924, TTL 0, Sinfo 10.168.10.14) 334404<=>103984 10.10.10.4:43777 1 (2) 10.10.10.3:0 (Gen: 1, K(nh):37, Action:F, Flags:, QOS:-1, S(nh):37, Stats:6/588, SPort 55381, TTL 0, Sinfo 4.0.0.0)
However, when pinging from VMb to VMa, the packets are dropped at the VMa interface because the default Security Group rejects outside IP addresses from other Security Group.
$ ping 10.10.10.3 -c 10 PING 10.10.10.3 (10.10.10.3): 56 data bytes --- 10.10.10.3 ping statistics --- 10 packets transmitted, 0 packets received, 100% packet loss
Since there is no constraint for outgoing traffic from VMb as defined in the SG sg_any , the flows are installed in node15 with the Action Forward. On the other hand, for VMa in node14, the packets are dropped by flow Action:D(SG) , which indicates that the reason for packet drop is the Security Group. The packets are rejected due to the default ingress traffic filter at VMa.
node15:
root@node15:~# flow --match 10.10.10.3 Flow table(size 80609280, entries 629760) Entries: Created 90 Added 90 Deleted 130 Changed 130 Processed 90 Used Overflow entries 0 (Created Flows/CPU: 8 14 20 5 22 3 1 2 0 2 2 6 4 1 0 0)(oflows 0) Action:F=Forward, D=Drop N=NAT(S=SNAT, D=DNAT, Ps=SPAT, Pd=DPAT, L=Link Local Port) Other:K(nh)=Key_Nexthop, S(nh)=RPF_Nexthop Flags:E=Evicted, Ec=Evict Candidate, N=New Flow, M=Modified Dm=Delete Marked TCP(r=reverse):S=SYN, F=FIN, R=RST, C=HalfClose, E=Established, D=Dead Listing flows matching ([10.10.10.3]:*) Index Source:Port/Destination:Port Proto(V) ----------------------------------------------------------------------------------- 28052<=>394036 10.10.10.4:42241 1 (2) 10.10.10.3:0 (Gen: 1, K(nh):37, Action:F, Flags:, QOS:-1, S(nh):37, Stats:10/980, SPort 54205, TTL 0, Sinfo 4.0.0.0) 394036<=>28052 10.10.10.3:42241 1 (2) 10.10.10.4:0 (Gen: 1, K(nh):37, Action:F, Flags:, QOS:-1, S(nh):26, Stats:0/0, SPort 64253, TTL 0, Sinfo 0.0.0.0)
node14:
root@node14:~# flow --match 10.10.10.4 Flow table(size 80609280, entries 629760) Entries: Created 2261 Added 2259 Deleted 50 Changed 52 Processed 2260 Used Overflow entries 0 (Created Flows/CPU: 61 79 40 36 777 37 28 34 18 28 937 37 49 27 30 43)(oflows 0) Action:F=Forward, D=Drop N=NAT(S=SNAT, D=DNAT, Ps=SPAT, Pd=DPAT, L=Link Local Port) Other:K(nh)=Key_Nexthop, S(nh)=RPF_Nexthop Flags:E=Evicted, Ec=Evict Candidate, N=New Flow, M=Modified Dm=Delete Marked TCP(r=reverse):S=SYN, F=FIN, R=RST, C=HalfClose, E=Established, D=Dead Listing flows matching ([10.10.10.4]:*) Index Source:Port/Destination:Port Proto(V) ----------------------------------------------------------------------------------- 138500<=>280684 10.10.10.3:42241 1 (1) 10.10.10.4:0 (Gen: 1, K(nh):24, Action:H, Flags:, QOS:-1, S(nh):24, Stats:0/0, SPort 57785, TTL 0, Sinfo 0.0.0.0) 280684<=>138500 10.10.10.4:42241 1 (1) 10.10.10.3:0 (Gen: 1, K(nh):24, Action:D(SG), Flags:, QOS:-1, S(nh):32, Stats:10/980, SPort 52344, TTL 0, Sinfo 10.168.10.15)
Therefore, Security Groups need to be configured correctly for VM instances to ensure a network connection.
The reason for the packet drop is that the default ingress traffic filter does not have the "network 0.0.0.0/0" rule. If the default Security Groups can be edited directly as "network 0.0.0.0/0" to pass traffic, creating additional custom Security Groups is not required as long as the rule is consistent in the network.