Enable Winbox on internet but with another tcp port (destnat) keeping 8291 for LAN

Hi, I want to preserve the router from attacks, I don’t want to leaved open the 8291, but use something like 48743, at the same time I want to leave the 8291 for the LAN connection, so it’s not just to change the service port and allow it on firewall.. it’s a destnat to another port, and this works somehow because I see the packet coming into the rule (statistics), and I can have it work if I disable “drop all not coming from LAN”..
So how to have it working? Let’s analyze where it stops:

the firewall rule allows packets coming from ether1, with any source IP to my public IP if it’s TCP with destination port 48743
the destnat is natting packets with destination adress my public IP, with destination TCP 48743 and natted to 192.168.88.1:8291. This works when “drop all not coming from LAN” is disabled,
What I’m missing?
Thanks

If you really «want to preserve the router from attacks» do not open any port at all…
Use a VPN (not PPTP) to remotely authenticate your device and after that use safely winbox.

If you leave the port open, sooner or later they find it, it’s not that: “Oh 8291 is closed, I’m leaving”,
they try them all…

@rextended is right…
But in case is needed, you could use Port knocking.
Check here https://wiki.mikrotik.com/wiki/Port_Knocking

Knocking is a lovely way, thanks for reporting it, I really hope Mikrotik will implement it to Winbox, where I can specify the 3 ports I’ve chosen fro knocking, and it does automatically. If not, I’m not going to use it since I don’t have time to knock from any host I’m using to maintenance, I prefer to risk. Since I’m using Mikrotik (about 10 years), no one of 100+ devices has been hacked, moving the tcp port far.

I hope we can keep on topic and solve my problem, how can I do that? Thank you for helping on solution

Sorry, the problem is that we are all selfish,
we don’t want other botnet members, (which then attack our networks), without the knowledge of the device administrator (I hope…)
We are so cynical that we often refuse to favor crackers with mikrotik routers, suggesting how to leave the doors open to the world.
It is our nature…
¯_(ツ)_/¯

IN this case help your costumers realizing a safe connection Winbox! Use knoking or what you’d love to use, but don’t leave us whouthout solutions just because you don’t want to risk.

Look, I don’t work for MikroTik, I’m just one of the forum moderators, who also don’t work for MikroTik…
Only those who have the name written in red, or yes green, but with the writing MikroTik Staff, work there.

It’s not great, but it’s still slightly better to use different port than default one, which could be the result otherwise. So with the usual warnings (kids, don’t try this at home, etc), you can recognize connections redirected from another port by connection-nat-state=dstnat, so you can add filter rule using that.

Thanks for answer, I’ve used a completely different port as described, for example 48743.
dstnat is not enogh, if the Winbox 8921 will be not changed to 48743, as I wrote.
There is need of something else, to avoid “drop all not coming from LAN” killing the connection, as I wrote.

I’ve solved the problem with an internal other Mikrotik, I destnat the 48743 to him, he will destnat it back to .88.1:8291 and the following roule will sourcenat that packets only (with destination tcp 8291) changing the source internet address with the address of internal Mikrotik. Wow, the “drop all not coming from LAN” rule is finally avoided

You are not our customer. We don’t work for MikroTik. We are just users like you.

You don’t seem to understand the risk involved. Watch this Getting Started and Having Fun With The Shodan Search Engine
and pay particular attention here.

As it is so dangerous and hurry, I’m looking to Mikrotik implement soon the knocking feature to Winbox, enforce security. I’ll certainly take advance of it

Oh… nice search engine…
AFP:
Server Name: MacBook Pro de Christophe
UTF-8 Server Name: MacBook Pro de Christophe
Machine Type: MacBookPro9,1
Directory Names:
afpserver/7-4--.broadband.c***.ru@BROADBAND.C****.RU
AFP Versions:
AFP3.1
AFP3.2
AFP3.3
AFP3.4
AFPX03
UAMs:
Cli…
another
MikroTik Winbox:
index:
advtool.dll: 6.47.7
dhcp.dll: 6.47.7
hotspot.dll: 6.47.7
mpls.dll: 6.47.7
ppp.dll: 6.47.7
roteros.dll: 6.47.7
roting4.dll: 6.47.7
secure.dll: 6.47.7
system.dll: 6.47.7
wlan6.dll: 6.47.7
list:
advtool.jg: 6.47.7
dhcp.jg: 6…

/ip firewall nat
add chain=dstnat <destination> protocol=tcp dst-port=48743 action=redirect to-ports=8291
/ip firewall filter
add chain=input protocol=tcp dst-port=8291 connection-nat-state=dstnat action=accept

Where should be either dst-address= (if it’s static) or in-interface= should probably be good enough too.

there is plenty off apps for desktop and mobile to do the port knock easily

Port knocking is a kludge and dull when there are secure VPN methods accessible.
As a matter of fact Wireguard is dirt simple to setup.
I hope MT staff never waste there very limited resources on automating port knocking as there is so much other functionality that needs adding or addressing…

Only a moron would leave winbox open to the internet after being told its unsafe.
If one insists on using port knocking thats at least better than not doing so, but a ton of work compared to
a simple wireguard connection.

some ideas here but too complicated for me… :slight_smile:
http://forum.mikrotik.com/t/portknocking-by-script/102274/11

WORKS!
Thank you man for kindly answer my question and help me learning as well! I was really far from the solution, I still have to learn more about how Mikrotik manage packets. Great lesson for me! :sunglasses:

PS: to avoid any possible misbehavior for inside 8291 connections I added to the filter the destination address as well and the input WAN port ether1

Input rule is ok as it is. It can’t affect direct connections to port 8291 from anywhere, because those won’t match connection-nat-state=dstnat, only dstnatted ones will. If you don’t have any other dstnat rule that redirects traffic to local port 8291, the only one that can do it is this that you added now. It can affect internal connections if used is only dst-address= and not in-interface=. In that case you’ll be able to connect to :48743 from anywhere. Which should be probably fine, because if you allow the whole world to connect, then allowing it also from your internal networks shouldn’t be worse than that.