The FDP team is no longer accepting new bugs in Bugzilla. Please report your issues under FDP project in Jira. Thanks.
Bug 1949171 - userspace dp: ct(nat) action may lead to a wrong lookup if hit twice
Summary: userspace dp: ct(nat) action may lead to a wrong lookup if hit twice
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux Fast Datapath
Classification: Red Hat
Component: openvswitch2.15
Version: FDP 21.A
Hardware: Unspecified
OS: Unspecified
low
unspecified
Target Milestone: ---
: ---
Assignee: Paolo Valerio
QA Contact: Jiying Qiu
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-04-13 15:35 UTC by Paolo Valerio
Modified: 2021-09-07 18:03 UTC (History)
8 users (show)

Fixed In Version: openvswitch2.15-2.15.0-27.el8fdp
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-09-07 18:03:36 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
double bare nat outcome (2.01 KB, application/octet-stream)
2021-04-13 15:38 UTC, Paolo Valerio
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker FD-1226 0 None None None 2021-08-09 16:01:57 UTC
Red Hat Product Errata RHBA-2021:3449 0 None None None 2021-09-07 18:03:40 UTC

Description Paolo Valerio 2021-04-13 15:35:35 UTC
Description of problem:

given the following entries
tcp,orig=(src=10.1.1.1,dst=10.1.1.2,sport=10000,dport=80),reply=(src=10.1.1.2,dst=10.1.1.240,sport=80,dport=10000),protoinfo=(state=ESTABLISHED)
tcp,orig=(src=10.1.1.1,dst=192.168.2.100,sport=10000,dport=80),reply=(src=10.1.1.2,dst=10.1.1.1,sport=80,dport=10000),protoinfo=(state=ESTABLISHED)

and the replies of a snat'ed connection hit a bare nat rule twice, the resulting
source IP gets translated to 192.168.2.100 (see the attachment).

How reproducible:
Always

Steps to Reproduce:
create two namespaces
- left (iface IP: 10.1.1.1)
- right (iface IP: 10.1.1.2)

add the following rules:

table=0,ip,actions=ct(table=10,nat)
table=0,priority=10,arp,action=normal
table=10,ct_state=+rel,icmp,actions=resubmit(,20)
table=10,priority=20,ip,ct_state=+trk+new,nw_dst=192.168.2.100,actions=ct(commit,nat(dst=10.1.1.2:80),table=20)
table=10,priority=10,ip,ct_state=+trk+new,actions=ct(commit,nat(src=10.1.1.240),table=20)
table=10,priority=7,ip,ct_state=+rpl,actions=ct(table=20,nat)
table=10,priority=5,ip,ct_state=-rpl,actions=resubmit(,20)
table=10,priority=1,action=drop
table=20,priority=10,ip,nw_dst=10.1.1.1,action=ovs-l0
table=20,priority=10,ip,nw_dst=10.1.1.2,action=ovs-r0

create two connections from left to right:
nc 192.168.2.100 80 -p 10000
nc 10.1.1.2 80 -p 10000

Actual results:
- using kernel dp both connections gets established correctly
- using userspace dp the first connection gets established 

Expected results:
userspace dp should behave like kernel dp

Comment 1 Paolo Valerio 2021-04-13 15:38:14 UTC
Created attachment 1771653 [details]
double bare nat outcome

Comment 2 Paolo Valerio 2021-07-28 18:01:32 UTC
Patch got accepted upstream and backported all the way to 2.13.

https://mail.openvswitch.org/pipermail/ovs-dev/2021-July/385420.html

Comment 5 Jiying Qiu 2021-08-11 06:34:15 UTC
Verified with openvswitch2.15-2.15.0-32.el8fdp.x86_64.

Have added a case in kernel/networking/openvswitch/conntrack_dpdk/runtest.sh  ovs_conn_dnat_with_snat_pass_ipv4_test.

# ovs-appctl dpctl/dump-conntrack - L
tcp,orig=(src=10.167.54.1,dst=10.167.54.2,sport=10000,dport=3000),reply=(src=10.167.54.2,dst=10.167.54.240,sport=3000,dport=10000),protoinfo=(state=ESTABLISHED)
tcp,orig=(src=10.167.54.1,dst=172.16.54.254,sport=10000,dport=3000),reply=(src=10.167.54.2,dst=10.167.54.1,sport=3000,dport=10000),protoinfo=(state=ESTABLISHED)

Comment 7 errata-xmlrpc 2021-09-07 18:03:36 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (openvswitch2.15 bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2021:3449


Note You need to log in before you can comment on or make changes to this bug.