When ACL is applied to a subnet, the action allow-related affects the other actions，such as drop

[BigCousin-z]

configure as：
ovn-nbctl acl-list subnet
1：to-lport 2000 (ip4.src == 100.100.200.0/24) drop

The network from ping 100.100.100.2 to 100.100.200.2 is not work.

when I modify the configure ，as：
ovn-nbctl acl-list subnet
1：to-lport 2000 (ip4.src == 100.100.200.0/24) drop
2：to-lport 2000 (ip4.src == 1.2.3.4/24) allow-related

The network from ping 100.100.100.2 to 100.100.200.2 is connected.

Will allow related-affect the correctness of other rule actions?

[BigCousin-z]

ovn : 21.12.3
ovs : 2.17.5

The acl rule applies to the ls。

[dceara]

@BigCousin-z thanks for the report!

However, this is expected behavior, as allow-related ACLs rely on conntrack to allow reply traffic for sessions allowed in the original direction.

For this ICMP exchange, in the first case (no "allow-related" ACL):
a. ICMP request from 100.100.100.2 -> 100.100.200.2 is allowed to reach the destination (the drop rule is for source 100.100.200.2)
b. ICMP reply from 100.100.200.2 -> 100.100.100.2 is dropped in the egress pipeline before reaching the destination (matches the drop rule)

In the second case ("allow-related" ACL):
a. ICMP request from 100.100.100.2 -> 100.100.200.2 creates a conntrack entry in the zone of the LSP connected to 100.100.100.2
b. ICMP request from 100.100.100.2 -> 100.100.200.2 is allowed to reach the destination (the drop rule is for source 100.100.200.2)
c. ICMP reply from 100.100.200.2 -> 100.100.100.2 is allowed in the ingress pipeline (from LSP connected to 100.100.200.2)
d. in the egress pipeline the ICMP reply matches the conntrack entry created at step "a" so the packet is allowed towards 100.100.100.2

I'm not completely sure what policy you're trying to implement with these ACLs. If you share that we might be able to help you figure out the correct way of defining the ACLs.

Regards,
Dumitru

[BigCousin-z]

@dceara thanks for your answer.
I did another test, and if I add a default rule like 0.0.0.0/0 drop, like this：
ovn-nbctl acl-list subnet
1：to-lport 2000 (ip4.src == 100.100.200.0/24) drop
2：to-lport 2000 (ip4.src == 1.2.3.4/24) allow-related
3：to-lport 1999 (ip4.src == 0.0.0.0/0) drop
The network from ping 100.100.100.2 to 100.100.200.2 is not work.

For this result， ACL has a "allow-related" ，but why is it not based on the action “conntrack entry created at step "a" ” , but rather on the action drop rule of “0.0.0.0/0”？

[dceara]

@dceara thanks for your answer. I did another test, and if I add a default rule like 0.0.0.0/0 drop, like this： ovn-nbctl acl-list subnet 1：to-lport 2000 (ip4.src == 100.100.200.0/24) drop 2：to-lport 2000 (ip4.src == 1.2.3.4/24) allow-related 3：to-lport 1999 (ip4.src == 0.0.0.0/0) drop The network from ping 100.100.100.2 to 100.100.200.2 is not work.

For this result， ACL has a "allow-related" ，but why is it not based on the action “conntrack entry created at step "a" ” , but rather on the action drop rule of “0.0.0.0/0”？

That's because the traffic that initiates the connection (ICMP request 100.100.100.2 -> 100.100.200.2) doesn't match the "allow-related" ACL, it actually matches the drop rule ("3"). So in this case the ICMP request doesn't even reach the destination.

[BigCousin-z]

@dceara thanks for your answer. I did another test, and if I add a default rule like 0.0.0.0/0 drop, like this： ovn-nbctl acl-list subnet 1：to-lport 2000 (ip4.src == 100.100.200.0/24) drop 2：to-lport 2000 (ip4.src == 1.2.3.4/24) allow-related 3：to-lport 1999 (ip4.src == 0.0.0.0/0) drop The network from ping 100.100.100.2 to 100.100.200.2 is not work.
For this result， ACL has a "allow-related" ，but why is it not based on the action “conntrack entry created at step "a" ” , but rather on the action drop rule of “0.0.0.0/0”？

That's because the traffic that initiates the connection (ICMP request 100.100.100.2 -> 100.100.200.2) doesn't match the "allow-related" ACL, it actually matches the drop rule ("3"). So in this case the ICMP request doesn't even reach the destination.

Yes, this statement is understandable to me，but if the ACL rules in the subnet cannot take effect after establishing the conntrack tab，what tool or commands can be used to configure them to take effect in the conntrack table?

[BigCousin-z]

@dceara thanks for your answer. I did another test, and if I add a default rule like 0.0.0.0/0 drop, like this： ovn-nbctl acl-list subnet 1：to-lport 2000 (ip4.src == 100.100.200.0/24) drop 2：to-lport 2000 (ip4.src == 1.2.3.4/24) allow-related 3：to-lport 1999 (ip4.src == 0.0.0.0/0) drop The network from ping 100.100.100.2 to 100.100.200.2 is not work.
For this result， ACL has a "allow-related" ，but why is it not based on the action “conntrack entry created at step "a" ” , but rather on the action drop rule of “0.0.0.0/0”？

That's because the traffic that initiates the connection (ICMP request 100.100.100.2 -> 100.100.200.2) doesn't match the "allow-related" ACL, it actually matches the drop rule ("3"). So in this case the ICMP request doesn't even reach the destination.

I have a question, the establishment of conntrack initiates needs to be bidirectional, the request 100.100.100.2->100.100.200.2 passed, but relpy 100.100.200.2->100.100.100.2 did not come back, how does conntrack deal with it at this time?

[dceara]

@dceara thanks for your answer. I did another test, and if I add a default rule like 0.0.0.0/0 drop, like this： ovn-nbctl acl-list subnet 1：to-lport 2000 (ip4.src == 100.100.200.0/24) drop 2：to-lport 2000 (ip4.src == 1.2.3.4/24) allow-related 3：to-lport 1999 (ip4.src == 0.0.0.0/0) drop The network from ping 100.100.100.2 to 100.100.200.2 is not work.
For this result， ACL has a "allow-related" ，but why is it not based on the action “conntrack entry created at step "a" ” , but rather on the action drop rule of “0.0.0.0/0”？

That's because the traffic that initiates the connection (ICMP request 100.100.100.2 -> 100.100.200.2) doesn't match the "allow-related" ACL, it actually matches the drop rule ("3"). So in this case the ICMP request doesn't even reach the destination.

I have a question, the establishment of conntrack initiates needs to be bidirectional, the request 100.100.100.2->100.100.200.2 passed, but relpy 100.100.200.2->100.100.100.2 did not come back, how does conntrack deal with it at this time?

If the reply doesn't come back (doesn't get sent to conntrack in the same zones as the request) then the conntrack entry stays in state UNREPLIED. But the reason why the reply doesn't get sent to conntrack is what should be investigated. Do you have a NB database we can have a look at?