Is possible to have one dst-nat rule with a dst-port range?

RouterOS General
1

Hello,


I’m trying to combine multiple one-port dst-nat rules into an other one with the range of those ports.

These are the rules and the netcat who test them:

add action=dst-nat chain=dstnat dst-address=PUB_IP dst-port=10000 protocol=udp to-addresses=PRIV_IP
add action=dst-nat chain=dstnat dst-address=PUB_IP dst-port=10001 protocol=udp to-addresses=PRIV_IP

The test:

$ nc -v -u -z -w 3 PUB_IP 10000-10001
Connection to PUB_IP 10000 port [udp/*] succeeded!
Connection to PUB_IP 10001 port [udp/*] succeeded!

If I replace the two rules with one and with a range in dst-port, it only works the first one:

add action=dst-nat chain=dstnat dst-address=PUB_IP dst-port=10000-10001 protocol=udp to-addresses=PRIV_IP

The test:

$ nc -v -u -z -w 3 PUB_IP 10000-10001
Connection to PUB_IP 10000 port [udp/*] succeeded!

It isn’t possible or is something wrong?

Thanks,

2

If you use range on ports, then you loose control over dst-port → to-port mapping.

Apart from better readability you get by merging rules (subjective), there’s no big performance difference … if you have more or less default firewall setup which includes the usual chain=forward action=accept connection-state=established,related (and the action=fasttrack-connection variant) before these rules as the specific rules will only affect the initial packet of each connection.

3

I think the subject of the OP is different - one would expect that if you do not specify any to-ports value in a dst-nat rule, the destination port should remain unchanged, no matter whether the rule contains a match condition for dst-port or not.

So I am as surprised as the OP…

4

Indeed the NAT documentation makes impression that if to-ports is not specified, then dst-port is not changed. From OPs tests I can only assume that there’s a bug in ROS regarding this …

5

Just tried that in my pocket lab and it works as expected:

/ip firewall nat
add chain=dstnat action=dst-nat in-interface=bridge protocol=udp dst-port=20053-20054 to-addresses=192.168.227.12

input:
[me@myTik] > put [resolve some.domain server=192.168.103.1 server-port=20053]
failure: dns server failure[me@myTik] > put [resolve some.domain server=192.168.103.1 server-port=20054]
failure: dns server failuresniffing on the target machine:
ether1 55.796 1 ← 00:15:5D:FC:E9:06 00:15:5D:FC:E9:02 192.168.103.25:59314 192.168.227.12:20053 ip:udp 73 0 no
ether1 57.799 2 ← 00:15:5D:FC:E9:06 00:15:5D:FC:E9:02 192.168.103.25:52700 192.168.227.12:20053 ip:udp 73 0 no
ether1 59.809 3 ← 00:15:5D:FC:E9:06 00:15:5D:FC:E9:02 192.168.103.25:42273 192.168.227.12:20053 ip:udp 73 0 no
ether1 61.819 4 ← 00:15:5D:FC:E9:06 00:15:5D:FC:E9:02 192.168.103.25:34858 192.168.227.12:20053 ip:udp 73 0 no
ether1 63.829 5 ← 00:15:5D:FC:E9:06 00:15:5D:FC:E9:02 192.168.103.25:38904 192.168.227.12:20053 ip:udp 73 0 noether1 89.683 6 ← 00:15:5D:FC:E9:06 00:15:5D:FC:E9:02 192.168.103.25:59428 192.168.227.12:20054 ip:udp 73 0 no
ether1 91.69 7 ← 00:15:5D:FC:E9:06 00:15:5D:FC:E9:02 192.168.103.25:58185 192.168.227.12:20054 ip:udp 73 0 no
ether1 93.7 8 ← 00:15:5D:FC:E9:06 00:15:5D:FC:E9:02 192.168.103.25:40577 192.168.227.12:20054 ip:udp 73 0 no
ether1 95.71 9 ← 00:15:5D:FC:E9:06 00:15:5D:FC:E9:02 192.168.103.25:39335 192.168.227.12:20054 ip:udp 73 0 no
ether1 97.719 10 ← 00:15:5D:FC:E9:06 00:15:5D:FC:E9:02 192.168.103.25:35587 192.168.227.12:20054 ip:udp 73 0 no

6

It must work, I use ranges like this for ftp server’s passive ports. If it didn’t work, I’d notice.

7

That’s why I’ve made the test with UDP in particular.

8

We have had this discussion already. What I would like to see is one to one mapping of a range…
so if I have 2-5, as a range of dst prts, and put “too-ports” range as 12-15, then I would want 2–>12, 3–>13, 4–>14 and 5—>15 and so forth.

Do we not already assume that if we have a destination range of 2-5 WITHOUT to-ports entry that we are saying that any port between from 2-5 can be mapped to port 2-5 on the receiving server.
Is our expectation not, that incoming on port 2 go to port 2 on server and incoming on port 3 go to port 3 on incoming server… So it is not a stretch to define the to-ports with a range with a similar expectation!!!

9

That was different discussion about shifted ranges. This is simple “keep it as it is” ranges.

10

Hmmm, okay just I have always used ranges successfully on zyxel and MT routers, as well a list of random ports separated by commas, never gave it much thought…

11

I only want to get the mapping with one-to-one port, not with shifted ports, the very basic NAT over a range of ports from a public IP to a private IP with UDP.

In an other test, I also set to-ports with the same range than dst-port have, but the result is the same, it doesn’t work.

12

dst-port is only a match condition, to-ports is only a pool of destination ports to use. There is no relationship between the two. So the issue must be something else (configuration, ROS version, CPU architecture).

Start by posting the complete configuration.

13

Interesting sindy,
So if one has a range of ports 5-10 and you put in a pool of ports 5-10, are you saying the router could match 5–>10 and 6—>7 etc… you make it sound arbitrary.

Extrapolating, if one has a range of ports 5-10 and a pool of 25-30, are you saying that the router could match 5—>30 and 6—>27 etc…

14

What I am saying is that matching on original destination port and assignment of a new destination port are totally unrelated. If you do not specify any to-ports at all, the destination port is not changed; if you specify a port range in to-ports, one of ports in that range is chosen “randomly” (i.e. you cannot affect the choice). There is no mapping like "the third port in the dst-port range will be translated to the third port in the to-ports range.

15

Thanks, so are you also saying that the router may choose to randomly assign the same too port for every one of the incoming destination ports…
Do you have a copy of the code or something or is it just a theory ;-PP
Theory by Anne Elk!!!
https://www.dailymotion.com/video/x2oh8ia