Dear fellow-RouterOS fans,

We have masquerade NAT configured with a single Public IP. We have an application that always uses udp source port 9000 from multiple clients on the inside. Most of the time each client is sending to a unique destination IP/udp port combination, so, ROS simply NATs the source IP address, leaving the source port the same.

This works fine and provides a unique NAT state for each connection (because the destination IP and port are unique on the outside even though the source IP and port are not). Here is an example of two client connections that work.

Client1
Request:
inside src: 10.1.1.20/udp9000 -->original dst: 1.1.1.50/udp12345
masq source: 2.2.2.29/udp9000 -->original dst: 1.1.1.50/udp12345
Reply:
dst: 1.1.1.50/12345 --> masq source 2.2.2.29/udp 9000
dst: 1.1.1.50/12345 --> inside source 10.1.1.20/udp9000

Client2
Request:
inside src: 10.1.1.21/udp9000 -->original dst: 1.1.1.50/udp54321
masq source: 2.2.2.29/udp9000 -->original dst: 1.1.1.50/udp54321
Reply:
dst: 1.1.1.50/54321 --> masq source 2.2.2.29/udp 9000
dst: 1.1.1.50/54321 --> inside source 10.1.1.21/udp9000

Here's when this does not work so well: On occasion, two clients, both using source udp9000, need to connect to the same destination IP/udp port. When this happens, ROS does not appear to PAT the source address from the second client. So, the reply traffic for the first client works until the second client connects, then ROS starts sending all reply traffic (for both connections) to the second client. In the example below the * NAT/PATs do not result in two unique NAT/PAT states, so ROS appears to get confused.

Client1
Request:
inside src: 10.1.1.20/udp9000 -->original dst: 1.1.1.50/udp12345
masq source: 2.2.2.29/udp9000 -->original dst: 1.1.1.50/udp12345 *
Reply:
dst: 1.1.1.50/udp12345 --> masq source 2.2.2.29/udp 9000
dst: 1.1.1.50/udp12345 --> inside source 10.1.1.20/udp9000 (this NAT state gets replaced by Client2's connection)

Client2
Request:
inside src: 10.1.1.21/udp9000 -->original dst: 1.1.1.50/udp12345
masq source: 2.2.2.29/udp9000 -->original dst: 1.1.1.50/udp12345 *
Reply:
dst: 1.1.1.50/udp12345 --> masq source 2.2.2.29/udp 9000
dst: 1.1.1.50/udp12345 --> inside source 10.1.1.21/udp9000

I can work around this problem by setting up rules that src-nat 9000 to something unique for each client. However, does this sound like a bug? Is there possibly a feature that I do not have turned on that might alleviate this issue? The ROS behavior seems like it breaks the rules of basic NAT/PAT. Maybe the application is just not NAT-friendly.

I would appreciate your comments or suggestions.

Thanks,
Lea Anne

It's a problem that also breaks L2TP through NAT but is common in most NAT "engines". In your case, if it is feasible, I'd mark the udp packets with a connection mark for each host and src-nat each mark to a different port range. IMHO current behavior is not really flexible.

I have not tryed this, but could you not do dst-nat, based upon your connection-mark?

And as sten said, mark each client connection, then based upon the port 9000 and the client connection-mark, redirect the packets to the correct client...

Is this not how helpers work, using connection tracking?

I have this problem so.
but my clients use pptp connections.
I think if we nat for example 10 valid IP to 100 invalid IP we will be success. but i cant nat 2 times in mikrotik.
do you know how must i do this?

Thanks for the suggestions sten and tgrand. Since the connection is initiated by the clients, the src-nat idea with marking allowed me to simplify the individual src-nat rules. I could not find a way to do it with less than 1 src-nat rule per client IP. If anyone knows of a more elegant way to do this, please sing out:

/ ip firewall mangle add chain=forward dst-address=1.1.1.50 protocol=udp src-port=9000 action=mark-connection new-connection-mark=udp9000 passthrough=yes comment="Mark 9000 connections for source port translation" disabled=no

/ ip firewall nat add chain=srcnat src-address=10.1.1.20 connection-mark=udp9000 action=src-nat to-addresses=2.2.2.29 to-ports=9020 comment="Connection-marked fixup for port 9000 per IP address" disabled=no
/ ip firewall nat add chain=srcnat src-address=10.1.1.21 connection-mark=udp9000 action=src-nat to-addresses=2.2.2.29 to-ports=9021 comment="" disabled=no

Thanks,
Lea Anne