Remote management on WAN

Hello,
I just upgraded ROS from 6.49.5 to 7.2 and remote management to WAN doesnt work anymore. Did anything change? I have enabled port 8291 in Firewall and it is locked down to 3 networks I am accesing it from.

Maybe best to post your config so we can have a look.
/export file= anynameyouwish
Review for sensitive info and post between [__code] quotes.

Here it is:

# apr/12/2022 13:44:16 by RouterOS 7.2
# software id = 4VLT-G4K3
#
# model = RBD53iG-5HacD2HnD
# serial number = F34E0F6BD6E0
/interface bridge
add admin-mac=DC:2C:6E:13:6C:13 auto-mac=no name=bridge
/interface wireless
set [ find default-name=wlan1 ] band=2ghz-b/g/n channel-width=20/40mhz-XX \
    disabled=no distance=indoors frequency=auto installation=indoor mode=\
    ap-bridge ssid=ap-snkfd wireless-protocol=802.11
set [ find default-name=wlan2 ] band=5ghz-a/n/ac channel-width=\
    20/40/80mhz-XXXX disabled=no distance=indoors frequency=auto \
    installation=indoor mode=ap-bridge ssid=ap-snkfd wireless-protocol=\
    802.11
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface lte apn
set [ find default=yes ] ip-type=ipv4 use-network-apn=no
/interface wireless security-profiles
set [ find default=yes ] authentication-types=wpa-psk,wpa2-psk eap-methods="" \
    mode=dynamic-keys supplicant-identity=MikroTik
/ip pool
add name=dhcp ranges=192.168.88.10-192.168.88.254
/ip dhcp-server
add address-pool=dhcp interface=bridge name=defconf
/interface bridge port
add bridge=bridge comment=defconf ingress-filtering=no interface=ether2
add bridge=bridge comment=defconf ingress-filtering=no interface=ether3
add bridge=bridge comment=defconf ingress-filtering=no interface=ether4
add bridge=bridge comment=defconf ingress-filtering=no interface=ether5
add bridge=bridge comment=defconf ingress-filtering=no interface=wlan1
add bridge=bridge comment=defconf ingress-filtering=no interface=wlan2
/ip neighbor discovery-settings
set discover-interface-list=LAN
/ipv6 settings
set max-neighbor-entries=8192
/interface list member
add interface=bridge list=LAN
add interface=ether1 list=WAN
/interface ovpn-server server
set auth=sha1,md5
/ip address
add address=192.168.88.1/24 interface=bridge network=192.168.88.0
/ip dhcp-client
add comment=defconf interface=ether1
/ip dhcp-server network
add address=192.168.88.0/24 gateway=192.168.88.1
/ip dns
set allow-remote-requests=yes
/ip dns static
add address=192.168.88.1 comment=defconf name=router.lan
/ip firewall filter
add action=accept chain=input comment="mikrotik remote management" dst-port=\
    8291 protocol=tcp
add action=accept chain=input comment=\
    "defconf: accept established,related,untracked" connection-state=\
    established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
    invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment=\
    "defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=drop chain=input comment="defconf: drop all not coming from LAN" \
    in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" \
    ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" \
    ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \
    connection-state=established,related hw-offload=yes
add action=accept chain=forward comment=\
    "defconf: accept established,related, untracked" connection-state=\
    established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" \
    connection-state=invalid
add action=drop chain=forward comment=\
    "defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
    connection-state=new in-interface-list=WAN
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" \
    ipsec-policy=out,none out-interface-list=WAN
add action=dst-nat chain=dstnat comment="snkfd-srv ssh" in-interface=\
    ether1 protocol=tcp to-addresses=192.168.88.234 to-ports=22
/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set ssh disabled=yes
set api disabled=yes
set winbox address=192.168.88.0/24,10.78.146.0/23,10.78.128.0/23,10.77.8.0/23
set api-ssl disabled=yes
/ipv6 address
add address=::1 from-pool=pf interface=bridge
/ipv6 dhcp-client
add add-default-route=yes interface=ether1 pool-name=pf request=\
    address,prefix
/ipv6 nd
set [ find default=yes ] ra-interval=20s-1m
add interface=bridge ra-interval=20s-1m
/system clock
set time-zone-name=Europe/Prague
/system leds
set 0 interface=wlan1 leds=led1,led2,led3,led4,led5 type=\
    wireless-signal-strength
set 1 leds=poe-led type=poe-out
/system package update
set channel=testing
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN

According to this rule there is no restriction on IP address, so it should be open for everyone.
You might want to activate logging to be able to do some debugging.

Are you testing from another location?

/ip firewall filter
add action=accept chain=input comment="mikrotik remote management" dst-port=\
    8291 protocol=tcp

Not really “no restriction”:

/ip service
set winbox address=192.168.88.0/24,10.78.146.0/23,10.78.128.0/23,10.77.8.0/23

only those private addresses.

All of the IPs on your “set winbox address” line are RFC 1918 private subnets.

@tangent, I hope @snakefood understand…

Yeah, of course. Network behind NAT, internal network and two networks where VPN is (both VPN IPs are fixed, so having enabled two more networks might be too much, but whatever..) I am getting inside exclusively just through VPN hosted in private network.

Anyways, I will enable some more logging and will be back afterwards.

And only now you say “I use VPN”???

Huh? Pardon me, I am confused. I think it has nothing to do with that. And it doesnt really matter if I use or dont use VPN.

Not if you’re making use of that firewall rule on line 55, which allows direct connection to port 8291 from the WAN side. To make that usable, you’d have to put your WAN IP into the address list I pointed out.

But don’t do that. Your IPsec VPN is likely much stronger than WinBox’s encryption.


it doesnt really matter if I use or dont use VPN.

It does if your VPN IP address is in the winbox address list but your public IP is not.

Not if you’re making use of that firewall rule on line 55, which allows direct connection to port 8291 from the WAN side. To make that usable, you’d have to put your WAN IP into the address list I pointed out.

Yes, as I need to access Mikrotik from virtual machine which is obviously out of my home network (ESXi hosted elsewhere in the network), but it is located in same private network. So I thought, I will just open 8291 in firewall and will restrict the service itself by setting networks explicitly. Mikrotik could be reached from Internet as it has public IPv4 tight to its private network IP, but I would like better to see it closed.


It does if your VPN IP address is in the winbox address list but your public IP is not.

I am not quite sure what you mean by that, because Mikrotik IP from my private network has assigned public IP to it. But it is not set up anywhere.

However this does not solve my problem at all, I need to go back to the logs and see why remote management doesnt work as it responds with ERROR: Router has refused connection.

I am testing from 2 different locations with "debug" enabled. Nothing shows up in the log. Winbox just says ERROR: Router refused connection.

The llama has arrived…

(1) Firstly, dont be a dufus and tell the whole world your winbox port. Change it from default and post XXXX on any config you present here.
(2) The others are right its poorly formulated (at least on the input chain itself wide open to LAN and WAN).
Ask yourself the simple question who needs access to the router for config purpose - Only the admin…

add chain=input action=accept in-interface-list=Trusted dst-port=winboxport protocol=tcp src-address-list=authorized

You will need to allow LAN users access to DNS services.
and then complete the config by dropping all other traffic as the last rule in the input chain

Finally - at least stick the rule after the default rules of established, drop invalid, accept icmp ---------then your rules…

(3) I see that you also have some what I can only assume is some VPN addresses allowed to winbox as well, /
Where is the interface for the VPN I dont see anything in the config to indicate you have a VPN here, no input chain rules etc…

(4) DST NAT RULE IS MISSING dst-port and protocol

Dont think, instead - PROVIDE missing information. There is something not clear on your VPN and how you access this router externally that is not well understood.
A diagram may help.

If you knew all the answers you wouldnt be asking for help, so help us help you by not making assumptions of what is or isnt relevant!!

My suggestion for this rule is as follows:
add chain=input action=accept in-interface-list=!WAN dst-port=8291 protocol=tcp src-address-list=Trusted

Why, to accept Winbox from everywhere except WAN for VPN specifically … for the admin this IMO scales far better and prevents WAN exploits.
This way the port for Winbox can remain the default.

I absolutely agree with you, however from user perspective, it worked on 6.49.5, it suddenly doesn’t on 7.2. No changes were made. VPN is not served by Mikrotik, so the impact on it should be close to zero. This is the reason I ommited it. I can also draw a diagram for making it crystal clear.

For now I am going to absorb @anav hints and make sure its everything set up correctly. I admit I am llama as I have hAP for a week or so … hooray lets go back and learn from mistakes. I will report back with the progress.

Awesome, looking forward to it…

Well its better than it was before, but also I prefer clear direct targettng and thus do not like any use of ! symbol unless absolutely necessary.
( you may use it properly but like RAW firewall rules, in the hands of a beginner or learner, it can be dangerous!! )
It is also redundant anyway because my input chain rule LAST RULE is drop all anyway, so I dont need no stinking ! crap :-0

You do have a point though!!!
Where it scales better for example is when you have multiple inject interfaces!
example 1 - the admin has IPs on a bunch of LAN subnets not just the trusted subnet and wants to be able to config the router from any location within the network
example 2 - the admin is coming in over a different interface (IE VPN)
Alternatives…

  • one can add the wireguard interface to the trusted interface list as one option
  • one can add a separate rule for VPN besides the above rule.

On further inspections. DISAGREE WITH WINBOX Port staying as default, CHANGE IT should be the automatic admin action!!!

Lets discuss in-interface-list=!WAN,
The problem I have with this one is more a question. What does that rule actually mean?
Does it mean allow all other interfaces list entries LAN, TRUSTED, MANAGMENT etc… if so ITS NO GAIN IMHO, because I can
always identify the list members I want to be trusted…

Futhermore it FAILS to address an interface or entity that is NOT described under and interface list.
For example WIREGUARD can be an interface member but other VPNs cannot so your rule doesnt allow them becuase they are not on any interface list as a member!!!

Thinking this is better
" in-interface=!ether1" (or pppoe-out or ISP vlan etc…).

In this way what we are saying is that any interface other than the WAN interface is okay…
Personally I would probably make two rules before getting to this point.