This page discusses a basic configuration for the MikroTik CCR2004-16G-2S+PC router in a role as edge
router for an advanced home network, or a small-business LAN. It also discusses the basic principles of
RouterOS configuration. My review of the hardware of this router is available
here.
Figure 1. CCR2004-16G-2S+PC, front panel and interior.
Configuration
The CCR2004 series is currently upgradeable to RouterOS v7.12. MikroTik recommends upgrading to the latest
stable version during initial install. Note that this router cannot be downgraded to RouterOS v6 or
earlier.
This router can be configured in various ways:
WinBox. This is a Windows application (there are ways to run it on a Mac or Linux machine, but no native
version for these OSs is available). It displays a GUI on the local PC and configures a remote router
via an encrypted network link to the RouterOS API service running on the router. It typically connects
to the router via its IP address, but can discover the router and connect to it via the router's
hardware address. This is especially useful if the router does not have an IP address yet, or if you
accidentally lock yourself out of the router because your PC can no longer connect to the router via L3.
However, configuring the router via its hardware address is overall less reliable than via its IP
address (unless the PC running WinBox is directly connected to the router). I actually like WinBox,
because it feels much like using a web GUI, but without the inherent obsolescence risk and sensitivity
to browser vagaries of web GUIs.
Webfig. This is a web-based GUI that replicates almost all functionality of WinBox. It
works inside a web browser, so some of the functionality may not be available in some browsers or with
some combinations of browser settings (e.g. rearranging the ordering of firewall rules by
drag-and-drop).
I am somewhat suspicious about the long-term viability of a web-based GUI, because I have witnessed the
web GUIs of both Cisco and D-Link equipment no longer working after a few years, as a consequence of
frequent discoveries of security and privacy risks (e.g. in Adobe Flash and Java applets). On the other
hand, Webfig seems to use exclusively JavaScript on the client, which is a better long-term bet.
RouterOS CLI. This, in turn, is accessible in several ways:
telnet, enabled by default but not recommended for obvious security concerns.
SSH (e.g. with PuTTY), highly
recommended, but not enabled by default.
serial port (e.g. with PuTTY). This is
the most reliable way to access the CLI, and you are unlikely to lock yourself out of the console
port by by making a configuration mistake. Also, the console port works by default at 115,200 BAUD,
compared to the measly default of 9,600 BAUD on Cisco devices (it can be set at up to 115,200 also
on Cisco devices, however).
console window in MikroTik WinBox.
console window in MikroTik Webfig.
By default, Webfig is only accessible via HTTP. To enable Webfig over HTTPS (and there is every reason for
doing so), follow MikroTik's
one-time procedure.
I read that a mobile phone app is also available for configuring the router, but I did not test it.
As usual with network equipment, security requires that this router is not physically accessible to
unauthorized persons. Access to the configuration services via the network and serial port must also be
restricted to authorized computers only, and the number of user accounts (especially of the administrator
type) must be limited to the minimum indispensable (one for each administrator, and possibly a single one
as a spare). The default admin account should be renamed, and safe passwords used on each
account. A few ways to secure the router are discussed below.
A nice touch of the RouterOS CLI is that all keywords are color-coded in the terminal window (as long as
your terminal software allows this). Color-coding is active even while you type in the terminal window.
RouterOS basics
Like Cisco IOS, a RouterOS configuration is entered in the CLI as a series of one-line text commands. The
similarities between the two configuration languages, however, end here. While IOS is limited to just a
few hierarchical levels of configuration (e.g. in the interface command),
almost every RouterOS command has nested levels and sublevels. Nested RouterOS commands look like a nested
folder structure, with each level separated from the next by a forward slash like Linux folders.
"Root-level", or top-level, commands can be prefixed by a slash, just like root folders. If you
type just a slash and command name (e.g. /ip) and hit enter, you
enter the ip substructure, and can issue multiple commands at this level
(e.g. firewall) without needing to re-type
/ip. In the same way you can enter, and stay in, sublevels of this
command. On the other hand, if you type /ip/firewall followed by a
complete firewall command and/or parameters, the prompt remains at the "root" level after
executing the command.
Hitting enter always causes RouterOS to attempt evaluating the current command. This may fail if
some essential parameter is missing. Hitting the up arrow key displays the previous command, and
hitting it multiple times steps back into the command history. Down arrow moves through the
command history in the forward direction. Hitting backspace deletes the last typed character, and
hitting left arrow and right arrow moves the cursor in either direction along the
current line.
You can reach a command sublevel also by separating the level and sublevel with a space, as an alternative
to a slash. For example, /system/note and
/system note are equivalent. The latter notation seems to be preferred in
recent documentation.
To move up one level only, type .. (just like in Linux and MS-DOS CLI). To
move up two levels with a single command, type ../... To move all the way
up to root level, type /.
F1 displays the list of commands available at the present level. It also works while you are
typing a command. A second F1 displays a list of function keys and
Ctrl+key combinations. Tab while you are typing a command performs autocomplete (if the
CLI recognizes that there is only one possible alternative). If there are multiple alternatives, a second
Tab displays the list of alternatives. \ (backslash) allows you
to continue typing a command on the following line (but cannot be used in the middle of a keyword).
If the word you are typing is wrong for the present context or misspelled, it turns red. For example, if
you start typing "/ip interface", the second word turns red as soon as you
type "/ip in", because no command starting with "in" is available in the /ip command context.
Scripting
RouterOS v.7 comes with a very powerful scripting language that lets you implement complex dynamic
behaviors based on specific router settings and events. The
documentation of this
scripting language by MikroTik can be a good start, but is not quite sufficient in the long run. If you
want to use, or explore in depth, scripting with this router, I recommend the 2023 book by Nigel Bowden
"MikroTik Scripting". As far as I know, it is the only book dedicated to this subject available
at present.
The interpreted scripting language offers operators, flow control, scope delimiting blocks, built-in
variable types (including primitive types and arrays), and function calls with arguments. The syntax is
quite similar to those of C, C++, Java, Javascript, and C#. If you know one or more of these programming
languages, you will only need to learn a few syntax peculiarities required by the specialized execution
environment. RouterOS also makes non-standard additions to the list of operators, especially operators
that take IP addresses as operands. Provisions for issuing RouterOS commands within scripts are of course
available (so scripting is not a substitute for learning RouterOS). The scripting language is strictly
procedural and does not offer classes, objects or other high-level constructs available in modern
object-oriented languages. Mathematical operators only work on integers and other data types that can be
treated as integers (e.g. IP addresses, which opens up interesting possibilities ordinarily available only
in high-level programming languages).
Some users believe that the RouterOS scripting language is far too powerful, given that one can
easily write scripts potentially usable as hacking tools, and that RouterOS comes with a built-in
filter-based packet sniffer that can forward captured packets to a Wireshark instance running on a remote
PC for further analysis, which can be used by malicious hackers to further penetrate your network.
This is one more reason for learning how to properly secure these routers. They are definitely not
"fire and forget" tools to be left unattended after the initial configuration, since a malicious
hacker may use system vulnerabilities or a sloppy configuration to transform your router into a powerful
tool for criminal activities.
This has indeed happened in the past (see
here for more
details), and is especially likely to happen to users who neglect to install recommended updates to
vulnerable versions of RouterOS. Nine months after the problem described at the above link was fixed in a
new firmware release available for free from MikroTik, an estimated 35,000 Internet-connected MikroTik
routers remained vulnerable to this specific attack, while 500,000 were vulnerable via their
insufficiently secured web GUI, and 900,000 via insufficiently secured WinBox.
It is a good idea to check whether there are scripts scheduled for execution on the router (especially
those scheduled for periodic execution). If you don't recognize some of these scripts, it is probably time
to start reviewing the router security, beginning with (1) make an offline backup of all scripts and
router settings, (2) delete the suspicious scripts, (3) change to a new, more secure password, and (4)
reduce or (preferably) totally shut off access to the router's administrative services from the WAN side.
An in-depth inspection of all LAN clients that can use Remote Desktop (or other remote control software)
and at the same time have access to the router administrative services is also necessary, because this is
an important vulnerability.
Changing a setting
When it comes to e.g. changing a setting or removing a setting in a given interface, RouterOS requires a
rather counterintuitive procedure. Knowing the name of the interface is not enough. Instead, you need to
know the number that RouterOS has associated with the interface when the interface was
created. For example, before you can modify a setting of a bridge, you need to display the numbers of the
existing bridges, with the command:
/interface bridge print
An example of the output:
Flags: X - disabled, R - running 0 R name="bridgeLAN" mtu=auto actual-mtu=1500 l2mtu=1596 arp=enabled
arp-timeout=auto mac-address=78:9A:18:4D:9E:00 protocol-mode=rstp
fast-forward=yes igmp-snooping=no auto-mac=yes ageing-time=5m
priority=0x8000 max-message-age=20s forward-delay=15s
transmit-hold-count=6 vlan-filtering=no dhcp-snooping=no
add-dhcp-option82=no
The bridge number is formatted in bold in the above output. Once you know the number of
the bridge you want to change or remove, you can use it, e.g.:
/interface bridge set 1 dhcp-snooping=yes
Incidentally, changing this setting may cause all interfaces to shut down for a few seconds, which may
cause your PC to lose contact with the router (depending on how PC and router are connected).
The task can be made easier by using, instead of the number, the script
[find where name="bridgeLAN"], where the return value of the script (in
this case, the bridge number of whatever bridge matches the specified name) will replace the square
brackets and their content. This removes the need for the administrator to know the bridge number, and the
whole procedure only requires knowing the bridge name:
/interface bridge set [find where name="bridgeLAN"] dhcp-snooping=yes
When changing the configuration of a hardware interface, an added level of difficulty is that interfaces
have a default name, assigned by the system, but can be renamed by the administrator. However, the default
interface name remains available, and can be used to access the interface with the slightly different
script [find default-name=ether1].
Removing a setting
To remove an entity that was previously created with an add command, it is
generally possible to use the remove command in the same context. The
principle is the same as when changing a setting: you need to know the RouterOS internal number of the
entity to remove, or use the script discussed above. For example:
/interface bridge
add name="bridgeLAN2"
remove [find where name="bridgeLAN2"]
Should you need to delete all instances of a given type, you can do this with the syntax
remove [find] . Before using this syntax, make sure this is what you
really want, and that you downloaded to your PC all the configuration backups currently stored on the
router. For example, to delete all files from the router:
# WARNING!! download all files from the router to your PC first,
# because this command will delete also your configuration backups
# from the router.
/file remove [find]
Deleting an entity that is currently in use may not be allowed. The entity may need to first be
deactivated, and/or it may be necessary to remove all references to this entity from other parts of the
configuration.
Basic initialization and basic hardening
This section includes the initial configuration of the basic ruter functionality. As such, it is likely
that this will be your first task to carry out on a new MikroTik router. For this reason, I suggest that
you perform this configuration via WinBox or WebFig, rather than the RouterOS CLI.
For a detailed description of RouterOS hardening, I suggest the 2017 book by Hart:
MikroTik Security Guide. You could argue that the advice in this book is already available
somewhere or else on the web, but the book is very modestly priced, and collects the information in a
single place. Advice found on the web is of varying quality and reliability, and quite a bit of this
advice refers to early versions of RouterOS and is no longer applicable.
I will not discuss here the whole hardening procedure in detail, but I suggest carrying out at least the
following general tasks:
Set a reasonably secure password for the admin account. Preferably 8
characters or more in total, including at least one digit, at least one uppercase letter, at least one
lowercase letter, at least one non-alphanumeric character (e.g. #, &, % etc.).
Rename the admin account to something else not easy for a hacker to
guess. This adds a further layer of security because the hacker will not be able to tell whether he/she
is attempting to use the wrong password or the wrong user name.
Keep the number of user accounts to a minimum. However, in a company environment, if you have multiple
administrators, avoid the use of shared accounts (because they result in no individual accountability
for mistakes or intentional abuse). Keep a separate Excel sheet of users (not passwords) updated, and
immediately remove from the router the accounts of personnel who quit, are fired, or are no longer
responsible for the router. It is very easy to re-create a deleted user account afterwards, if a user
returns to his previous router administrator duties. Record the history of changes in the Excel sheet,
and add a timestamp to each change.
Rename the router from the default MikroTik to something else that does not openly declare what
make and model it is.
Ideally, before login just display the login: and password: prompts and nothing else.
If you really must, display also a router name that gives away nothing about the company, location, and
function of the router (e.g., you may need to identify the router if your company has several).
A pre-login notice that promises dire consequences for any hacker who will attempt to log in is largely
unenforceable, and may in fact have the opposite effect than intended (but some companies may require
displaying a notice for insurance and/or legal purposes). The less your router says before login, the
better. After login, the user already has access to everything, so at this time there is no point in
trying to scare off a hacker with a notice promising the fires of hell.
If you must have a pre-login notice, remove the brand and model of router, and the RouterOS version it
runs. The less information it gives away, the better.
Perhaps the following suggestion is slightly paranoid, but many makers of network equipment (e.g. Cisco)
use hardware addresses that follow a recognizable pattern. To prevent a hacker from identifying the make
and series of your router, change the hardware address of your router's WAN-facing interface to a random
hardware address. The chance this random address will collide with a pre-existing address on your
network is virtually nil, but if it does happen, just choose another random address. Note that some ISPs
expect your router to have a specific hardware address, and in this case you do not have a choice.
Disable all unused packages and services. The total list of services available on the router is long,
but on a CCR2004 router connected to an ISP by Ethernet you are only likely to need a couple of ways to
access the router configuration, and little else. You certainly don't need the PPP and hotspot packages,
for example. You may need only IPv4, and in this case there is no reason to leave IPv6 enabled. With
regard to services, you should only use the strict minimum. I recommend you disable Telnet, FTP, DNS,
Bandwidth Test, API, API-SSL, SMB, SNMP, WWW, and perhaps SOCKS (unless you need it as part of an
SSL-enabled proxy) and UPnP. This should leave only SSH and WinBox enabled to configure the router, and
possibly WWW-SSL (i.e. HTTPS). You are very likely to need also DHCP. The fewer, the better.
Restrict access to the remaining ways to configure the router. Unless you really, absolutely, need to
configure your router through the Internet, block all administrative access from WAN interfaces and
allow accessfrom only one or two LAN-facing interfaces. You may also want to restrict access to only one
or two LAN IP addresses. The fewer, the better.
Make a backup of the configuration after any change is made, and save a copy of all backups offline. I
suggest you use the file name RouterName-YY-MM-DD-ver, where
RouterName is the router name,YY-MM-DD
is the date and ver is a progressive version number for multiple backups
made the same day. The router adds the .backup file extension.
Backup files are stored in a non-human-readable format, so after making a backup I suggest you also
export the configuration with export file=RouterName-YY-MM-DD-ver.txt,
which saves the configuration in a text file with the name
RouterName-YY-MM-DD-ver.txt.rsc (that's right, notRouterName-YY-MM-DD-ver.txt) and save this file offline, together with
the respective configuration backup. You can use the text file as a script to re-enter part or all of
the configuration by copy-pasting from the file to the CLI, if necessary. You can also edit a copy of
this file before you paste the updated configuration into the CLI.
The section discussing firewall rules and mangle (below) contains an example of firewall configuration.
Shutdown, reboot and reset button
It seems that most users of MikroTik routers simply flick the power switch or cut down the power to their
routers when they wish to shut them down. The latter applies to the CCR2004, since it has no power switch.
Unless the router is writing to flash memory at the exact moment power is cut, this procedure seems to be
completely safe. Therefore, if you are configuring the router, allow for a few seconds of pause from the
last command before you shut down or reboot the router. Some operations, like making a backup of the
router configuration or file transfers, may require tens of seconds.
If physical access to the router is inconvenient (e.g. the router is located in a locked-up server room),
or if you need to make sure that it is safe to shut down, issue the CLI command
/system shutdown . Of course later you will need physical access to the
router to start it.
To reboot, the simplest procedure is probably to power down with the power switch, then power up. Also in
this case, if physical access to the router is inconvenient, you can issue the
/system reboot command in the CLI.
/system reset-configuration is used to reboot to the default router
configuration.
It is also possible to schedule a periodic reboot of the router, but this is generally useful only with
consumer-grade equipment that hangs frequently. A CCR2204 router that needs periodic reboots is defective,
poorly configured, or is using a corrupted or buggy RouterOS image.
The reset button has multiple functions:
A short press of the button during normal router operation does nothing. This is intentional, so you
don't need to worry about accidentally pressing the button while plugging or unplugging the Ethernet and
console cables.
During power-up, keeping the reset button pressed until the LED starts flashing, then
releasing the button, loads the router's default configuration.
During power-up, keeping the reset button pressed until the LED stops flashing tells
the router to look for Netinstall servers.
There may be more to the reset button, but the above functions are those documented by MikroTik.
Saving the settings
Normally, settings are immediately applied to the router and stored in the router configuration. A safe
mode is available, which reverses the latest settings changes and reboots if the router unexpectedly loses
contact with the administrator session. Safe mode is optional, because some changes of settings do cause
e.g. the interfaces to temporarily shut down as a normal behavior, interrupting the administrator session.
In these cases, you probably don't want the latest changes to be lost. Other than safe mode, RouterOS has
no equivalent to Cisco's running-config and
startup-config, so it is particularly important that you save frequent
configuration backups on the router while you are working.
Interfaces
The Ethernet interfaces default names are ether1 to
ether16. Each switch chip is connected to eight of these hardware ports,
and in addition the connection of a switch chip toward the CPU is regarded by RouterOS as an interface of
sorts (switch1cpu and switch2cpu).
However, normally you will not be directly configuring these two interfaces. Layer 3 hardware offloading
and layer 2 hardware offloading, as well as hardware-offloaded port mirroring, is available for each of
these 16 Ethernet ports.
The SFP+ cages are named sfp-sfpplus1 and
sfp-sfpplus2. If sfp-sfpplus1 is in use,
it appears to be designated as root port by default.
At this point, it is a good idea to define lists of interfaces. They will become useful later during the
configuration. A list of interfaces is a way to configure all the interfaces on the list with a single
command, instead of explicitly repeating the command for each individual interface. We will use
ether16 for a special purpose later, so we place it in its own list.
Interface lists can be used, for example, in firewall rules. However, there are many cases in RouterOS
configuration where interface lists would be useful but are not accepted, and interfaces must still be
configured, or listed in configuration commands, one-by-one.
By default, loop protection is off. It is a good idea to enable it on all Ethernet interfaces, just in
case later on you will start connecting external switches to these interfaces, and by mistake create a
loop. By default, the router tests for loops every 5 s and, upon detecting a suspected loop, disables the
interface for 5 minutes (these times are configurable, but I recommend not setting the disable time at 0,
which means forever or until the router is reloaded).
/interface ethernet
set ether1 loop-protect=on
set ether2 loop-protect=on
set ether3 loop-protect=on
set ether4 loop-protect=on
set ether5 loop-protect=on
set ether6 loop-protect=on
set ether7 loop-protect=on
set ether8 loop-protect=on
set ether9 loop-protect=on
set ether10 loop-protect=on
set ether11 loop-protect=on
set ether12 loop-protect=on
set ether13 loop-protect=on
set ether14 loop-protect=on
set ether15 loop-protect=on
set ether16 loop-protect=on
Note that we do not enable loop protection on the SFP+ cages. The reason is that, in the configuration
example discussed below, we will configure the cages in an unorthodox way that is detected by the router
as a loop. Ordinarily, you could enable loop protection also on the cages.
A characteristic of RouterOS is that it allows giving names to interfaces, as well as groups of
interfaces. The names can be chosen to be informative, and in this sense they work like comments (which
can also be attached to interfaces and interface groups). The difference is that the newly assigned
interface names can be used to configure these interfaces instead of
ether1 etc. (which also remain available), while comments do not have any
effect on router configuration.
For example, more informative names can be assigned to the serial (=console) interface(s):
/port
set 0 name=serial0
set 1 name=serial1
From now on, to address the serial port 0 you can refer to it by its name
serial0. Another example:
/port set 0 name=console0
/port set console0 baud-rate=115200 data-bits=8 parity=none stop-bits=1
At this point, console0 is the valid name for port
0. To remove a name, issue the command:
/system console disable 0
However, it is a good practice for each port to have one easily remembered name. Also, do not forget to
re-enable the console port if you plan on using it:
/system console enable 0
/port set 0 name=serial0
Incidentally, this router has only one serial port. Some of the unused soldering pads on the motherboard
may support a second serial port, but using it is not as simple as soldering a cable and connector to the
motherboard. All the components for the second serial port seem to be missing, including the UART. Other
router models may have an internal connector and electronics installed for a second serial port, but not
the model being discussed. My best guess is that RouterOS supports two serial ports by default and shows
both in the WinBox GUI, even when no corresponding hardware is present.
Ethernet bridges
Typically, a home or small-office router has only one or two L3 interfaces facing toward the Internet (or
toward the ISP's WAN when the ISP does not offer a public IP address for direct access to the Internet).
For the example configuration, however, I choose a different configuration. Each of the two groups of
Ethernet ports is configured as a switch. One of these logical switches is connected to the WAN, the other
to the LAN. This provides multiple Ethernet interfaces on both the WAN and the LAN side of the router, for
maximum flexibility.
Other routers and router-switches are equipped with a built-in group of Ethernet ports hardwired as a
switch. This is the case, for example, of the Cisco RV series and
C900 series of routers. In the CCR2004 routers, instead, each of
the 16 Ethernet interface of this router can be configured as a fully routed interface, or alternatively
as part of a switch. The latter is done by creating a bridge and adding to to it the desired Ethernet
interfaces.
Note that earlier versions of RouterOS had a different way to configure a set of ports as a switch. Since
the CCR2004 does not run earlier RouterOS version than 7, this is irrelevant to the present discussion. If
you use an older MikroTik router with an older version of RouterOS and for some reason cannot, or do not
want to, upgrade to the current version, you need to check which configuration procedure applies in your
case.
In the following example, we add each Ethernet port to a bridge one by one. For complex configurations, it
can be more efficient and less repetitive to define two ranges of interfaces, one for the WAN and one for
the LAN. We can subsequently re-use these ranges whenever necessary. Either way, each individual Ethernet
interface remains separately configurable by using its pre-defined name.
Note that we are not adding ether16 to
bridgeLAN. We will use this interface for a special purpose.
Creating a list of interfaces is not the same thing as adding the interfaces to a bridge. A list of
interfaces is only a shorthand notation for addressing multiple interfaces by a single name, but simply
adding interfaces to a list does not change their operation in any way. When interfaces are added to a
bridge, instead, their operation changes according to the bridge configuration.
DHCP client
The router will get an IP address with DHCP on the WAN-facing switch. Although we could configure one
Ethernet port to receive a dynamic IP address, it makes better sense to do this on
bridgeWAN. In this way, any of the Ethernet ports connected to this bridge
can be physically wired to the WAN. bridgeLAN is instead configured with a
static private IP address. This bridge becomes the gateway of our LAN.
Note that I use two public DNS servers from Google, in part because they are very reliable, and in part to
bypass the censorship mandated by many national governments onto the DNS servers located within their
respective national borders (not only in totalitarian dictatorships but also elsewhere, including in the
EU).
These are the DNS servers that the LAN clients will use. As configured earlier on, the router itself will
use whatever DNS server(s) it receives as part of the DHCP configuration of
bridgeWAN. In a typical configuration, these DNS servers are chosen by the
ISP. The router's DNS server(s) only matter when using the router's network utilities, and censorship on
these DNS servers does not prevent the LAN clients from reaching the censored Internet locations (except
in countries that additionally enforce censorship through the use of national firewalls, which can be
beaten by using open VPN servers or P2P proxies in non-censored countries).
If your only reason to use different DNS servers on your LAN clients is that your ISP blocks access to
certain web sites by de-listing them in their DNS servers, you could configure a different DNS server in
your web browser. Several modern web browsers, e.g. Firefox, can be configured to access a special DNS
server via HTTPS, instead of the DNS servers configured in your operating system. This may not work, of
course, if your ISP additionally blocks the IP addresses of the desired web sites and/or HTTPS DNS servers
via a firewall (you need to use a web proxy in this case).
There is no need to worry about DHCP messages from the WAN being relayed to the LAN and messing up the
LAN's client addresses, because we will implement NAT between the WAN and LAN. On a RouterOS machine, this
by default causes DHCP messages to be dropped by the NAT.
We reserve two DHCP addresses, one for the administrative PC and one for a printer.
Note that the client ID is the same as the hardware address (=mac-address)
prefixed with 1:, but the format is slightly different (all lowercase and
no leading zeroes for the client ID, all uppercase and leading zeroes present in hardware address).
Specifying both addresses has a better chance of success than using either address alone. Some hosts may
fail to acquire a reserved IP address if only the client ID is supplied, others may fail if only the
hardware address is supplied. This is a problem I encountered multiple times in Cisco IOS, for example.
The way RouterOS works when asked to renew a lease of a reserved IP address is slightly unexpected for me.
Assuming that the router has already leased a reserved address to a client, if the client asks to renew
the lease before it has expired on the server (e.g. by manually issuing ipconfig /renew on a
Windows PC), the server replies by sending once more the existing lease with its
original creation date/time and current expiry date/time, not a new
lease (to see all details of the lease, issue ipconfig /all). This means that the creation
date/time of the lease can be days or weeks ago if the client has been running 24/7, even though the lease
lifetime is only set to one hour on the server. Thus, it appears that the server
extends the existing lease whenever the latter expires, rather than issuing a new lease
with a new creation date/time. This behavior may help preventing a malfunctioning LAN host from obtaining
a new lease by frequently requesting new leases even though the current lease has not expired.
On the other hand, ipconfig /release followed by ipconfig /renew does cause the server
to delete the existing lease and issue a new lease with a new creation date/time.
It may be a good idea to harden the router againts DHCP address starvation attacks. This type of attack
consists of sending from one LAN host (e.g. by executing a script) a large number of DHCP requests, each
with a different, random made-up MAC address. This causes the router (within seconds if the attack is very
fast) to exhaust the pool of available IP addresses, and deny all subsequent DHCP requests (including
legitimate ones).
The following configuration creates a custom firewall chain named
dhcp1 (see also the firewall section). The first
filter action jumps from the input to the
dhcp1 chain whenever the action finds a broadcast packet marked
dhcp by the mangle. The second filter action then either returns to the
input chain or passes control to the third action, depending on whether
the specified limit=1,3 (1 packet in 1 s, not counting an initial burst of
3 packets that are always allowed) has been exceeded. The third filter action drops the packet.
The overall effect of this configuration is that the router drops all packets from UDP source port 68 to
UDP destination port 67 that arrive to the router, if these packet are more frequent than a given
threshold. To ensure a faster recovery from this type of attack, one can also configure a short duration
of DHCP leases. The default RouterOS lease-time is 10 minutes, after which
the client is supposed to renew the lease (but typically does not, in the case of an address starvation
attack). Lowering this setting to e.g. 5 minutes halves the recovery time for any lease secured by an
address starvation attack. In a small to medium LAN, the resulting increase in DHCP traffic is of no
practical consequence.
Unless the DHCP server receives more than 3 legitimate DHCP requests in 1 s, the
limit is unlikely to cause disturbances of the DHCP service. Therefore,
this configuration should be modified if the DHCP server is ordinarily very busy.
DHCP snooping
We likely want to implement DHCP snooping on the LAN, so that DHCP messages from a rogue DHCP server
(either accidentally or intentionally activated on one of the LAN clients) will not be relayed by the
router to other LAN clients. The router will drop any DHCP server messages coming from the Ethernet
interfaces attached to the bridge (DHCP client messages will still be forwarded to the DHCP server, of
course).
A practical problem is that bridgeLAN has already been created at an
earlier time.To gain access to bridgeLAN and change its configuration, we
can use the simple script [find where name="bridgeLAN"]discussed above.
/interface bridge set [find where name="bridgeLAN"] dhcp-snooping=yes
We cannot explicitly set a bridge as the trusted interface. The above setting is all we need to do if we
want to allow DHCP offers from the router itself, and block any DHCP offers from being forwarded from LAN
ports to other LAN ports. In particular, we should not set any router interface to
trusted.
Free software is available for running a DHCP server on a Windows PC without a need to install it (e.g.
see www.dhcpserver.de). Thus, it is entirely
possible for a non-administrator to run such software on a corporate PC, and in this way to bypass the
corporate software security policies. Therefore, it is really a good idea to activate DHCP snooping on the
router. In the lack of DHCP snooping, a single rogue DHCP server may largely disable a DHCP-configured
corporate LAN and prevent its clients from accessing the Internet.
DHCP option 82 can be configured on the router's DHCP server. We only need it if the router's DHCP server
messages need to be relayed to a different network than the router's DHCP server. This is not the case in
the present configuration example.
NAT
We will use port NAT between bridgeLAN ("inside" interface) and bridgeWAN ("outside"
interface). This type of NAT, called masquerade in RouterOS when the
outside IP address is dynamic, remaps both the inside source IP address and the inside source port. In
RouterOS, the NAT functionality is grouped under the IP firewall category.
Some additional configuration may be required if the bridgeWAN IP address
changes frequently, leaving some of the existing connections "hanging". Check the RouterOS
documentation. Under certain
conditions, the same problem may temporarily occur when the NAT is initially enabled. The result is that
some pre-existing connections from LAN clients may appear not to be NATed, but the problem will correct
itself as these connections gradually time out.
NTP client
It is necessary to start the NTP client on the router and to assign one or more NTP servers that the
router will query. The following commands assume that the DNS client on the router is active. If not, you
need to enter the IP addresses of the chosen NTP server(s) instead. You should choose at least one public
NTP server in your country, plus one public NTP server in the same continent. Also, set the right time
zone, because NTP does not handle time zones and only "knows" about UTC time.
/system ntp client
set enabled=yes
/system ntp client servers
add address=europe.pool.ntp.org
add address=se.pool.ntp.org
/system clock
set time-zone-name=Europe/Stockholm
Services
The following configuration commands disable all services except WinBox, HTTPS and SSH. These three
services are enabled but only accessible from IP address 10.10.10.100, which is the administrative PC.
This configuration is only an example. You will need to adapt it to your network. SSH is additionally set
to use strong cryptography.
/ip firewall service-port
set ftp disabled=yes
set tftp disabled=yes
set h323 disabled=yes
set sip disabled=yes
set pptp disabled=yes
/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set ssh address=10.10.10.100/32 disabled=no
set www-ssl address=10.10.10.100/32 certificate=Webfig \
disabled=no
set api disabled=yes
set winbox address=10.10.10.100/32 disabled=no
set api-ssl disabled=yes
/ip ssh
set strong-crypto=yes
Firewall filters and mangle
The main purpose of the following configuration is to deny certain TCP connections coming from the WAN and
directed to the router itself. This includes most of the TCP ports used by administrative interfaces. Most
of these services are already switched off, or open only to the administrative PC (see the preceding
section), but it is a good idea to block their TCP ports, too, just in case some of the services are
activated by mistake later on.
However, we do not want to block the same service protocols from passing through the router, because some
LAN clients may have legitimate uses for the same protocols. To achieve this goal, we need to use the
proper firewall chain.
In RouterOS, the firewall has multiple chains independent of each other. The
input chain processes all traffic from the WAN (as specified by
in-interface=bridgeWAN) to the router itself (not to the LAN). This is the
chain to use for the goal outlined above. The router goes through the firewall rules in the order they are
stored in the configuration (by default, this is the order in which the rules were entered). In the
following rule, some of the settings are default values and in most situations the rule would work without
specifying them, but it does not hurt to enter them explicitly, just to be sure that these settings have
not been changed by some earlier configuration.
It is interesting to note that switching off a service does not have the same consequences as dropping WAN
traffic to the service with a firewall rule. In the former case, the router sends back a message saying
that the requested TCP port is not open. A hacker will then know that "something" is listening
on that IP address. In the latter case, instead, the router is a black hole swallowing all connection
requests to that specific TCP port without replying. A hacker only sees her connection requests time out,
and has no evidence that there is something at the probed IP address and TCP port. See below for a
discussion on how to use mangle for an even better protection against hackers.
If you know you will not remotely access the router from the Internet, you can just as well completely
block all access to the router (not to the LAN) from the WAN. Instead of the firewall
filter discussed above, just use e.g.
/ip firewall filter add action=drop chain=input comment="drop all from bridgeWAN to router"
in-interface=bridgeWAN log=yes log-prefix=WAN_input_denied
. This does not include connections to the WAN originating from the LAN or router, and their replies from
the WAN to the LAN or router.
Some of the firewall rules shown below are created by the initial wizard, and can be identified by their
comment="defconf:..." description. I am adding them here,
because it is useful to see the order in which the rules are specified. The router stores the rules in the
order they are configured, and the firewall processes the list of rules from top to bottom. If the
ordering of the rules need to be manually changed, it is far easier to do this by drag-and-dropping them
in WinBox than through the CLI. Some users have reported that drag-and-dropping firewall rules does not
work in WebFig, probably because of specific combinations of web browser settings.
The forward chain is used for rules that control traffic entering one
router interface and directed to another interface. This is the chain to use for blocking traffic from WAN
to LAN, or vice versa (depending on which interface is defined as
in-interface).
We explicitly allow all traffic from bridgeLAN to be forwarded.
add action=accept chain=input comment="accept all input from bridgeLAN" \
in-interface=bridgeLAN
One more default rule, this one to drop invalid packets (it would serve no useful purpose to forward
them):
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
invalid
Then we drop whatever has not been allowed onto the input chain by the
preceding rules. There is no implicit "block everything" rule at the end of a list of RouterOS
firewall rules, so you must enter this final rule explicitly for each chain, if required:
add action=drop chain=input comment="drop all else input" log-prefix=\
"drop_all_else(input)"
Now we continue with the forward chain rules, ending with a blocking rule
for this chain:
The mangle functionality attaches one or more flags to arriving packets, so that further processing can be
performed on them. We use this functionality to register (in the address list
drop_traffic) the WAN IP addresses that try to send traffic to any of the
administrative interfaces of the router. The firewall rule
"drop input from bridgeWAN to router services" (see above) then
blocks all traffic from this address for the following 10 minutes, at which point the address is removed
from the list and the temporary blockage ends. This should be enough to make the attempts of a hacker so
frustrating that she will eventually give up and choose an easier target.
There is a third pre-defined RouterOS firewall chain, i.e. output. It
controls the traffic originating by the router itself. This chain has no firewall rule in the present
configuration, which means that all traffic originating from the router is allowed. The router needs
access to the LAN and WAN for several reasons, e.g. neighbor discovery, and may need access to the
Internet for e.g. periodic checks of availability of new RouterOS versions.
Custom firewall chains can also be defined. One possible use for a custom chain, for example, is grouping
together all rules that apply to a specific protocol on a specific interface.
User LEDs
The CCR2004 has two user-configurable LEDs placed directly above the power LED (many other MikroTik
devices only have one customizable LED, i.e. user-led). These LEDs can be
configured to have a number of functions. I chose to have the two LEDs blink whenever data is transmitted
by the bridgeLAN and bridgeWAN interfaces.
I find this useful, since all traffic between LAN and WAN passes through these bridges, but the only
visual indications of this traffic are otherwise the LEDs on the individual interfaces associated with
either bridge.
The LEDs of the SFP+ cages can be customized in the same way, but not the LEDs of the RJ45 interfaces.
Testing the SFP+ cages at 10 G
With this router, I am beginning to add 10 Gbps links in my home network (better late than never, and
pricewise also better now than earlier on). This router and a MikroTik
CRS305 router-switch are so far the only 10 G capable devices
on my network. Therefore, I was not able to test them with real-life 10 G links carrying data at this
speed, and I was forced to set up an artificial way to use the 10 G interfaces.
The test LAN architecture is structured as follows:
Interfaces ether9 through ether15 are
grouped under bridgeLAN as previously configured.
A new bridge bridgeLAN1 is created, containing interfaces
ether15 and sfp-sfpplus1. Additionally,
sfp-sfpplus2 is added to bridgeLAN:
A firewall rule is added for allowing all traffic from bridgeLAN1to be
forwarded. All traffic from bridgeLAN1 to the WAN will pass through
bridgeLAN, where the firewall rules of the latter are applied to traffic
to the WAN. Therefore, we just allow everything from bridgeLAN1.
add action=accept chain=forward comment="accept all input from bridgeLAN1" \
in-interface=bridgeLAN1
10 G singlemode transceivers are inserted into sfp-sfpplus1 and
sfp-sfpplus2, and joined with a length of singlemode fiber.
A PC is connected with an Ethernet cable to ether16.
If we follow the network traffic originating from the PC and directed to the WAN, we see it
enter ether16,
be bridged by bridgeLAN1,
exit sfp-sfpplus1,
enter sfp-sfpplus2,
be bridged by bridgeLAN, and from there
be routed and NATed to the WAN.
This architecture has practical consequences on which interfaces can use hardware offloading. We can see
this by listing the ports of each bridge:
Hardware-offloaded ports are indicated by the H flag. The
I flag means inactive, usually meaning that nothing is physically
connected to the port.
This router is equipped with two switch LSIs. Each of them can perform hardware offloading for one bridge
only. Because of the way I chose the ports associated to each bridge, each of the two bridges only
contains ports connected to the same switch LSI. By default, the first bridge created on a given switch
LSI contains hardware-offloaded ports whenever possible. As a result, ports
ether0 to ether15 are hardware-offloaded.
Port ether16, on the other hand, belongs to the second bridge created on
one of the switch LSIs, so this port cannot be hardware-offloaded (even if you configure it as
hardware-offloaded, it does not display as such in the above list). In the above list it is inactive
because, when I generated the above list, the test PC was connected to
ether15, thus bypassing the path of the traffic through the two SFP+
transceivers and going directly to bridgeLAN.
The SFP+ cages cannot be hardware-offloaded, either, because they are not connected to a switch LSI but to
the CPU.
To make the traffic circuit longer, we can replace the fiber patch cord with the CRS305 configured as a
switch and equipped with two 10G fiber transceivers, one of them connected by a patch cord to
sfp-sfpplus1, the other with a second patch cord to
sfp-sfpplus2. In this way, the traffic is additionally switched through
the CRS305. Naturally, the throughput speed of the test circuit is capped to 1 Gbps by
ether16, and to 250 Mbps by the ISP if the PC connection is to the
Internet.
RouterOS books and training
If you need one or more certifications on RouterOS and MikroTik network devices, MikroTik offers quite a
variety of official certifications. Some
of the books and video courses discussed below are targeted to MikroTik certifications, but in-person
training, in spite of its much higher cost, is usually a better bet when a certification is the objective.
If you are looking for formal or informal training not leading to a certification, the range of choices is
broader. RouterOS and MikroTik routers are not as common as Cisco IOS and Cisco routers. Therefore, the
number of available books and courses on RouterOS is much smaller than training materials about Cisco IOS.
Much of the literature on Cisco IOS is published by Cisco, and is often available for free in electronic
format. MikroTik, on the other hand, maintains a reasonably well updated web site documenting RouterOS,
but does not make the contents available in PDF format for off-line use, nor publishes any books. Some
additional documentation is available on MikroTik bulletin boards, but its extent is not comparable with
the abundance of free information on Cisco IOS provided by Cisco, third-party companies, and individuals.
The quality of free RouterOS videos on YouTube, and the web in general, is extremely variable. I find
YouTube videos time-consuming, compared with printed materials of good quality. I can easily read four
times the amount of information from a book, in the time it takes for one of these videos to run in its
entirety.
Most individuals wishing to learn RouterOS in their own free time must rely on books, freely available
materials on the web, or pre-recorded video courses. Udemy seems to offer the large majority of video
courses specific to MikroTik and
RouterOS, and their prices are reasonable among this type of training materials. I am not impressed,
however, with the quality of a few of the introductory courses I had a chance to access. You can get the
same knowledge, quite possibly faster and cheaper, from a couple of good books, the MikroTik
documentation, and hands-on practice with a MikroTik router.
Another, and more important, criticism I have is that one or two video courses on RouterOS security
dedicate an entire lesson to port knocking as a secure way to access the router.
Port knocking is not secure, and should not be recommended as a way to access MikroTik routers, or any Internet-facing interface. Security-wise, this is just a "hack" that may give a false
feeling of security to inexperienced systems administrators, but does not stand up to the scrutiny of even
a moderately skilled security professional.
In the context of MikroTik routers, port knocking was described in a 2019 open-access paper by Mursyidah
et al. (IOP Conf. Ser.: Mater. Sci. Eng. 536 012129) and a subsequent 2020 paper by Idhom et al (J. Phys.:
Conf. Ser. 1569 022046). In spite of well-justified criticism of the method (e.g.
Linux.com, 2004), port
knocking on MikroTik routers has been re-hashed in multiple web discussions as well as the above-mentioned
video courses (perhaps as an easy way to "pad" these courses with open-source materials).
Until 2018, the web site portknocking.org collected information on this technique. The
web site is now dead and the URL seems to be occupied by Indonesian cybersquatters, but the original web
site is accessible on
Wayback Machine.
A few other techniques taught in some video courses on MikroTik routers can also be regarded as
problematic or obsolete.
I own, or have used, the following books. Some of these books are fairly old as RouterOS goes (RouterOS
version 7 was released in 2021, and introduced significant syntax changes). Today, some of these older
books would not be my first recomendation for learning from the ground up, but nonetheless they contain
some useful information for a discerning reader. The books I find especially useful are in
bold, but your mileage may vary.
Bowden 2023 - MikroTik Scripting.
Burgess 2009 - Learn RouterOS, 2nd ed.
Discher 2011 - RouterOS by Example.
Hart 2017 - MikroTik security guide.
Hart 2017 - Networking with MikroTik. MTCNA Study Guide.
Haddad 2021 - MikroTik switching with labs.
Haddad 2021 - Multicast on MikroTik with labs.
Zen 2019 - Theory, laboratories and exercises for MikroTik RouterOS, Routing.
Zen 2021 - Theory, Laboratories and Exercises for MikroTik RouterOS.
Because of the smaller installed base of MikroTik routers, compared to Cisco's, in-depth knowledge of
RouterOS is less common than Cisco IOS. This can be a problem or a boon in different circumstances. The
bulk of router admin jobs may be for a Cisco or other mainstream brand specialist. However, ads for
positions that require a MikroTik specialist are likely to attract a far lesser number of competent
applicants.
For self-learning on a budget, in addition to books and perhaps video courses, I would recommend to stick
with the MikroTik user forum, because the
quality of RouterOS information on YouTube, Quora and the like tends to be a bit spotty, and some of the
information that comes up all the time in web searches is several years old and outdated.
A company planning to install MikroTik routers in their network for the first time should do at least one
or two of the following things:
Send one or more of their sysadmins to paid RouterOS courses and/or certifications.
Hire a certified MikroTik sysadmin with proven work experience. If you decide to go with a
newly-graduated, newly-certified systems engineer with no experience of corporate work because of the
lower salary level, you must factor-in the cost of on-the-job training and the disadvantages of the
initial adjustment period.
Hire a proven MikroTik consultant.
The third option may be the most expensive up-front, but it is very likely to save time, money and
aggravation by getting things working on the first try, even when combined with one or two of the other
points.
Summary
RouterOS provides virtually all the capabilities expected of a modern multi-role router.
MikroTik offers free and acceptably timely updates to RouterOS for a minimum of 5 years,
and often for the lifetime of the equipment unless prevented by hardware limitations. This router also
provides reasonably sophisticated firewall capabilities, but
MikroTik does not provide a subscription service to keep the firewall automatically
updated against new threats.
Possible drawbacks of MikroTik routers are (1) RouterOS differs from Cisco IOS and
related OSs like IOS-NX, so a knowledge of these is not directly transferable to MikroTik routers, and
(2) the installed base of MikroTik routers is smaller than Cisco's. Consequently, there
is less published information on RouterOS (by both MikroTik and third-parties)
than on the Cisco IOS family. Nonetheless,
all the information really necessary for self-learning RouterOS is available, and
a sufficient number of user bulletin boards, paid courses, books, and MikroTik professional
certifications is available.
