… I think this is wrong and using one zone per Security Group would probably
solve this specific issue.
>>>>>>>>>>>>>>>>
[Darrell] Yes, using zoning differently was one suggestion back in Aug/2017 to
solve the issue.
However, there is a more fundamental problem.
Here is an excerpt sent from Rohith on Aug 29/2017 for the connection b/w VM1
and VM2
“
VM1 and VM2 VMs are on same compute node but with different SGs.
For VM1, security rules configured are as below:
Egress/Ingress Allow all
For VM2,
Egress Allow all
Ingress Allow only from VMs which are in same security group.
So if I ping from VM1 to VM2 then VM1 should be able to send the ICMP request
but
It should not reach VM2 and it should get dropped at the ingress side of VM2.
Since Both VMs are in same network, they will landup in having same zones.
Since VM1 needs to allow all ingress/egress traffic it needs to have the
following rule.
cookie=0x0, duration=128.074s, table=214, n_packets=1, n_bytes=98,
priority=1000,ct_state=+new+trk,ip,metadata=0x19f40000000000/0x1fffff0000000000
actions=ct(commit,zone=5021),resubmit(,17)
“
VM1 has no access restrictions.
VM2 is a restricted access VM, however the connection (the only one being used
b/w these VMs) is being committed in its untrusted
direction (i.e. coming into VM2).
<<<<<<<<<<<<<<<<<
[Jan] I think we all agree that design in ODL to use the same conntrack zone
for VMs in different SGs is not correct given the semantics of the userspace
conntrack. The connection should be tracked independently for each SG.
The problem is that the kernel conntrack semantics and behavior is different.
That is what the ODL developers have based their implementation on (as it
existed first). The connection committed on the on the sending side is not yet
considered established at the second lookup on the receiving side because
conntrack hasn’t seen a reply packet yet. Hence the ct() lookup still returns
+trk+new and the ingress SG filter of VM2 drops the packet.
Our main point is that OVS conntrack behavior should be consistent between
kernel and userspace, at least for such basic functionality. Since the kernel
conntrack has set the standard (which is used also outside OVS) we think
userspace conntrack should follow the kernel semantics and return +est only for
connections that are established in both directions. And we should clarify the
documentation accordingly.
Independent of that we will still push for a more correct use of zones in ODL
Security Group implementation.
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
