Attempting to isolate Winbox access [SOLVED]

I have a map lite which I have reconfigured successfully as CPE, i.e. wireless DHCP client on WAN with Ethernet DHCP server on LAN. I have added a virtual wireless as a DHCP server using a different address pool from LAN. I have prevented Winbox access to the mapL by IP, allowing it on mgt-vwan, and this works. My remaining task is to allow Winbox access via mgt-vwan only, not via LAN. So far, this has failed.

My approach was to create a new list MGT and assign mgt-vwan to it instead of to LAN. I then changed these two settings:

/tool mac-server set allowed-interface-list=Mgt
/tool mac-server mac-wingox set allowed-interface-list=Mgt

with the result that I could no longer access the mapL from mgt-vwan at all, although I could still do so on the eth1 (LAN) Mac address.

What am I doing wrong please, or what must I do right?

Here is the config as it did not work, with some redundancy owing to fiddling, and a couple of oddities ROS chucked in with no apparent action by me:

# 2025-02-27 15:33:34 by RouterOS 7.18
# software id = H0CT-RZZJ
#
# model = RBmAPL-2nD
# serial number = <na0>
/interface bridge
add comment=default name=bridge1
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
add comment=Mgt-list name=Mgt
/interface wireless security-profiles
set [ find default=yes ] comment="No function\?" supplicant-identity=MikroTik
add authentication-types=wpa2-psk comment=CPE mode=dynamic-keys name=CPEsec \
    supplicant-identity=""
add authentication-types=wpa2-psk comment=Management mode=dynamic-keys name=\
    Mgt-sec supplicant-identity=""
/interface wireless
set [ find default-name=wlan1 ] band=2ghz-onlyn channel-width=20/40mhz-XX \
    comment=CPE country=australia disabled=no distance=indoors frequency=auto \
    installation=indoor security-profile=CPEsec ssid=<na1> \
    wireless-protocol=802.11
/interface wireless manual-tx-power-table
set wlan1 comment=CPE
/interface wireless nstreme
set wlan1 comment=CPE
/interface wireless
add comment="Virtual WiFi Mgt" disabled=no keepalive-frames=disabled \
    mac-address=7A:9A:18:31:5D:C2 master-interface=wlan1 multicast-buffering=\
    disabled name=mgt-vwan security-profile=Mgt-sec ssid=<na2> \
    wds-cost-range=0 wds-default-cost=1 wps-mode=disabled
/interface wireless manual-tx-power-table
set mgt-vwan comment="Virtual WiFi Mgt"
/interface wireless nstreme
set *6 comment="Virtual WiFi Mgt"
/ip pool
add comment=NVR name=LANpool ranges=10.43.45.2-10.43.45.9
add comment=Mgt name=Mgtpool ranges=10.17.26.2-10.17.26.25
/ip dhcp-server
add address-pool=LANpool comment="NVR DHCP" interface=ether1 name=LANserver
add address-pool=Mgtpool comment="Mgt DHCP" interface=mgt-vwan name=Mgtserver \
    server-address=10.17.26.1
/disk settings
set auto-media-interface=bridge1 auto-media-sharing=yes auto-smb-sharing=yes
/interface bridge port
add bridge=bridge1 comment=defconf disabled=yes interface=pwr-line1
/ip neighbor discovery-settings
set discover-interface-list=LAN
/ipv6 settings
set disable-ipv6=yes forward=no
/interface list member
add comment=defconf interface=wlan1 list=WAN
add comment=CPE interface=ether1 list=LAN
add comment="mgt is mixed" interface=mgt-vwan list=Mgt
/interface ovpn-server server
add mac-address=FE:D5:DD:F9:59:EE name=ovpn-server1
/ip address
add address=192.168.88.1/24 comment=defconf interface=bridge1 network=\
    192.168.88.0
add address=10.43.45.1/24 comment=CPE interface=ether1 network=10.43.45.0
add address=10.17.26.1/24 comment="Mgt port" interface=mgt-vwan network=\
    10.17.26.0
/ip dhcp-client
add comment=CPE interface=wlan1
/ip dhcp-server
add address-pool=*1 disabled=yes interface=bridge1 name=defconf
/ip dhcp-server network
add address=10.17.26.0/24 comment=Mgt dns-server=10.17.26.1 gateway=\
    10.17.26.1 netmask=24
add address=10.43.45.0/24 comment=CPE dns-server=10.43.45.1 gateway=\
    10.43.45.1 netmask=24
add address=192.168.88.0/24 comment=defconf dns-server=192.168.88.1 gateway=\
    192.168.88.1
/ip dns
set allow-remote-requests=yes
/ip dns static
add address=10.43.45.1 comment=defconf name=router.lan type=A
add address=10.17.26.1 comment=MgtDNS name=router.vwan type=A
/ip firewall address-list
add address=10.17.25.0/24 comment="NVR list" list=NVR-set
/ip firewall filter
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 log-prefix=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=accept chain=input comment="Accept MGT list" in-interface-list=Mgt
add action=accept chain=input comment="defconf: Accept LAN list" \
    in-interface-list=LAN
add action=drop chain=input comment="Drop all else" log-prefix=Input
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 log-prefix=FwdInvalid
add action=accept chain=forward comment="NVR NTP" dst-address=0.0.0.0 \
    dst-port=123 protocol=udp src-address-list=NVR-set
add action=accept chain=forward comment="NVR DNS" dst-port=53 protocol=udp \
    src-address-list=NVR-set
add action=drop chain=forward comment="Else block NVR" disabled=yes \
    src-address-list=NVR-set
add action=accept chain=forward comment="Allow internet for MGT" \
    in-interface-list=Mgt out-interface-list=WAN
add action=accept chain=forward comment="Allow internet for LAN" \
    in-interface-list=LAN out-interface-list=WAN
add action=accept chain=forward comment="Alow port forwarding" \
    connection-nat-state=dstnat
add action=drop chain=forward comment="defconf: drop all else" \
    connection-nat-state="" connection-state="" in-interface-list=all
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" \
    ipsec-policy=out,none out-interface-list=WAN
add action=accept chain=dstnat dst-address=172.17.10.2 dst-port=37777 \
    protocol=tcp
/ip service
set telnet disabled=yes
set ftp disabled=yes
set winbox address=10.17.26.0/27
/system clock
set time-zone-name=Australia/Sydney
/system note
set show-at-login=no
/tool mac-server
set allowed-interface-list=Mgt
/tool mac-server mac-winbox
set allowed-interface-list=Mgt

You may notice that rules are set up so a LAN device can ask the time or DNS resolution but otherwise cannot (should not be able to) reach anything. This is intended. A single port is opened inwards by dst-nat.

/ip neighbor discovery-settings
set discover-interface-list=Mgt

/tool mac-server
set allowed-interface-list=none
/tool mac-server mac-winbox
set allowed-interface-list=Mgt

++++++++++++++++++++++++++++

Dont understand the purpose of this rule
add action=accept chain=dstnat dst-address=172.17.10.2 dst-port=37777
protocol=tcp



The winbox address should match the address…
/ip address
add address=10.17.26.1/24 comment=“Mgt port” interface=mgt-vwan network=10.17.26.0
/ip service
set winbox address=10.17.26.0/27

Thank you for the comments, anav. After I posted I realised neighbors would probably be involved but waited for comments because there might be more to it. I will test in expectation of marking this as solved.

The dstnat rule is insufficient / incomplete. I forgot to go back to it after being distracted by Winbox. I intend to pass port 37777 from the WAN side to 10.43.45.3 which will be statically allocated to the NVR.

Lately I see dozens and dozens of customers with a hacked DVR / NVR because they insist on leaving a port open to reach it from outside,
instead of using the cloud or a VPN first…
(All used as an attack vector for RDP protocols)

It will be yet another NVR in the hands of hackers.



add action=accept chain=forward comment=“NVR NTP” dst-address=0.0.0.0 dst-port=123 protocol=udp src-address-list=NVR-set

dst-address must not exist or not work as expected (permit everywhere the NTP)

add action=drop chain=forward comment=“defconf: drop all else” connection-nat-state=“” connection-state=“” in-interface-list=all

connection-nat-state and connection-state must not be present or not work as expected

I am sure you are offering great advice here rextended but I dont understand what you are saying at all such that

I dont know if you are suggesting
a. this is the solution one should implement
b. this is what you should avoid

Please speak Italien, otherwise its greek to me.

Easy: Avoid to open ports to DVR/NVR

Are you saying
a. dont port forward to NVR devices in general
WHY… they only have username and password and no encryption.

Wouldnt that be the same advice for any LAN server exposed to the public?

Hence why I dream of having zerotrust cloudflare as an options package…

The software used on DVRs/NVRs is leaky everywhere, especially in the less expensive ones…
Customers install them and leave them on for months without ever checking for updates or brute force usernames and passwords.

Then once hackers have hacked them, they install their own firmware on top and do whatever they want with them.

Of course, anything goes with an open port to the internet for months, but lately DVRs/NVRs and related clouds are very… hacked…

Thanks, concur, I would only provide Storage access etc to family via VPN, nothing open port to server…

I will come back to the rules mentioned by rextended after some study later. Time zones.

For reassurance, we are discussing an internal router designed to further limit access to and fro.

  • There is zero access from the NVR to the internet, DNS and NTP requests being captured and answered by the upstream router.
  • There is zero access to the NVR via that port other than from my secure internal network and from VPN on the edge firewall.
  • Even that VPN has access only to mail and the NVR, not to my secure internal network (it has its own firewall) or the NAS within it.

The mAP lite simply replaces an unnecessarily larger and more power-hungry (=hotter) OPNsense box and its cabling, hence some caution on my part in translating from what I understand there to Mikrotik-speak. In general terms I have been using this security design for years.