Hello!
I’ve done a dumb thing by accidentally changing configuration without SafeMode enabled on RB2011, leading to loss of winbox connection. MAC server is disabled. The configuration is following:
Management VLAN with DHCP add lease arp, firewall accept input from that VLAN, drop else, arp reply-only, ip-services winbox access from 192.168.238.1/27 (subnet in this VLAN).
Video VLAN arp-enabled with DHCP add lease arp 192.168.188.1/24, Local VLAN arp reply-only DHCP add lease arp 192.168.240.1/24
I have interfaces on my PC for all those VLANs
What I have done is disabling dhcp server on management vlan. The only idea I have now is probably resetting the router, it has a backup (a bit outdated, but still) in its filesystem. But I thought to ask if there is any other way to regain access - probably a way to trick router by changing MAC addresses on interfaces or something like that? Would appreciate any help
I don’t think there’s any other way but reseting the device (and reloading the outdated backup file).
The beauty of tight security is that it’s secure. If one (accidentally) blocks them selves, then this is the ultimate proof that the security settings were working
In your case I don’t think so … because basically you’ll have to use the button to perform reset. But the process should be pretty straight-forward (if you can gain MAC access to the device), simply restore the backup file manually. To make things easier (in case if your winbox work station can’t be connected directly to RB2011): there’s MAC access via telnet and all ROS devices can be MAC telnet clients … so if you have another ROS device in same L2 broadcast domain as your RB2011 (and runs equally dated ROS, there was some change in how overMAC works somewhere around 6.45, but I can’t remember which version exactly, old and new are not compatible), you can use MAC telnet and reload RB2011 from backup via CLI.
I’ve made a reset, now I’ve found an auto-before-reset.backup file in router FS. Is there any way to modify this file to enable the DHCP on interface and restore it afterwards? Since it’s the newest config
Didn’t notice any serial port there, could give it a try if I would. This is probably some kind of budget models of RB2011, which doesn’t have neither usb or sfp ports.
You are right, I should.
Model is RB2011iL-RM, ROS version 6.47
When I open a backup file, I can see some readable scripts aside binary data
Script for building a network table
# https://forummikrotik.ru/viewtopic.php?p=70575#p70575
# tested on ROS 6.46.5
# updated 2020/05/20
# Enumeration of interfaces
foreach interfaceIndex in=([ /interface find; ]) do={
:local interfaceName ([ /interface get $interfaceIndex name; ]);
:local bridgeIndexes ([ /interface bridge find; ]);
:local bridgeIP ("not IP-address");;
:local bridgeName ("not bridge name");
:local bridgeHosts;
# Enumeration of bridges
foreach bridgeIndex in=$bridgeIndexes do={
:set bridgeName ([ /interface bridge get $bridgeIndex name; ]);
:set bridgeHosts ([ /interface bridge host find bridge=$bridgeName; ]);
Can I somehow add a script to this backup, so all dhcp servers become enabled after restoring?
I’ve also found a Python script that can parse my backup into *.dat and *.idx files. It says backup is plaintext format and no password on it. So maybe there’s a tool to read this?
Your best bet is to create what I call an emergency or just plain regular access to the router OFF THE BRIDGE.
Thus no matter what you do on especially bridge configurations or other configurations you will maintain access…
Yes, that’s what would I do when I recover and maybe a scheduled backup, painful experience is a good teacher.
So as I understand, there’s no way to modify a .backup file? Or maybe I can restore it to a metarouter VM and then export somehow, I believe there should be something?
Restoring a backup to ROS device of different type is very likely to bring plenty of problems. It might be useful in your particular case because it’ll give you an opportunity to review configuration as it will be on real device when you restore that backup … so you can prepare necessary steps to reconfigure device to a state it was before the latest mayhem. But if you want to use this kind of setup to its fullest, you really should try to get yourself anotehr device of exactly the same mode as you have … in this case restoring backup will be (almost) successfull and you will be able to prepare necessary configuration steps precisely (with some other model, the prepration will be very approximate).
Solved my problem thanks to Cloud Hosted Router images for virtual machines available here
Steps taken are:
Get .vmdx image
Create Gen1 Hyper-V vm, attach disk image to it
Boot, login as admin no password, set any new password
ROS automatically gained an address in VM subnet, which was 172.x in my case, on this step, I was able to ping it from host, and enter through WinBox from host
Upload .backup file, restore (thankfully restore completed successfully, despite I’ve read backups only restore on identical hardware) ← since I’m working directly through vmconnect, I didn’t lose connection to virtual router here, therefore could fix any configuration issues I’ve made
Wait until reboot, login with credentials saved in backup
Assign IP address to ether1 interface to be able to connect with WinBox again, fix firewall filter to allow input from ether1
Connect with WinBox, /export rsc config, download from File section
Thanks Mikrotik for CHR being available!! Was very surprised all that described above worked.
It’s not that it doesn’t restore, it does most of time … but some parts may not make any sense. Example: your RB2011L has 10 ether ports (VM probably doesn’t). Your RB2011L has two switch chips (VM probably doesn’t). Etc.
So parts of configuration dealing with those missing parts may be lost when restoring (in your particular case you may not care about those details, but in some cases that can prove fatal).
Yeah, in my case there was no big settings related to ports and switch chips, but I had things related to IPsec, vlans and firewall rules I didn’t want to reconfigure again, which doesn’t relate to hardware, so now I’m happy
Seems like you were lucky (or smart) enough to use interface lists in firewall filter rules. If you’d use interfaces directly, then some firewall filter rules would be garbled (e.g. showing in-interface=*11 instead of in-interface=ether8 or something like that). Likewise anything referencing the missing interfaces. Etc.
