-
Bug
-
Resolution: Done
-
Undefined
-
None
-
None
-
False
-
-
False
-
-
With the following configuration:
ovn-nbctl --portrange lr-nat-add rtr snat 66.66.66.66 42.42.42.0/24 10000-20000
When client initiates a connection from behind the SNAT,
e.g.:
43.43.43.2:40000 -> 42.42.42.2:8080
this get's SNATed to:
66.66.66.66:X -> 42.42.42.2:80
with X being a random value in the 10000-20000 range. Until
here the behavior is as expected.
Now, if we change the client and initiate connections with a
source port that's already in the desired range, e.g.:
43.43.43.2:15000 -> 42.42.42.2:8080
then PAT doesn't happen anymore and only the source IP gets
translated:
66.66.66.66:15000 -> 42.42.42.2:80
Checking why that happens I see it's because of the way OVN
configures the SNAT openflow. The openflow action is:
ct(commit,table=46,zone=NXM_NX_REG12[0..15],nat(src=66.66.66.66:10000-20000))
This leaves the nat flags set to default (0) which AFAICT,
with the kernel datapath, eventually ends up translating to
NF_NAT_RANGE_PROTO_RANDOM:
https://elixir.bootlin.com/linux/latest/source/include/uapi/linux/netfilter/nf_nat.h#L10
With this, conntrack will not do PAT unless needed. However,
checking the ovs-actions manual:
"ports The L4 port or range port1-port2 from which
the translated port should be selected. When
a port range is specified, fallback to
ephemeral ports does not happen, else, it
will. The port number selection can be
informed by the optional random and hash
flags described below. The userspace
datapath only supports the hash behavior"
If we explicitly request random hashing then the datapath
will use NF_NAT_RANGE_PROTO_RANDOM_FULLY and always perform
PAT.
Reported upstream at:
https://mail.openvswitch.org/pipermail/ovs-dev/2024-January/410847.html
- blocks
-
RFE-4980 SNAT Source Port Randomization
-
- Accepted
-
- is cloned by
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
- links to
