Bug/Improvement suggestion - Lost connection to Winbox

Router OS v 7.11.2
LTE6 version: R11e-LTE6_V036

Failure to connect to Winbox after disable then enable firewall in Quick Set, can be reproduced by:

  1. Reset LHG to defaults
  2. Connect to Winbox OK
  3. No WAN IP at this stage (0.0.0.0)
  4. Disable Firewall in Quick Set
  5. Connect to Winbox OK
  6. Enable firewall
  7. Restart Winbox
  8. Fail to connect, also no neighbour discovery

I’ve noted the FW rules are not re-created equally between the initial default rules and when the FW button is disabled then re-enabled. Not a FW rule guru by any imagination, but suspect due to the significant differences something is causing the issue.

TBH quite frustrating as a newcomer, but finally tracked it down.

FW rules from default config:

# 2023-11-03 17:04:57 by RouterOS 7.11.2
# software id = 
#
# model = RBLHGR
# serial number = 
/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 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

And these after the FW feature is disabled, then re-enabled from Quick set:

# 2023-11-03 17:10:29 by RouterOS 7.11.2
# software id = 
#
# model = RBLHGR
# serial number = 
/ip firewall filter
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
add action=accept chain=input protocol=icmp
add action=accept chain=input connection-state=established
add action=accept chain=input connection-state=related
add action=drop chain=input in-interface-list=!LAN
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" \
    ipsec-policy=out,none out-interface-list=WAN

Cheers
Lea

Quickset settings were never intended to be used in succession.
Only ONCE after a reset to default config, to have a base config never to be touched again via Quickset (unless starting again from default config).

So I am not sure this is to be considered a bug.
Others may view this differently.

I disagree, if Mikrotik place a tick box in Quick Set (it’s not labelled Quick Start, never to be used again) then it should function as intended, for setting things quickly (even the manual doesn’t indicate once only), and not with random consequences - or at least a warning should be displayed. Also you’ll note from the steps to reproduce, no configuration has occurred and we are at the initial config immediately post reset to defaults. To have a setting that’s available anytime and during initial setup of a device that breaks essential management functions (Winbox and Neighbourhood) is poor design. RouterOS is an amazing beast but a complex one and I suspect many newcomers will be frustrated (as I) and maybe dissuaded from advanced use if the fundamentals are not in place. Time is $$$, so losing many many hours vs paying more for a more ‘point and click’ device is always a decision point in consulting.

Many solutions to this exist, correct the re-write of FW rules to match the original rules set at reset to default when the FW enable check box is selected, or/and at least warn the user that custom settings maybe lost to name 2. I could appreciate custom settings maybe lost but only when I understand what exactly is happening under the hood, ie the check box actually re-creates many rules rather than simply toggling on/off, however nuubs will not. Also, we haven’t even customised the device, this is initial setup.

So whilst not strictly a ‘bug’ the intended consequences are similar, FW rules should be set to those created at reset to default, with a warning indicating custom rules maybe lost.

Solved!

I agree that QuickSet is sort of suggesting more features than it really has, and ought to be disabled after its first use.
It is easy to view it as an “easy control panel” to configure the router without using all those complicated menus, but in reality it isn’t.

The MikroTik products require study for effective use, at least in advanced scenarios. When you are not up to that, indeed buying a more expensive but more beginner-friendly product may be the only way to go.

Agreed. QuickSet should never be used on anything except a brand new device and once touched, never used again.

@Mikrotik

Please: FW rules should be set to those created at reset to default, with a warning indicating custom rules maybe lost.

I think you may have missed one of the arguments, I was at initial config, and preventing fundamental access to the device (especially without warning or by tick box) at anytime is poor design.

Mikrotik staff does not always read the forum.
Best to contact support with your request about quickset.

I still stand by my point to only used quickset ONCE, never again afterwards.
And use SAFE MODE in Winbox, it might have prevented you from locking yourself out (which basically is what happened).

Good idea, I’ve raised a Support issue.

Not splitting hairs…but…it was the first time I used Quick Set.

Rereading your sequence it seems so but you did manually change settings afterwards.
So you did lock yourself out :laughing:

Safe mode helps to prevent that.

For all you QuickSet ‘haters’ out there :smiley: Support confirm this bug has been resolved in v7.12 :sunglasses:

Thank you Support for acknowledging this is incorrect behaviour and resolving in the latest version, here’s their response fyi:

Described behavior occurs, due QuickSet script incorrectly interacting with the interface list !LAN.

Filter rule - add action=drop chain=input in-interface-list=Unable to render embedded object: File (LAN - main matching criteria here is interface list, being LAN - “) not found.”, essentially means, match all, except LAN.

Described sequence, removes ether1, in LHG case, from the interface list, which allows the input-drop rule to restrict access.

Described behavior has already been fixed, please upgrade the RouterOS to the latest 7.12 version.

Well done sir!!