ARP Management

The Address Resolution Protocol (ARP) works at Open Systems Interconnection (OSI) Layer 2 and allows computers on a LAN to find the computer with a given IPv4 address so it can be sent traffic. In other words, if you are sitting at a computer and open a Telnet connection to a different machine in your LAN with IP address 192.168.90.55, it will cast an ARP request into the void asking, "Who has IP address 192.168.90.55?" Ideally, the target machine will send an ARP reply, "I have IP address 192.168.90.55," so that the connection can be established.

ARP is handy, but poses a security problem because anybody in the same LAN segment can reply that they have the requested address. In this way, an evil machine could send multiple ARP replies posing as the target machine and convince the originator of the connection to create a connection with it instead of the correct computer. This deceit is known as ARP spoofing [5] and is most known for such things as performing evil MITM attacks, although it does have some benevolent applications.

The easiest way to prevent ARP spoofing is to load static ARP tables to your devices. If your computer already knows which device has a certain IP, it won't need to issue an ARP query; therefore, it won't get and process a bogus response. Loading a static ARP table in a common Linux computer is easy enough (superuser privileges are required):

arp -s 192.168.90.55 00:0c:29:c1:91:b1

The last field of the command is the MAC address, which is the unique identifier of the network device to which the IP belongs.

However, most commercial routers don't have this capability. Fortunately, RouterOS allows you to introduce static ARP entries, so it won't be tricked into delivering traffic to the wrong devices:

/ip arp add address=192.168.90.55 mac-address=00:0C:29:C1:91:B1 interface=bridge1

Static ARP tables work by specifying beforehand which MAC address corresponds to a given IP. A MAC address is assigned to each network interface in your network, and you can often find it printed on a label on the physical device or on its box.

Establishing VPNs

Most consumers think of virtual private networks (VPNs) as privacy network services that route their connections through a third-party server so all their traffic appears to come from the VPN server instead of the originating machine. This approach is known to be used to download copyrighted material over BitTorrent, because it makes it seem like a different computer than yours is performing the deed. Although I suspect you can configure your MikroTik device to do this, I have not tested this, and it is definitively not the reason for which RouterOS was built.

MikroTik uses Internet Protocol Security (IPsec) as the reference VPN protocol, and the scenario on which the documentation focuses is the same that system administrators have most often in mind when they talk about VPN. The traditional use of VPNs is to join two LANs located in separate offices on the Internet over a secure channel in such a way that both places seem to be located on the same LAN (Figure 4). This setup allows a computer in one office to connect to a device in the other office (e.g., a printer) transparently over a secure connection. Often, VPN technology can be used by employees to connect to their workplace network from home or while on the road (Figure 5).

Figure 4: A VPN allows computers in a network to contact devices located in a separate office over a secure connection. Ludovic.ferre CC BY-SA 4.0 [6].

Figure 5: A VPN allows a smartphone with GrapheneOS (a privacy- and security-focused mobile OS) to connect directly to any machine (Test) located on a firewalled network over the Internet.

IPsec is not known for being easy to use. Luckily, since version 7, RouterOS supports the WireGuard protocol [7], which is regarded as easier to use. Despite some valid criticism [8], it has become very popular.

The usual way to join two LANs with WireGuard is to run a WireGuard-capable router on each LAN and configure both to establish a WireGuard tunnel to each other over the Internet. For example: if you have a LAN with devices that use network 192.168.101.0/24 and another with a LAN that uses 192.168.100.0/24, you would set the router of the first to direct any internal traffic to the second over a WireGuard-encrypted tunnel. This arrangement requires setting up a WireGuard virtual network interface in the first router and configuring it to establish a tunnel with its peer, then doing the same in the second router.

The steps in Listing 2 show how easy it is to set up a WireGuard node. The first line creates a WireGuard interface that listens on port 13231. The second line instructs this interface to accept peering with any node that displays the provided public key. The WireGuard interface will accept traffic from any machine from the LAN behind the peer node as long as the machine lives in network 192.168.100.0/24.

01 /interface/wireguard add listen-port=13231 name=wireguard1
02 /interface/wireguard/peers add allowed-address=192.168.100.0/24 endpoint-address=0.0.0.0 endpoint-port=13231 interface=wireguard1 public-key="$somepublickey="
03 /interface/list/member add interface=wireguard1 list=LAN
04 /ip/firewall/filter add chain=input action=accept protocol=udp in-interface=ether1 dst-port=13231 place-before=5

It might be a good idea to add the WireGuard interface to the LAN list, so the firewall allows traffic from the peer into your network. You can do this on line 3. Line 4 opens a port in your firewall so you can accept WireGuard traffic from peers.

MikroTik has some fine documentation [9] on setting up WireGuard, if you want to dive into the details.

Quality of Service

The most attractive feature MikroTik brings with RouterOS, at least for home users, is their QoS, which embodies the methods used to assign priorities to different sorts of traffic so that important connections get more bandwidth and less latency if bandwidth runs tight.

Because RouterOS is Linux based, QoS will be familiar to any administrator who has ever had QoS on a regular distribution. If terms such as token bucket filter (TBF), stochastic fair queuing (SFQ), and hierarchical token bucket (HTB) ring a bell, you will pick up advanced QoS in RouterOS in no time. If not, don't despair, because you can get a quick primer from the Arch Wiki [10]; moreover, RouterOS offers a simplified queue system for people who need to set QoS without undergoing intensive training.

Simplified QoS in RouterOS is implemented by Simple Queues . These are useful if you have multiple computers on your LAN and you want to group them in such a way that a given group does not use more upload or download bandwidth than they should. In this example ruleset, different groups of computers are assigned limits, as you would introduce with the SSH management interface:

/queue simple> add name=doctor target=192.168.90.211 max-limit=0/0
/queue simple> add name=students target=192.168.90.0/24 max-limit=256K/512K

A rule called doctor sets unlimited available bandwidth for the computer at address 192.168.90.211 (0/0 is understood as unlimited). Next, a rule called students ensures that every computer in network 192.168.90.0/24 is placed in a queue with an upload limit of 256Kbps and download limit of 512Kbps, so all the traffic from that network segment combined will not exceed such values. Keep in mind that Simple Queues are evaluated from top to bottom and that, once a rule is matched, it is not evaluated against any of the rules that follow, so the doctor's computer will never end up in the student queue, even if it belongs to the same network.

RouterOS supports static DHCP leases, so you can configure your router always to assign the same IP address to the doctor's computer, which is simpler than asking for the doctor's computer so you can set a static IP. In fact, the DHCP management interface allows you to define Simple Queues directly if you prefer. Listing 3 shows an example in which a static DHCP entry is set for the doctor and a static DHCP entry is configured for a different computer while creating a Simple Queue on top of the ruleset that limits its traffic to 1Mbps upload and 2Mbps download.

/ip dhcp-server lease add address=192.168.90.211 mac-address=b6:c2:55:41:01:01
/ip dhcp-server lease add address=192.168.90.212 mac-address=b6:c2:55:41:02:02 rate-limit=1M/2M insert-queue-before=first

Traffic can also be assigned to queues by the packet filter because the Simple Queue rules can be matched against packets carrying specific marks. This way, you could use the Firewall to mark packets that come from a certain source or target a certain port and then use a Simple Queue to limit the bandwidth. This example is useful, say, if you want to mark all the traffic going to well-known ports as unlimited and then put restrictions on everything else. If you intend to use this option, make sure you use the prerouting mangle chain in the packet filter to ensure packets are marked before they reach the Simple Queue engine.

Traffic that reaches a fasttrack rule in the firewall ruleset is not passed over to the queues, so if you intend to use them, you'd better disable fasttrack rules in the packet filter.

Simple Queues are fine for most home uses, but if you need more flexibility, you can always use Queue Trees to access the full power of the Linux traffic-shaping framework [11].