enable_router_port_acl usage #264
Comments
|
@TVKain Patch [1] causes the ovn-controller to assign a CT zone ID to the localnet LSP but not to the dgw LSP. As a result, reply packets from the external network use the localnet’s CT zone for lookup, fail to match ACL rules, and are discarded. @dceara @putnopvut I modified the code to assign a CT zone ID to the dgw LSP on this chassis, resolving the issue. Any suggestions? [1]5ae7d2c |
shylou
added a commit
to shylou/ovn
that referenced
this issue
Apr 16, 2025
Consider the case of stateful Firewall for N-S traffic: PUBLIC---S1-(S1-R1)---------(R1-S1)-R1 -------- S2 ---- VM1 R1: dgw port 26.7.2.18, SNAT S1: localnet -> VLAN 1000, 26.7.2.0/24 S2: localnet -> VLAN 3001, 192.168.31.0/24, VM1: internal 192.168.31.200, floating 26.7.2.81 PUBLIC: 26.7.2.201 Configuration: ovn-nbctl pg-add pg_dgw ovn-nbctl pg-set-ports pg_dgw S1-R1 ovn-nbctl acl-add pg_dgw to-lport 1002 "outport == @pg_dgw && ip4" allow-related ovn-nbctl acl-add pg_dgw from-lport 1001 "inport == @pg_dgw && ip4" drop ovn-nbctl lsp-set-options S1-R1 router-port=R1-S1 enable_router_port_acl=true Before this patch, the ovn-controller assigned a CT zone ID to the localnet LSP[1] but not the dgw LSP, as the local lports excluded the dgw LSP residing on this chassis. Consequently, reply packets from the external network used the localnet's CT zone for lookup, not the dgw's CT zone, failed to match ACL rules, and were discarded. We fixed it by adding the dgw LSP residing on this chassis to local lports, allowing `ct_zones_update` to assign a zone ID to the dgw LSP. [1]ovn-org@5ae7d2c Reported-at: ovn-org#264 Signed-off-by: Xie Liu <liushyshy@gmail.com>
|
@TVKain hi，I would greatly appreciate it if you could test the attached patch [1] to validate its functionality. Please let me know if you encounter any issues or have feedback. Thank you for your time and assistance |
shylou
added a commit
to shylou/ovn
that referenced
this issue
Apr 16, 2025
Consider the case of stateful Firewall for N-S traffic: PUBLIC---S1-(S1-R1)---------(R1-S1)-R1 -------- S2 ---- VM1 Configuration: ovn-nbctl pg-add pg_dgw ovn-nbctl pg-set-ports pg_dgw S1-R1 ovn-nbctl acl-add pg_dgw from-lport 2000 "outport == @pg_dgw && ip4 && icmp4" allow-related ovn-nbctl acl-add pg_dgw from-lport 1000 "outport == @pg_dgw && ip4" drop ovn-nbctl acl-add pg_dgw to-lport 1000 "inport == @pg_dgw && ip4" drop ovn-nbctl lsp-set-options S1-R1 router-port=R1-S1 enable_router_port_acl=true VM1 pings external network. Before this patch, the ovn-controller assigned a CT zone ID to the localnet LSP[1] but not the dgw LSP, as the local lports excluded the dgw LSP residing on this chassis. Consequently, ICMP reply packets from the external network used the localnet's CT zone for lookup, not the dgw's CT zone, failed to match ACL rules, and were discarded. We fixed it by adding the dgw LSP residing on this chassis to local lports, allowing `ct_zones_update` to assign a zone ID to the dgw LSP. [1]ovn-org@5ae7d2c Reported-at: ovn-org#264 Signed-off-by: Xie Liu <liushyshy@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The commit 48397c0 added the
enable_router_port_acloption for lsp which has a dgw port peer.My goal is to set up a stateful Firewall for N-S traffic
I set up a simple topology to test it out
PUBLIC---S1-(S1-R1)-------------(R1-S1)-R1 -------- S2 ---- VM1
R1: dgw port 26.7.2.18, SNAT
S1: localnet -> VLAN 1000, 26.7.2.0/24
S2: localnet -> VLAN 3001, 192.168.31.0/24,
VM1: internal 192.168.31.200, floating 26.7.2.81
PUBLIC: 26.7.2.201
The behaviors that I want are
Actual result:
VM1 was able to initiate IMCP echo to PUBLIC, but the return traffic didn't pass through
The text was updated successfully, but these errors were encountered: