Hi,
I am forwarding port for Windows remote desktop and it’s working fine.
/ip firewall nat
add action=dst-nat chain=dstnat dst-address-type=local dst-port=3389-3389 protocol=tcp to-addresses=192.168.3.10 to-ports=3389-3389
add action=masquerade chain=srcnat dst-address=192.168.3.10 dst-port=3389-3389 out-interface=ether4 protocol=tcp src-address=192.168.3.0/24
192.168.3.10 is my system’s IP and network id is - 192.168.3.0
But, when I am trying to forward some unassigned port like 3390 or 81 something like that, it’s not working. All assigned ports are working fine like - 80, 21, 22
ROS will forward any port according to NAT configuration. Whether not-so-commonly-used ports are filtered by some firewall on the way … that’s entirely different issue. Or NAT rule was written based on some misconception.
So when it seems like you can’t forward port 3390 to LAN IP, you have to investigate about why’s that … some common error would be just to forward port while not changing the destination port … like this:
then it’s likely it won’t work because connecting to port 3390 on WAN side will translate to connecting to port 3390 on LAN host and it’s quite likely no software will pick it up.
I gather this has nothing to do with normal destination nat from the wan side. Accessing the pc on the lan from the wan?
The reason I am thinking this is your masquerade rule is really weird and your destination rule is weirder still!
I would have expected something like.
dynamic wanip
add action=masquerade chain=masquerade out-interface=eth1-wan
or for static ip
add action=masquerade chain=srcnat dst-address=assigned-wan-ip out-interface=eth-1 wan
In general the dst nat rule you is also non-standard and you state address-type-local which is unusual. The format could also be cleaner.
add action=dst-nat chain=dstnat dst-port=3389 protocol=tcp to-addresses=192.168.3.10
Nothing in particular but it seems that you randomly dont like me using in-interface=eth1-wan for dst nat rules, but I cant randomly dislike dst-address-type=local rules? Tis not fair LOL.
Seriously, why is that needed to be included. WHy is it a good practice to include in general. Where could it get one in trouble.
It’s not random. Imagine that you really fall in love with networking and decide to get a nice small public subnet routed to you, to play with. You’ll get a brand new webserver to go with it, you’ll assign new public address directly to it, prepare new flashy website, throw out a big party to celebrate, invite many guests, champagne popping all around, … you feel it, it’s really big, right? And then guests try to open the new website by entering the new public address in their mobile browsers… and they will get the old website from old server, because forwarded port to that was done only with in-interface=eth1-wan. Are you prepared to suffer such embarrassment?
Ok, it will probably not happen like this. It’s more philosophical question, but do you really want dstnat rule for any incoming traffic regardless of destination address, or do you want it for the public address on router? Or on more practical side, dstnat with in-interface=eth1-wan is not compatible with hairpin NAT. As for dst-address-type=local, it’s not really anything to be excited about, only a workaround, when you don’t want in-interface, but you don’t have static address.
If ports are not used by services running on router and are not forwarded explicitly, then router won’t know what to do with connections targeting those ports. So it will most probably just ignore those connections thus making those ports seem blocked.
Re. permitting ports: is you have restrictive firewall with drop all rule at the end of chain=forward, you’ll have to permit NATed ports before that final rule somehow. The most general way is to have rule
which will implicitly allow access to all forwarded ports. You cna, however, construct a series of more restrictive rules, targeting fi]chain=forward[/i], if you like.
Lets start at the first post… If there is after effects its the food stuffing of Easter. We will be eating turkey soup for the next 3 days too.
To be frank, I don’t have a clue of what the poster is doing.
With that configuration. It doesnt compute at all.
I cant even begin to attempt to explain it.
If I am port forwarding for remote desktop
Its simple and works, so i dont understand the overly complex setup and weird masquerade rule or question about unassigned ports…
if they are not in the config, they wont work!
The “weird masquerade rule” is hairpin NAT, which you already know, but for some unknown reason insist that it’s complicated, even though it’s exact opposite of complicated, it can hardly be any simpler/easier.
And “unassigned ports” I don’t get either. OP seems to think that “standard” ports used by well-known services can be forwarded, but that others don’t work. It’s not true, you can forward any port you like. Of course the success depends on where you forward it to, target machine must have something listening on that port, otherwise it won’t do anything useful.
