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