DNAT PortRange missbehaves

[modzilla99]

Hey there,

we are on OVN 23.06 and face an issue when using the portrange dnat option. Our main use is to Port-Forward IPSEC ports to a VM.

The PAT on the set ports works properly, but every other port that's not the selected Port will be forwarded to a port in the selected range. So if I used port 22 every other Port would forward the traffic to the SSH port. ssh -p 1234 $IP would therefore work. If you select more than one port all the traffic would be loadbalanced between the selected ports in a round-robin fashion.

The only way to not run into this behaviour is to port-forward all ports 1-65535 and let the SecurityGroup/ACLs handle the rest.

Example

$ ovn-nbctl --portrange lr-nat-add neutron-e6777adf-ec9f-4cf1-b954-736133ce5c3f dnat 1.1.1.1 10.0.0.250 22-23
$ ssh -p 2323 ubuntu@1.1.1.1
ubuntu@1.1.1.1: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
$ ssh -p 2323 ubuntu@1.1.1.1
^C                                 # No response
$ ssh -p 26 ubuntu@1.1.1.1
ubuntu@1.1.1.1: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
$ ssh -p 26 ubuntu@1.1.1.1
^C                                 # No response
$ ovn-nbctl --portrange lr-nat-add neutron-e6777adf-ec9f-4cf1-b954-736133ce5c3f dnat 1.1.1.1 10.0.0.250 22-22
$ ssh -p 2323 ubuntu@1.1.1.1
ubuntu@1.1.1.1: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
$ ssh -p 26 ubuntu@1.1.1.1
ubuntu@1.1.1.1: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
$ ssh -p 5175 ubuntu@1.1.1.1
ubuntu@1.1.1.1: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

Best regards.

[dceara]

@modzilla99 If I understand correctly your use case I guess there's a confusion of terms here. The external_port_range attribute on a NAT entry instructs OVN (and indirectly conntrack) what range of ports it should use when (D)NATing traffic destined to that IP:

ovn/ovn-nb.xml

Lines 3763 to 3767 in dc34b4d

	<p>
	Range of ports, from which a port number will be picked that will
	replace the source port of to be NATed packet. This is basically
	PAT (port address translation).
	</p>

With your example, ovn-nbctl --portrange lr-nat-add neutron-e6777adf-ec9f-4cf1-b954-736133ce5c3f dnat 1.1.1.1 10.0.0.250 22-23, it's expected that NAT will change the destination IP to 10.0.0.250 and will select a destination port from the range 22, 23.

So, essentially, this doesn't mean "DNAT only traffic destined to IP 1.1.1.1 and port range 22-23", it means "DNAT traffic destined to IP 1.1.1.1 and select a new destination port from range 22-23".

Or did I misunderstand your scenario?

As a side note, it shouldn't be round-robin, it should be random. But maybe that's because you're missing this recent fix:
0ef388c

Thanks,
Dumitru

[modzilla99]

So, essentially, this doesn't mean "DNAT only traffic destined to IP 1.1.1.1 and port range 22-23", it means "DNAT traffic destined to IP 1.1.1.1 and select a new destination port from range 22-23".

Ah, okay. The term PAT got me confused and I thought it was like traditional port-forwarding. Is there a way to accomplish said thing, though?

As a side note, it shouldn't be round-robin, it should be random. But maybe that's because you're missing this recent fix: 0ef388c

Yes, we don't have that patch applied. Seems like its causing it.

Or did I misunderstand your scenario?

No you did not. Thanks for the clarification.

Best regards

[dceara]

So, essentially, this doesn't mean "DNAT only traffic destined to IP 1.1.1.1 and port range 22-23", it means "DNAT traffic destined to IP 1.1.1.1 and select a new destination port from range 22-23".

Ah, okay. The term PAT got me confused and I thought it was like traditional port-forwarding. Is there a way to accomplish said thing, though?

Hmm, probably the only way is to add a (stateless maybe) ACL in the switch connecting to the router that does the DNAT. I guess that's a security group rule in OpenStack terminology.

[dceara]

Closing this as it's working as expected. Please feel free to continue the discussion but you might get more feedback by posting this question as an email to ovs-discuss@openvswitch.org.