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

idst · Wed Nov 04, 2020 11:08 am

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,

mkx · Wed Nov 04, 2020 12:06 pm

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.

sindy · Wed Nov 04, 2020 12:19 pm

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

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...

mkx · Wed Nov 04, 2020 12:37 pm

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 ...

sindy · Wed Nov 04, 2020 12:53 pm

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:

formatted code

[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 failure

sniffing on the target machine:

formatted code

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 no
ether1                  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

Sob · Wed Nov 04, 2020 1:07 pm

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

sindy · Wed Nov 04, 2020 2:17 pm

I use ranges like this for ftp server's passive ports.

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

anav · Wed Nov 04, 2020 2:53 pm

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!!!!!

Sob · Wed Nov 04, 2020 8:03 pm

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

anav · Wed Nov 04, 2020 9:31 pm

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...........

idst · Thu Nov 05, 2020 4:56 pm

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.

sindy · Thu Nov 05, 2020 5:17 pm

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.

anav · Thu Nov 05, 2020 7:11 pm

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.....

sindy · Thu Nov 05, 2020 7:34 pm

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.

anav · Thu Nov 05, 2020 11:50 pm

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