MikroTik Solutions

Default Router Configuration
Login

Default Router Configuration

Help

Motivations

One of the most beautiful things about RouterOS is that, at bottom, its configuration is scriptable in plain text. It is this that makes my backup script more useful than a simple binary dump of the configuration, for example. It also means that, in principle, you can look at anyone’s RouterOS configuration /export and puzzle out what it’s doing, looking unknown commands up in the manual as needed.

What the manual doesn’t go into so much, however, is the “why” of it all, and the reason for that is that motivations are infinitely variable. This is why RouterOS is scriptable in the first place: your use cases for a given piece of RouterOS hardware are not necessarily mine.

Yet, the RouterOS lineup does include a set of default configurations, which cover a broad enough subset of the most common use cases that starting with them rather than configuring everything from scratch is generally a good idea. If your needs hew to the mainstream, they may serve as-is. If not, they do at least serve as useful starting points.

In this article, we’ll dive into the default configuration for an RB4011iGS+RM configured as a home Internet router, though the discussion applies adequately to the other “router” class devices in MikroTik’s lineup.

This article purposefully avoids discussing a default configuration for any of MikroTik’s Ethernet switches as they simply aren’t interesting enough to be worth discussing in detail. As proof, I offer a comparison of this article’s exemplar configuration to that for an RB960PGS (a.k.a. hEX PoE) configured as a smart switch.

In the interest of maximum clarity, I’ve stripped inessential details from the configuration as presented inline below. I’ve also left out everything related to IPsec and CAPsMAN as advanced topics not suited for coverage at this beginner’s tutorial level. For much the same reason, I didn’t bother covering the IPv6 firewall; those that need IPv6 support can add their knowledge of that protocol stack to the existing IPv4 coverage to extend the concepts. Where it aids the presentation’s logical order, I’ve reordered commands from the default.

The intent of this beginner-level tutorial is to get you oriented so that you can find everything else you need in the RouterOS docs. I have no intention of writing a complete replacement of that material here.

Product Naming

The formal name for the wired-only version of the router we’re using as our exemplar in this document is the RB4011iGS+RM. MikroTik’s product naming guide tells us how to break this name down into parts:

I’ve bothered to go into all of this for the benefit of those not familiar with the RB4011, because these details feed directly into the first parts of the default configuration.

Interface Lists

In this context, an “interface” is a fancy name for a network port on the device, of which there are eleven on the RB4011. There are many other interface types in RouterOS, but because the default configuration doesn’t define any of them, we needn’t be distracted by any of that here.

The first thing the default configuration does is define two interface lists:

/interface list add name=WAN
/interface list add name=LAN

This is characteristic of a border router, as opposed to a switch or a bridge: we have a WAN side and a LAN side, and the job is to shuttle packets selectively from one side to the other. It is possible to reconfigure an RB4011 as a smart switch or a media converter merely by bridging all required interfaces.

For simple configurations, only one port ends up in the WAN interface list:

/interface list member add list=WAN interface=ether1

Realize that this is a default only, wholly contingent on your local needs:

The value of named interface lists is that we don’t have to care exactly which interfaces are in that list, only what it logically does in our configuration.

The Bridge

RouterOS boxes with more than two ports have a default bridge configured:

/interface bridge
add name=bridge auto-mac=yes protocol-mode=rstp

The term “bridge” has multiple meanings in network engineering circles. Originally, it meant something akin to the architectural element: a device for connecting two networks in order to span an obstacle. A good many of these prototypical network bridges are media or protocol converters: WiFi to Ethernet bridges, power-line converters, etc. These devices learn about the LAN hosts connected to its ports and try to shuttle packets intelligently from one side to the other, tying those two networks together.

RouterOS devices can be configured as such, and indeed, a good many of MikroTik’s professional wireless products are of this type: radio on one side, Ethernet on the other. A “router” like the RB4011 can be turned into a bridge between copper Ethernet and optical fiber by ignoring the other nine ports.

The thing is, there is no technical restriction that limits a bridge to two ports. In RouterOS terms, a “bridge” more nearly approximates what we’d call an Ethernet switch in other contexts, except that it isn’t limited to Ethernet. You can have two RJ45 GigE ports, a 2.4 GHz WiFi interface, and an SFP+ fiber port in a bridge, and they’ll all intercommunicate through the magic of RouterOS bridging. If you put all of the device’s ports onto the bridge, then it essentially becomes what other vendors call a “smart switch.”

This is why RouterOS puts all non-WAN ports into a single “LAN” bridge:

/interface bridge
port add bridge=bridge interface=ether2
port add bridge=bridge interface=ether3
port add bridge=bridge interface=…
port add bridge=bridge interface=sfp-sfplus1

Most of the time, this is exactly what one wants: it allows all LAN devices to talk to each other directly at wire-speed without interference, while at the same time, the router’s software-defined rules dictate how packets get shuttled between LAN and WAN. Although it is this latter characteristic that defines a device as a router, realize that both characteristics apply to an RB4011 in its default configuration. On the LAN side, it is a smart Ethernet switch. If you move ether1 out of the WAN list and add it to bridge, an RB4011 becomes a pure smart switch, not a router at all.

Because a bridge acts as a type of logical interface, the default configuration is able to add it wholesale to the “LAN” interface list:

/interface list member add list=LAN interface=bridge

This abstraction lets it avoid naming each LAN-side interface redundantly, risking the two lists becoming desynchronized.

You may be wondering why I titled this section “The Bridge,” singular. Can you not have more than one bridge on a RouterOS device? Indeed, with certain network equipment vendors, multiple bridges are required to get certain things done. The fact is that while RouterOS does support multiple bridges, as a rule, you never want more than one per device because the switch chip underlying it generally cannot hardware-offload more than one bridge. There are exceptions, but pursuing them gets us well outside the mainstream set of use cases.

If you are trying to divide the ports on the device into two or more groups, you generally want to set up VLANs along with bridge VLAN filtering, not define multiple bridges at all.

All of this is why the default configuration puts the single WAN-side interface into an interface list directly, rather than put it into a WAN bridge first before adding the WAN bridge to the named “WAN” interface list.

Bridge MAC Address

Returning to the top of this section, we found this:

auto-mac=yes

A dumb Ethernet switch has only one MAC address, no matter how many ports it has, but because all RouterOS based devices are, at their core, routers — even the ones classed for technical reasons as “switches” — every port has its own MAC address. An eleven-port device like the RB4011 has eleven MAC addresses!

How, then, do protocols like ARP work? If each port has a separate MAC address and the set of ports on a given bridge is reconfigurable at will, does that mean our computer’s network stack gets a different answer when it asks for the next-hop’s MAC address via ARP, depending on which port we’re plugged into at the moment?

No. That would cause chaos in a number of areas. A few easy cases are:

There’s more, but because RouterOS doesn’t change its MAC depending on which of the bridge’s ports you’re plugged into, we have no need to go any further down that rabbit hole. What it does instead in auto-mac mode is pick one of the MACs on the bridge to be the one it presents to the outside world.

This is a sensible default, but realize that it can create difficulties in advanced setups. For one, the veth device you need to add to the bridge for the benefit of containers participates in this, potentially meaning that the automatic MAC address changes on each reboot. For such cases, you want to disable auto-mac mode and manually assign one of the per-port MAC addresses to the bridge.

Spanning Tree Protocol

There’s one final detail to cover, and it’s a bit of a doozy:

protocol-mode=rstp

The Spanning Tree Protocol family is complicated and powerful, but useful, which is why it’s enabled by default. You should read the linked article for details, but essentially what it does is detect connection loops on the network and automatically disable ports as needed to break those loops. Without some flavor of STP in effect, it’s possible to take down an entire network by plugging two ports together.

There are simpler alternatives, including RouterOS’s own loop protect feature, but it’s less powerful and proprietary besides. If you have a mixed-vendor network, STP is by far the superior solution. The only common alternative is to disable STP entirely, then make it a rule to never create a loop. That’s defensible if you’re in full control of your network and never make mistakes, but otherwise, I recommend that you keep STP enabled.

RSTP is the modern replacement for the original STP protocol, which has no justifications for use any more now that all of the STP-only devices have generally aged out of the environment.

That leaves the MSTP alternative, and the only reason for preferring that is certain VLAN configurations.

IP Addressing

The router gives itself a static LAN-side address with:

/ip address add address=192.168.88.1/24 interface=bridge

Because so much of consumer networking gear still uses dotted-quad netmasks, you may not be familiar with this “/24” notation. It means exactly the same thing as a netmask of 255.255.255.0, but in three characters instead of thirteen. RouterOS is pro-grade gear, meant for those who appreciate the compactness and clarity of this notation.4

For more on this, see the IP fundamentals guide in the RouterOS manual.

For now, notice that it applies its static IP address to the bridge, not to any particular LAN-side interface. This is part of the magic of bridging: it doesn’t matter which LAN-side port a given client’s request packet comes in on, the router will see those asking about 192.168.88.1 and respond.

DHCP Server

One of the defining characteristics of an Internet gateway router is that it typically offers DHCP service to the LAN-side hosts. RouterOS sets one up for you like so:

/ip pool add name="default-dhcp" ranges=192.168.88.10-192.168.88.254
/ip dhcp-server
add address-pool="default-dhcp" interface=bridge lease-time=10m
/ip dhcp-server network
add address=192.168.88.0/24 gateway=192.168.88.1 dns-server=192.168.88.1

As we saw above, the router takes the 192.168.88.1 address for itself. This configuration then reserves the other IPs with single-digit final octets for non-DHCP use. The rest of the addresses in the 192.168.88.0/24 range it hands out to LAN clients as needed.

Notice that the DHCP server is bound to “bridge,” not to “LAN” or individually to every LAN-side interface. It does this for the same reason the default configuration attaches the LAN-side static IP address to the bridge.

By the same token, the DHCP server will not respond to requests on the WAN port, because it isn’t on the bridge.5

RouterOS supports static DHCP reservations, a feature I find greatly helpful even on small LANs. Because the default configuration doesn’t set any of these up for you, I offer this example to spark ideas of your own:

/ip dhcp-server lease server=default-dhcp
add address=192.168.88.99 mac-address=11:22:33:44:55:66 comment="network printer"

Caching DNS

Along with a DHCP server, the router sets itself up as a caching DNS server:

/ip dns
set allow-remote-requests=yes
static add name=router.lan address=192.168.88.1

If you let the allow-remote-requests setting take its default value of no, the DNS server affects services running on the router itself only. This can be useful when you want local caching but also want the LAN devices to use some other DNS server. In that case, you’d adjust the DHCP server configuration above to hand out this alternate DNS server address to its clients.

Technically, this configuration means the DNS server listens on all ports, including the WAN. This would be dangerous if it were not for the firewall, which we will get to shortly.

The final line in the default configuration fragment quoted above assigns a DNS name for the router itself, allowing you to do things like put http://router.lan/ into a browser to connect to the router’s web configuration interface. I find great value in assigning logical names to LAN devices, particularly in conjunction with static DHCP reservations. To extend the “network printer” example above, we might say:

/ip dns static
add address=192.168.88.99 name=printer.lan
add cname=laser.lan name=printer type=CNAME

This gives our laser printer two logical names, “laser” and “printer”, either of which will resolve within the semi-standard “.lan” TLD used in this configuration.6

DHCP Client

Now that we’ve got the LAN side of things set up, we need to finish setting up the WAN side, which in the default configuration assumes is connected to someone else’s DHCP server, commonly used by modern ISPs for automatic IP configuration of their client networks:

/ip dhcp-client add interface=ether1

Recall that we set aside ether1 as the lone WAN port above. This tells RouterOS’s DHCP client to go and get a public IP from our ISP via that port.

Because we did not set “add-default-route=no”, this setting implicitly creates a dynamic route to the Internet based on the DHCP lease we get. If that worked, this RouterOS CLI command will show that route:

/ip route print

The result might look like this:

#     DST-ADDRESS          GATEWAY       DISTANCE
  DAc 198.51.100.0.4/24    ether1        0

The capital “D” at the start of the second line means it’s a dynamic route, added via DHCP in this case, as opposed to one defined statically in the RouterOS configuration. The “A” means the route is active, not disabled, and the “c” means the physical link toward the destination is connected, without which that route would be ignored.

The primary alternative to DHCP for doing this type of thing is PPPoE, commonly used with LTE and DSL networks.

Firewall

This section of the tutorial isn’t meant to replace the RouterOS manual’s Building Your First Firewall section. Our focus here is merely on explaining what the default firewall does, line-by-line. Recall above where we said we’re skipping coverage of advanced topics like IPsec and CAPsMAN; this explanation is incomplete on purpose, our interest here being to explain matters to a beginner’s level, just enough to get you started. This is a sufficiently deep topic that you can build an entire career on mastering this set of tools alone. We aren’t going to be able to do more than skim the surface of what’s possible here. Even restricting ourselves to explaining the default configuration is going to get deep enough that you’re gonna wanna go get your hip waders on.

Ready? Okay, here we go.

More than anything else, the single attribute that characterizes an Internet gateway router is the NAT firewall separating the LAN from the WAN side of the device. The RouterOS default firewall does this like so:

/ip firewall nat add chain=srcnat out-interface-list=WAN action=masquerade

Essentially, what this says is that when traffic from the LAN side tries to go out onto the WAN, the source IP address should be translated to the WAN-side (“public”) IP address, with whatever adjustments are needed to the port numbers to avoid conflicts and to disambiguate replies.7

Input Chain

The second rule in the default firewall begins…

/ip firewall filter add chain=input …

This begins a new “chain,” being a sequence of rules checked in order, from top to bottom. This is a common area where newbies get stuck or turned around. Briefly, the “input” chain is for connections to the router itself, while the “forward" chain is for traffic crossing the router. The prior section covered the sole rule in the “srcnat” chain, which is treated specially by the router, a fact that is easiest to see in the packet flow diagrams.8

We’re going to skip over this first input-chain rule for now, because it requires context to understand, while the second does not:

add chain=input action=drop connection-state=invalid

It suffices to say that if the packet is obviously bogus, drop it. The details of how the Linux kernel’s firewall makes that determination are too abstruse to get into here.

Next up is another easy one:

add chain=input action=accept protocol=icmp

The ICMP protocol is used for many things in IPv4. Most famous is the ping facility, which leads some people to mistakenly block ICMP in an attempt to hide themselves from other Internet users. This is a stupendously bad idea. Don’t do it. Take MikroTik’s lead on this and allow ICMP on both the LAN and WAN sides.

Next comes one of the key rules that defines this as an “Internet gateway router” configuration:

add chain=input action=drop in-interface-list=!LAN

This blocks everything coming into the router from the WAN side other than what we explicitly allowed above. It is what prevents random Internet hosts from:

…and so forth.

Any exceptions you want to add for public-facing network services need to be ahead of this “drop” rule to take effect. A prime example of this is port-forwarding.9

While you will note that this rule terminates the default “input” chain, that isn’t the end, since this rule doesn’t scoop up literally everything not explicitly allowed. Contrary to standard advice you will find in generic Linux firewall chain guides, the default action in RouterOS when falling off the end of a chain is “accept,” not “deny,” which is why the inverse of the “!LAN” exception made in the preceding “drop” rule allows everything else coming from the LAN side, including the WinBox connections we’ve been using to set our router up.10

This finally allows us to get back to the meaning of the first rule in the input chain:

add chain=input action=accept connection-state=established,related,untracked

It needs to be high up in the chain for it to take effect, but only now do we have the context we need to understand what it does: once a given connection has been classified, it causes everything else related to that established packet stream to bypass the firewall. It’s been vetted by all the prior rules, right? Let it through.

Forward Chain

Recall that the “forward” chain is for traffic being routed from one network to another. The first rule in this chain is:

/ip firewall filter
add chain=forward action=fasttrack-connection connection-state=established,related

Note the similarity to the rule at the top of the “input” chain. The main differences are in which traffic it applies to and the fact that it applies the FastTrack feature.

Not all RouterOS devices support fast-tracking, and it isn’t always wanted, but it’s a good default for a “router” class device when used as intended. Essentially, this rule says that once a decision has been made about a given TCP connection that the rest of the stream should flow through the router without continual re-checking of all the firewall rules. Without this rule, a good many routers in the MikroTik roundup wouldn’t be able to keep up with modern Internet speeds. You’d best have a strong reason if you think you should remove this rule.

One small but important difference between this and the otherwise similar rule at the start of the input chain is that this one does not allow “untracked” streams. A packet stream must be classified by another rule in order to be considered “tracked” under this definition, thus allowed to take the fast-track past the firewall. Without this, it would be possible to sneak packets past our firewall. That’s fine on the input side, but unacceptable across the routing boundary between the trusted LAN and the big bad Internet.

add chain=forward action=accept connection-state=established,related,untracked
add chain=forward action=drop connection-state=invalid

These rules have the same effect as the similar ones in the “input” chain above. The only difference is that this variant affects traffic crossing the router, not packets destined for the router itself.

The final rule completes the default NAT firewall configuration:

add chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface-list=WAN

This is the one that turns the router into a deny-by-default firewall on the WAN side, blocking everything we didn’t ask for by making an outbound connection from the LAN. Whereas the “chain=input action=drop” rule above affects attempts to connect to the router itself from the outside, this one prevents external attempts to traverse the router back into the LAN. There are exceptions that bypass this protection, but the default assumption is that you want the set of hacks collectively termed NAT traversal to occur.

Note that UPnP is disabled by default. This is because it is generally considered insecure and semi-obsolescent now, replaced not only by NAT traversal techniques, but also VPNs and widespread use of cloud services.

Management

The default configuration allows LAN-side management via WinBox only:

/ip neighbor discovery-settings set discover-interface-list=LAN
/tool mac-server set allowed-interface-list=LAN
/tool mac-server mac-winbox set allowed-interface-list=LAN

The first line allows WinBox to discover routers on the same network as itself. Next, it allows direct MAC connections from the LAN, which allows configuration while the router’s IP setup is broken or still being defined.

There are several other remote management service options available in RouterOS, all disabled by default.

Gating access to these services are the default user name and password, which with new hardware uses a random password included with the device on a label, insert card in the box, and/or a pull-out drawer:

/user set admin password=$defconfPassword
/user expire-password admin

You can reset the router to clear this default password, but I give a more sophisticated alternative at the end of my NetInstall article, which brings us full-circle with the topic of this tutorial.

Going Further

Now that you’ve seen the high-level overview of the default configuration, you may want to read the complete version produced by RouterOS 7.15.2, with naught but the most minor of edits.

Up one level from there you will find my archive of default configuration files, along with further details you may find interesting.

Conclusion

I hope this has been helpful.

License

This work is © 2024 by Warren Young and is licensed under CC BY-NC-SA 4.0

  1. ^ Products with more than one SFP+ port are named like “2S+”.
  2. ^ The RB750Gr3, for instance, a.k.a. the “hEX”.
  3. ^ It is likely to be the EtherBoot port, and it often does something uncommon with PoE.
  4. ^ This was once called Classless Inter-Domain Routing (CIDR) addressing, meant to distinguish it from the old “Class A” thru “Class E” scheme, but many tutorials now drop the distinction since class-based addressing hasn’t been anything but an obsolete historical convention for decades now.
  5. ^ Indeed, it’s a serious configuration error to put the WAN port into the bridge; it exposes your whole LAN naked to the Internet!
  6. ^ The default DHCP server configuration really should declare “domain=lan” for you so that host-name-only URLs like http://router/ work, but personally, I prefer to use the set-aside .home TLD for private home LANs. Someday when I’m feeling particularly pedantic, I might switch to using the RFC 8375 name .home.arpa instead.
  7. ^ Read up on masquerading in the manual for the main story. For the rest, realize that Source NAT isn’t always required, and when it is, there are alternatives to the so-called “masquerading” algorithm.
  8. ^ Specifically, at point 4B here.
  9. ^ Properly called destination NAT, a.k.a. dstnat.
  10. ^ If you’re tempted to object that you also want to allow remote administration of your router over the Internet, you almost certainly should set up a VPN of some kind instead, not allow direct WinBox or WebFig or SSH connections to the router itself. This isn’t the place to go into the “whys” of it all, so for now, please take it as a fact: exposing RouterOS’s remote administration features to the Internet is a seriously bad idea.