Tips and Tricks for Beginners and Experienced Users of RouterOS
This page contains various tips and tricks for RouterOS users, both beginners and experienced ones. Each subject depends on RouterOS version and might change from one version to another.
Note: This article is work in progress
First steps of debugging and how to contact MikroTik support team
Very often major problems on network can be resolved in easy way. There is a presentation which shows simple first debugging steps and explains how to contact MikroTik support team if you have not managed to fix your problem by yourself.
Firewall
Basic router protection based on connection state and IP address type by using Firewall
It is necessary to have proper firewall configuration on your routers to avoid different attacks and incorrectly formatted connections.
To do so, you can apply configuration (which of course should be modified for each users individual needs) which is show on example (written on 6.34.3 RouterOS),
In example WAN is gateway to internet, LAN is local interface and 192.168.88.0/24 is subnet used on LAN.
Create address list which includes different subnets (basically all subnets which should not exist in public network):
/ip firewall address-list add address=0.0.0.0/8 comment=RFC6890 list=NotPublic add address=10.0.0.0/8 comment=RFC6890 list=NotPublic add address=100.64.0.0/10 comment=RFC6890 list=NotPublic add address=127.0.0.0/8 comment=RFC6890 list=NotPublic add address=169.254.0.0/16 comment=RFC6890 list=NotPublic add address=172.16.0.0/12 comment=RFC6890 list=NotPublic add address=192.0.0.0/24 comment=RFC6890 list=NotPublic add address=192.0.2.0/24 comment=RFC6890 list=NotPublic add address=192.168.0.0/16 comment=RFC6890 list=NotPublic add address=192.88.99.0/24 comment=RFC3068 list=NotPublic add address=198.18.0.0/15 comment=RFC6890 list=NotPublic add address=198.51.100.0/24 comment=RFC6890 list=NotPublic add address=203.0.113.0/24 comment=RFC6890 list=NotPublic add address=224.0.0.0/4 comment=RFC4601 list=NotPublic add address=240.0.0.0/4 comment=RFC6890 list=NotPublic
Create firewall filter rules to protect router from incoming (input) connections:
/ip firewall filter add chain=input comment="Accept established and related packets" connection-state=established,related add chain=input comment="Accept all connections from local network" in-interface=LAN add action=drop chain=input comment="Drop invalid packets" connection-state=invalid add action=drop chain=input comment="Drop all packets which are not destined to routes IP address" dst-address-type=!local add action=drop chain=input comment="Drop all packets which does not have unicast source IP address" src-address-type=!unicast add action=drop chain=input comment="Drop all packets from public internet which should not exist in public network" in-interface=WAN src-address-list=NotPublic
Create firewall filter rules to protect your local network from passing (forwards) connections:
/ip firewall filter add chain=forward comment="Accept established and related packets" connection-state=established,related add action=drop chain=forward comment="Drop invalid packets" connection-state=invalid add action=drop chain=forward comment="Drop new connections from internet which are not dst-natted" connection-nat-state=!dstnat connection-state=new in-interface=WAN add action=drop chain=forward comment="Drop all packets from public internet which should not exist in public network" in-interface=WAN src-address-list=NotPublic add action=drop chain=forward comment="Drop all packets from local network to internet which should not exist in public network" dst-address-list=NotPublic in-interface=LAN add action=drop chain=forward comment="Drop all packets in local network which does not have local network address" in-interface=LAN src-address=!192.168.88.0/24
Block specific domains by using scripts
At the moment, it is not possible to block access for the specific domain on RouterOS. The only way to do it is to know IP addresses used by the domain and blocking them by using the firewall. The idea is - find out addresses, add them to address list and drop packets destined for these addresses. Since addresses usually are dynamic, you have to refresh them periodically. For such purposes, there is a script which will implement needed configuration. All you need to do is create scheduler which refreshes these addresses from time to time.
Example show how to block access to facebook.com and youtube.com (written on 6.34.3 RouterOS):
#Script to add IP addresses for specific domains to address lists
{
#Array of desired domain names
foreach iplist in=("youtube","facebook") do={
{
#Old entries are deleted
/ip firewall address-list remove [find where list=$iplist]
#Dummy variable to not get into loop
global counter true
#Check if IP addresses are not repeating themselves
while ($counter) do={
#Resolve domain
local ip [/resolve ("www.".$iplist.".com")]
#Add IP to address list under specific domain list if it does not already exist
if ([len [/ip firewall address-list find where address=$ip]] = 0) do={
/ip firewall address-list add address=$ip list=$iplist } else={
#If IP already exist in list then stop resolving this domain
set counter false
}
}
}
#If there is no firewall filter rules which blocks this specific domain then add it
if ([:len [/ip firewall filter find where chain=forward && dst-address-list=$iplist]] = 0) do={
/ip firewall filter add chain=forward action=drop dst-address-list=$iplist place-before=0 \
comment=("This rule blocks access to " . $iplist)
}
}
}
Note: This will work only with IPv4 traffic
Ease load on firewall by sorting firewall filter, NAT and mangle rules
When a packet travels through the firewall it is checked against each rule until it matches one (except when passthrough action is used). It means that CPU load and packet processing speed depends on it. There is a very simple way how to ease the load on firewall filter, NAT and mangle rules - sorting. Based on the action, without breaking logical order, you should sort your firewall rules by checking packet count on statistics for each independent rule. Move rules which have more packets matched up and those who have been matched more rarely move down. Remember that you always have to be sure that logical order of rules is not affected by this sorting.
Ease load on firewall by using no-mark as a mark for packets, connections and routing
When a packet travels through the firewall it is checked against each rule until it matches one (except when passthrough action is used). If you use rules which have action mark-packet, mark-connection and mark-routing, then it is worth to set additional matcher as no-mark for the related parameter. It will allow for the firewall to decide sooner if the packet matches this rule and also will allow for you to avoid re-marking.
Example script which should configure router as explained before (written on 6.34.3 RouterOS):
foreach mrk in=("packet","connection","routing") do={
{
foreach i in=([/ip firewall mangle find where action=("mark-" . $mrk)]) do={
local cmd ("ip firewall mangle set " . $i . " " . $mrk . "-mark=no-mark")
:execute $cmd
}
}
}
Protect local network against attacks from public internet
Very often people use default configuration on their routers. That also means, that it is possible to guess which local address is used behind router. Usually it is 192.168.88.0/24 for devices which runs on RouterOS. This means, that in public network attacker can create simple route which says that 192.168.88.0/24 is behind your public IP and attack to your local network devices.
To protect your local subnet against these attacks very simple firewall filter rule can be used. This rule will drop all packets which are destined to local network but are not NATted. NATted connections are allowed because NAT is there for exactly this purpose - to allow/redirect access from public internet to local address.
Example script which should configure router as explained before (written on 6.34.3 RouterOS):
/ip firewall filter add action=drop chain=forward comment="Drop new connections from internet which are not dst-natted" connection-nat-state=!dstnat connection-state=new in-interface=WAN
Specify corresponding interface for firewall NAT rules
Very often you can see configurations where many firewall NAT rules are being used. Once you make one rule the whole principle is clear and you can easily add many of them. Quite often RouterOS users forget about interface parameter on these rules. Rules can work correctly without them but they also can turn out to be a cause of many different kinds of problems, for example, loops, lost access to internet and etc.
To avoid problems like these you have to always specify out-interface parameter for srcnat NAT rules and in-interface parameter for dstnat NAT rules. If you need to specify multiple interfaces, then you need to have multiple NAT rules. This all will also reduce load on CPU.
Wrong example (written on 6.34.3 RouterOS):
/ip firewall nat add action=masquerade chain=srcnat src-address=192.168.88.0/24 add chain=dstnat dst-port=1234 action=dst-nat protocol=tcp to-address=192.168.88.2 to-port=80
Correct example (written on 6.34.3 RouterOS):
/ip firewall nat add action=masquerade chain=srcnat src-address=192.168.88.0/24 out-interface=WAN add chain=dstnat dst-port=1234 action=dst-nat protocol=tcp to-address=192.168.88.2 to-port=80 in-interface=WAN
General
Global variable is not working in script
In RouterOS there are many things which can be done by using scripts. Scripts and variables can be used in various places. Very often, for example, in Netwatch people define global variable and afterwards try to use it also in System/Scripts. Usually it does not work, because in very beginning of script you have to remember to define this variable by using command:
:global variable_name
If something does not work, then maybe it is like that on purpose
RouterOS has a feature called FastTrack. It makes connections even faster if it is enabled and correctly configured. When FastTrack is enabled, the traffic will bypass queues, firewall and other RouterOS features. When using FastTrack make sure that it is configured properly and does not interfere with other configuration. For more info see Manual:Wiki/Fasttrack page.
Note: As of RouterOS version 6.34.3 FastTrack only works with UDP/TCP IPv4 traffic. In most cases the configuration can be easily tested by using ping. If ping works and TCP/UDP does not, then it is very likely that FastTrack is enabled for this traffic.
Make sure that interface names are correct
Quite often after using different kinds of scripts or for any other reason interfaces on the router are renamed. If you are trying to configure something on the interface and it does not work as expected, make sure that you are trying to configure correct one.
Example command which should show correct interface names (written on 6.34.3 RouterOS):
[admin@MikroTik] > interface export /interface ethernet set [ find default-name=ether3 ] name=ether1 set [ find default-name=ether1 ] name=ether3
Myth about the reboot
Very often people say that problem disappeared after the reboot. In most cases it actually is not true. Reboot does many things, for example, clears DNS cache, clears different dynamic entries and so on. If the reboot helped in your case, you should think what on your device is configured and what of it is cleared by the reboot. Then you can try to trace the real reason.
PPP
Create static bindings for PPP interfaces
If you do not like that your PPP interfaces are dynamic, then you can on PPP profile execute the on-up script which creates static server binding for each client.
Example is made for PPPoE interfaces, but it can be easily adjusted for any other PPP interface types (written on 6.34.3 RouterOS):
if ([/interface pppoe-server print count-only where user=$user && !dynamic] = 0) do={
log info message=($user . " - is being added as static binding")
/interface pppoe-server add name=$user user=$user service=service1
/ppp active remove [find where name=$user]
}
Note: Last command within script will disconnect client at first time authentication
Queues
Limits specified on parent Simple Queue are not working
In RouterOS if you have Simple Queues with child queues, then you have to remember that after a parent queue matches some kind of traffic the same traffic will be again checked by the child queues. It means that you have to cover an entire set of packets which are captured by the parent and there is an easy way to do it by using the copy of the parent as a child.
Example which shows how to correctly create a child Simple Queue (written on 6.34.3 RouterOS).
This is not correct because only packets with address 192.168.88.2 will be limited by queues:
/queue simple add max-limit=100M/100M name=GLOBAL target=192.168.88.0/24 add max-limit=10M/10M name=child1 parent=GLOBAL target=192.168.88.2/32
To fix this problem you have to add another child queue which would be a copy of the parent without specified limits:
/queue simple add max-limit=100M/100M name=GLOBAL target=192.168.88.0/24 add max-limit=10M/10M name=child1 parent=GLOBAL target=192.168.88.2/32 add name=child2 parent=GLOBAL target=192.168.88.0/24
Queue slows down router
In the RouterOS, each Simple Queue works on single CPU core.
Example which shows how to ease the load on Simple Queue on multi-core systems (written on 6.34.3 RouterOS).
This queue will work on single core and will not work as fast as it would be possible:
/queue simple add max-limit=100M/100M name=queue1 target=192.168.88.1/32,192.168.88.2/32
This queue will work on two CPU cores and will work better compared to previous queue (of course you have to be sure that limit is proper for you):
/queue simple add max-limit=50M/50M name=queue2 target=192.168.88.1/32 add max-limit=50M/50M name=queue3 target=192.168.88.2/32
[ Top | Back to Content ]