How is default config allowing Winbox access?

RouterOS General
1

I don’t understand what I’m missing. It seems the behavior has changed along the way with later Router OS versions but I’m not sure.
I though I used to be able to separate an interface from the default bridge, assign an IP then access it with winbox when connecting
to that port. This is no longer the case. I now have to add a new input rule to allow new connections from this interface or Ip, etc.

What in the default config is allowing winbox access via the default bridge?


Here are the default input rules which allow access via winbox, but if I remove eth5 from the bridge and assign an ip, I can’t reach the routerboard.

/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
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
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 services for WinBox is not restricted with “from”. What else is there in the config that is allowing access to port 8291 from the bridge or default 192.168.88.0/24?

2 
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN

That “!LAN” means “not member of LAN”. At the same time “LAN” is not something magical, it’s interface list (in /interface list) which has to be appropriately maintained.

3

Without seeing the complete config one would be guessing although MKX is 99.999 probably on the money.

4

When you remove the interface from bridge (LAN group),
for be used as another LAN access,
you may also add ether on interface group LAN
or is correctly dropped al traffic because is not WAN and is not LAN.

5

I’m 99% sure that I added the interface to the LAN list when I removed it from the bridge, as that’s what I’ve always had to do.

I’ll need to start again with a default router and document the steps, but I think having a unique ip/subnet overrides the interface list??? Meaning if I assign 192.168.2.1/24
to ether5 and add it to the interface-list=LAN it still is blocked without additional subnet to subnet or specific input rule. I guess nobody else has seen this behavior or noticed
the default firewall rules have changed along the way.

/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN
add interface=ether5 list=LAN

Perhaps my age is killing my memory. It’s possible in the past I assigned an ip within the 192.168.88.0/24 range to the independent interface.
It still leaves the question, “should I need to add the rule if the independent interface is added to the LAN list but has a different subnet”?

6

please post the latest config, talk is cheap the config is where the rubber meets the road!!
/export hide-sensitive file=anynameyouwish

7

I didn’t post my config because I’ve already edited to make it work.

Here’s the full monty:

# sep/10/2021 15:10:56 by RouterOS 6.48.4
# software id = WFID-UWGP
#
# model = RB750Gr3
# serial number = xxxxxxxxxxxxxx
/interface bridge
add name=brLoopback
add admin-mac=08:55:31:DD:3B:3B auto-mac=no comment=defconf name=bridge
/caps-man configuration
add country="united states3" datapath.bridge=bridge name=cfg1 \
    security.authentication-types=wpa2-psk ssid=myWiFiNotYours
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip ipsec policy group
add name=grp-roadWarrior
/ip ipsec profile
add dh-group=modp2048,modp1536,modp1024 enc-algorithm=aes-256,aes-192,aes-128 \
    hash-algorithm=sha256 name=prof-roadWarrior
/ip ipsec peer
add exchange-mode=ike2 local-address=1.2.3.4 name=roadWarrior passive=\
    yes profile=prof-roadWarrior
/ip ipsec proposal
add auth-algorithms=sha512,sha256,sha1 enc-algorithms="aes-256-cbc,aes-256-ctr\
    ,aes-256-gcm,aes-192-ctr,aes-192-gcm,aes-128-cbc,aes-128-ctr,aes-128-gcm" \
    lifetime=8h name=Prop-roadWarrior pfs-group=none
/ip pool
add name=default-dhcp ranges=192.168.85.50-192.168.85.200
add name=vpn ranges=10.85.0.100-10.85.0.116
add name=oldIP ranges=192.168.1.60-192.168.1.199
/ip dhcp-server
add address-pool=oldIP disabled=no interface=bridge lease-time=1d14h10m name=\
    defconf
/ip ipsec mode-config
add address-pool=vpn address-prefix-length=32 name=modeConfVPN split-include=\
    192.168.85.0/24 static-dns=192.168.85.1 system-dns=no
add address-pool=vpn address-prefix-length=32 name=modeGateway split-include=\
    0.0.0.0/0 static-dns=192.168.85.1 system-dns=no
/caps-man manager
set enabled=yes
/caps-man manager interface
set [ find default=yes ] forbid=yes
add disabled=no interface=bridge
/caps-man provisioning
add action=create-dynamic-enabled master-configuration=cfg1
/interface bridge port
add bridge=bridge comment=defconf interface=ether2
add bridge=bridge comment=defconf interface=ether3
add bridge=bridge comment=defconf interface=ether4
add bridge=bridge comment=defconf disabled=yes interface=ether5
/ip neighbor discovery-settings
set discover-interface-list=LAN
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN
add interface=ether5 list=LAN
/ip address
add address=192.168.88.1/24 comment=defconf interface=bridge network=\
    192.168.88.0
add address=192.168.201.1/24 interface=ether5 network=192.168.201.0
add address=192.168.85.1/24 interface=bridge network=192.168.85.0
add address=192.168.1.1/24 interface=bridge network=192.168.1.0
add address=1.2.3.4/24 interface=ether1 network=71.183.87.0
add address=10.85.0.254/24 interface=brLoopback network=10.85.0.0
/ip dhcp-server network
add address=192.168.1.0/24 dns-server=192.168.1.1 gateway=192.168.1.1
add address=192.168.85.0/24 comment=defconf dns-server=192.168.85.1 gateway=\
    192.168.85.1
/ip dns
set allow-remote-requests=yes servers=208.67.220.220,8.8.8.8
/ip dns static
add address=192.168.88.1 comment=defconf name=router.lan
add address=192.168.1.201 name=anotherDomain.info
add address=192.168.1.201 name=poweredge
/ip firewall address-list
add address=dnsDomain.hopto.org comment="mgmt office" list=trustedPUB
add address=192.168.1.201 list=anotherDomainPrivate
add address=8.17.32.12 list=DigiumCloudIP
add address=192.168.1.40 list=pbxServer
add address=10.85.0.0/24 comment="road warrior subnet" list=IPsecLANs
add address=192.168.1.0/24 list=oldLAN
add address=192.168.85.0/24 list=newLAN
/ip firewall filter
add action=accept chain=input comment="allow ipsec port 500" dst-port=\
    500,4500 in-interface=ether1 protocol=udp
add action=accept chain=input comment=\
    "Allow access to the router from mgmt" in-interface-list=WAN \
    src-address-list=trustedPUB
add action=accept chain=input comment=\
    "Allow access to the router from IPsec clients" src-address-list=\
    IPsecLANs
add action=accept chain=input comment=\
    "Allow access to the router from port 5" connection-state=new \
    in-interface-list=LAN
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="allow traffic newLAN to oldLAN" \
    dst-address-list=oldLAN src-address-list=newLAN
add action=accept chain=forward comment="allow traffic oldLAN to newLAN" \
    dst-address-list=newLAN src-address-list=oldLAN
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
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=dst-nat chain=dstnat comment="allow RTP to PBX from SIP provider" \
    dst-port=10000-20000 in-interface=ether1 protocol=udp to-addresses=\
    192.168.1.40
add action=src-nat chain=srcnat comment=\
    "srcNAT IKE2: 10.85.0.0/24 WAN traffic" ipsec-policy=out,none \
    out-interface=ether1 src-address=10.85.0.0/24 to-addresses=1.2.3.4
add action=dst-nat chain=dstnat comment=\
    "port forward http & https to web server" dst-address=1.2.3.4 \
    dst-port=80,443 in-interface=ether1 protocol=tcp to-addresses=\
    192.168.1.201
add action=masquerade chain=srcnat comment="defconf: masquerade" \
    ipsec-policy=out,none out-interface-list=WAN
/ip ipsec identity
add auth-method=digital-signature certificate=vpn.myDomain.com \
    generate-policy=port-strict match-by=certificate mode-config=modeGateway \
    peer=roadWarrior policy-template-group=grp-roadWarrior \
    remote-certificate=eric@vpn.myDomain.com remote-id=\
    user-fqdn:eric@vpn.myDomain.com
add auth-method=digital-signature certificate=vpn.myDomain.com \
    generate-policy=port-strict match-by=certificate mode-config=modeConfVPN \
    peer=roadWarrior policy-template-group=grp-roadWarrior \
    remote-certificate=jill@vpn.myDomain.com remote-id=\
    user-fqdn:jill@vpn.myDomain.com
add auth-method=digital-signature certificate=vpn.myDomain.com \
    generate-policy=port-strict match-by=certificate mode-config=modeConfVPN \
    peer=roadWarrior policy-template-group=grp-roadWarrior \
    remote-certificate=mike@vpn.myDomain.com remote-id=\
    user-fqdn:mike@vpn.myDomain.com
add auth-method=digital-signature certificate=vpn.myDomain.com \
    generate-policy=port-strict match-by=certificate mode-config=modeConfVPN \
    peer=roadWarrior policy-template-group=grp-roadWarrior \
    remote-certificate=julie@vpn.myDomain.com remote-id=\
    user-fqdn:julie@vpn.myDomain.com
add auth-method=digital-signature certificate=vpn.myDomain.com \
    generate-policy=port-strict match-by=certificate mode-config=modeConfVPN \
    peer=roadWarrior policy-template-group=grp-roadWarrior \
    remote-certificate=mando@vpn.myDomain.com remote-id=\
    user-fqdn:mando@vpn.myDomain.com
add auth-method=digital-signature certificate=vpn.myDomain.com \
    generate-policy=port-strict match-by=certificate mode-config=modeConfVPN \
    peer=roadWarrior policy-template-group=grp-roadWarrior \
    remote-certificate=rene@vpn.myDomain.com remote-id=\
    user-fqdn:rene@vpn.myDomain.com
add auth-method=digital-signature certificate=vpn.myDomain.com \
    generate-policy=port-strict match-by=certificate mode-config=modeConfVPN \
    peer=roadWarrior policy-template-group=grp-roadWarrior \
    remote-certificate=dave@vpn.myDomain.com remote-id=\
    user-fqdn:dave@vpn.myDomain.com
/ip ipsec policy
add dst-address=10.85.0.0/24 group=grp-roadWarrior proposal=Prop-roadWarrior \
    src-address=0.0.0.0/0 template=yes
/ip route
add distance=1 gateway=1.2.3.1
/ip service
set www port=8080
/system clock
set time-zone-name=America/New_York
/system identity
set name=cpFirewall
/system logging
add topics=dhcp
/system ntp client
set enabled=yes secondary-ntp=17.253.14.125
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN
8

My observations…

(1) There should only be one address for the bridge interface!! You have it THREE PLACES WTF?? . Keep the blue one get rid of the red ones.
/ip address
add address=192.168.88.1/24 comment=defconf interface=bridge network=
192.168.88.0
add address=192.168.201.1/24 interface=ether5 network=192.168.201.0
add address=192.168.85.1/24 interface=bridge network=192.168.85.0
add address=192.168.1.1/24 interface=bridge network=192.168.1.0
add address=1.2.3.4/24 interface=ether1 network=71.183.87.0
add address=10.85.0.254/24 interface=brLoopback network=10.85.0.0

(2) Missing parts for the separate subnet on etheport 5. I see an address but not anything else.
Assuming then that is strictly for emergency access to the router for config purposes.

(3) Your DHCP server is set to an OLD IP range that is no longer valid
/ip dhcp-server
add address-pool=oldIP disabled=no interface=bridge lease-time=1d14h10m name=
defconf
(note: old pool refers to 192.168.1.60-99, whereas the bridge is actually default-dhcp 192.168.85.50-200)

(4) If ethernet 5 is not part of the bridge then it shouldnt be on bridge port settings…OK I see its disabled but the more you keep old stuff around clearly you start stepping in it!!!

(5) Potentially a security nightmare or wrong approach ?? Allowing public IPs direct access to your router is a huge security caution flag.!!
I see in the following rule you allow ipsec clients access to the router, which makes more sense to me. Suggesting you drop this rule asap.
If you want a quick way to access your router try out remotewinbox its not as good as ipsec like you have but its convenient for the homeowner but not good enough for a business IMHO.

add action=accept chain=input comment=
“Allow access to the router from mgmt” in-interface-list=WAN
src-address-list=trustedPUB


(5) THis rule is TOO Broad. Unless your comment is wrong and its meant for all LAN users???
If you allow access for the entire LAN, then anyone on the bridge can also access
From
add action=accept chain=input comment=
“Allow access to the router from port 5” connection-state=new
in-interface-list=LAN
TO
add action=accept chain=input comment=
“Allow access to the router from port 5” connection-state=new
in-interface=ether5

Furthermore the rule was completely useless anyway because in the next rule YOU LET ALL LAN users access the router anyway.
add action=drop chain=input comment=“defconf: drop all not coming from LAN”
in-interface-list=!LAN

What you need to do is
a. allow an admin list of IPs from your LAN subnet in-interface-list=LAN with source-address list (firewall address list=admin access)
admin acces = IPs of admin devices pc desktop, laptop, ipad, smartphone, ether5 IPs statically set in dhcp leases )
b. allow DNS services to all LAN users udp and tcp
c. add a last input chain rule that drops all traffic.

9

@anav,

Thanks for your comprehensive reply.

I’m unable to reproduce the condition on a freshly reset router. I don’t know what went wrong.

I’d love to know why having multiple IP addresses (multiple subnets) on the bridge or any interface is a problem.
Isn’t it the same as “router-on-a-stick” sans the vLANs.

Do you really think allowing a single /32 public IP address access to the router is a grave of an issue? Even if someone were to spoof my public IP, traffic
would not flow both ways to/from the bad actor’s location. Obviously, I’d want to use a secure protocol when accessing it via public IP though.

I only added:

add action=accept chain=input comment=\
"Allow access to the router from port 5" connection-state=new \
in-interface-list=LAN

because I was unable to reach the router from port 5 without it (the reason for this post).
As you stated it’s actually “useless”/redundant, yet it was needed else I couldn’t access the router via WinBox.
I literally started with a bone stock router, removed ether5 from the bridge, added an IP to ether5, added ether5 to the interface-list=LAN, but was unable to reach the router without the above input rule. Perhaps I forgot to change the IP on my laptop or my Mac was acting squirrely! I really don’t know why it didn’t work as I perform these steps often so I don’t get locked out of the router when messing with the IP address on the bridge.

The following rule is a default rule… not mine :wink: I guess it’s mine by inheritance :slight_smile:

add action=drop chain=input comment="[color=#0040FF]defconf[/color]: drop all not coming from LAN" \
in-interface-list=!LAN

I certainly can’t argue this config can use some hardening, but it’s still a work in progress, hence the “allow trusted pub” (again it’s a single IP), and the multiple IP addresses on the bridge. Additionally the need to point DHCP pool at the oldIP range as there were issues after putting the router in place. I wanted to change the office subnet away from 192.168.1.0/24, but I didn’t have admin access to all assets. Issues arose so I had to get DHCP clients back on the old subnet quickly.

Further detail:
As I wanted to get the office off of 192.168.1.0/24 (mostly to eliminate issues with VPN roadwarriors) I added the 192.168.85.0/24 ip, network, and DHCP pool.
I also added 192.168.1.1/24 to the bridge as there were some static IP machines that I just couldn’t change. I treated it like a “router on a stick” so users could access the
servers from the new subnet. VPN users RDP into their workstations so I didn’t really need VPN clients to reach the 192.168.1.0/24 subnet. I figured this was
a good approach as a first step… that should’ve been fully functional. The one stick in the spokes was a Switchvox PBX server that didn’t like the phones on
a separate subnet. Even after adding forwarding rules to/from 192.168.1.0/24 and 192.168.85.0/24 the phones still had undesired symptoms. I didn’t do any
packet captures, but I suspect there must be some MDNS or other broadcast-type traffic that wasn’t flowing. I have next to zero experience with Switchvox.