Firewall Filters

Document revision:1.10 (Sun Dec 05 12:41:37 GMT 2004)
Applies to: V2.8

General Information


The firewall implements packet filtering and thereby provides security functions that are used to manage data flow to, from and through the router. Along with the Network Address Translation it serve as a tool for preventing unauthorized access to directly attached networks and the router itself as well as a filter for outgoing traffic.

Quick Setup Guide


Packages required: system
License required: Level1 (P2P filters limited to 1) , Level3
Submenu level: /ip firewall
Standards and Technologies: IP
Hardware usage: Increases with filtering rules count

Related Documents


Network firewalls keep outside threats away from sensitive data available inside the network. Whenever different networks are joined together, there is always a threat that someone from outside of your network will break into your LAN. Such break-ins may result in private data being stolen and distributed, valuable data being altered or destroyed, or entire hard drives being erased. Firewalls are used as a means of preventing or minimizing the security risks inherent in connecting to other networks. MikroTik RouterOS implements wide firewalling features as well as masquerading capabilities, which allows you to hide your network infrastructure from the outside world.

Packet Flow


MikroTik RouterOS simplifies the creation and deployment of sophisticated firewall policies. In fact, you can easily create a simple one to filter your traffic or enable source NAT without need to know how packets are processed in the router. But in case you want to deploy more complicated policies, it is worth to know the underlying process details. IP packet flow through the router is depicted in the following diagram:

IP Packet Flow

As we can see, a packet can enter the conveyer in two ways: whether the packet has come from an interface or whether it has been originated by the router. Analogically, a packet has two ways to leave the conveyer: through an outgoing interface or, in case the packet is locally destined, in the local process.

When the packet arrives to the router's interface, firewall rules are applied in the following order:

Additional arrows from IPsec boxes shows the processing of encrypted packets (they need to be encrypted / decrypted first and then processed as usual, id est from the point an ordinal packet enters the router).

If the packet is bridged one, the 'Routing Decision' changes to 'Bridge Forwarding Decision'. In case the bridge is forwarding non-IP packets, all things regarding IP protocol are not applicable ('Universal Client', 'Conntrack', 'Mangle', et cetera).

Firewall Rules

Submenu level: /ip firewall rule <chain name>


A rule is an expression in a definite form that tells the router what to do with a particular packet. The rule consists of two logical parts: the matcher set and the action set. For each packet you need to define a rule with appropriate match and action.

Management of the firewall rules can be accessed by selecting the desired chain. If you use the WinBox console, select the desired chain and then press the List button on the toolbar to open the window with the rules.

Peer-to-Peer Traffic Filtering

MikroTik RouterOS provides a way to filter traffic from most popular peer-to-peer programs that uses different P2P protocols.


In order to protect your router and attached private networks, you need to configure firewall to drop or reject most of ICMP traffic. However, some ICMP packets are vital to maintain network reliability or provide troubleshooting services.

The following is a list of ICMP TYPE:CODE values found in good packets. It is generally suggested to allow these types of ICMP traffic.

General suggestion to apply ICMP filtering

Type of Service

Internet paths vary in quality of service they provide. They can differ in cost, reliability, delay and throughput. This situation imposes some tradeoffs, exempli gratia the path with the lowest delay may be among the slowest. Therefore, the "optimal" path for a packet to follow through the Internet may depend on the needs of the application and its user.

Because the network itself has no knowledge on how to optimize path choosing for a particular application or user, the IP protocol provides a facility for upper layer protocols to convey hints to the Internet Layer about how the tradeoffs should be made for the particular packet. This facility is called the "Type of Service" facility.

The fundamental rule is that if a host makes appropriate use of the TOS facility, its network service should be at least as good as it would have been if the host had not used this facility.

Type of Service (ToS) is a standard field of IP packet and it is used by many network applications and hardware to specify how the traffic should be treated by the gateway.

MikroTik RouterOS works with the full ToS byte. It does not take account of reserverd bits in this byte (because they have been redefined many times and this approach provides more flexibility). It means that it is possible to work with DiffServ marks (Differentiated Services Codepoint, DSCP as defined in RFC2474) and ECN codepoints (Explicit Congestion Notification, ECN as defined in RFC3168), which are using the same field in IP protocol header. Note that it does not mean that RouterOS supports DiffServ or ECN, it is just possible to access and change the marks used by these protocols.

RFC1349 defines these standard values:

Property Description

action (accept | drop | jump | passthrough | reject | return; default: accept) - action to undertake if the packet matches the rule, one of the:
accept - accept the packet. No action, i.e., the packet is passed through without undertaking any action, except for mangle, and no more rules are processed in the relevant list/chain
drop - silently drop the packet (without sending the ICMP reject message)
jump - jump to the chain specified by the value of the jump-target argument
passthrough - ignore this rule, except for mangle, go on to the next one. Acts the same way as a disabled rule, except for ability to count and mangle packets
reject - reject the packet and send an ICMP reject message
return - return to the previous chain, from where the jump took place

comment (text; default: "") - a descriptive comment for the rule

connection (text; default: "") - connection mark to match. Only connections (including related) marked in the MANGLE would be matched

connection-limit (integer; default: 0) - match the number of concurrent connections from each particular IP address

connection-state (any | established | invalid | new | related; default: any) - connection state

content (text; default: "") - the text packets should contain in order to match the rule

disabled (yes | no; default: no) - specifies whether the rule is disabled or not

dst-address (IP address mask:port; default: - destination IP address

dst-netmask (IP address) - destination netmask in decimal form x.x.x.x

dst-port (integer: 0..65535) - destination port number or range
0 - all ports 1-65535

flow (text) - flow mark to match. Only packets marked in the MANGLE would be matched

icmp-options (integer; default: any:any) - matches ICMP Type:Code fields

in-interface (name; default: all) - interface the packet has entered the router through.
all - may include the local loopback interface for packets originated from the router

jump-target (name) - name of the target chain, if the action=jump is used

limit-burst (integer; default: 0) - allowed burst regarding the limit-count/limit-time, measuret in bits/s

limit-count (integer; default: 0) - how many times to use the rule during the limit-time period

limit-time (time; default: 0) - time interval measured in seconds, used in conjunction with limit-count
0 - forever

log (yes | no; default: no) - specifies to log the action or not

out-interface (name; default: name) - interface the packet is leaving the router from
all - may include the local loopback interface for packets with destination to the router

p2p (any | all-p2p | bit-torrent | direct-connect | fasttrack | soulseek | blubster | edonkey | gnutella | warez; default: any) - match Peer-to-Peer (P2P) connections:
all-p2p - match all known P2P traffic
any - match any packet (i.e., do not check this property)

protocol (ah | egp | ggp | icmp | ipencap | ospf | rspf | udp | xtp | all | encap | gre | idpr-cmtp | ipip | pup | st | vmtp | ddp | esp | hmp | igmp | iso-tp4 | rdp | tcp | xns-idp; default: all) - protocol setting
all - cannot be used, if you want to specify ports

src-address (IP address mask:port; default: - source IP address

src-mac-address (MAC address; default: 00:00:00:00:00:00) - host's MAC address the packet has been received from

src-netmask (IP address) - source netmask in decimal form x.x.x.x

src-port (integer: 0..65535) - source port number or range (0-65535)
0 - all ports 1-65535

tcp-options (any | syn-only | non-syn-only; default: any) - TCP options

tos (<integer> | dont-change | low-cost | low-delay | max-reliability | max-throughput | normal | anyinteger; default: any) - specifies a match to the value of Type of Service (ToS) field of IP header:
any - match any packet (i.e., do not check this property)


Keep in mind, that protocol must be explicity specified, if you want to select port.


For instance, we want to reject packets with dst-port=8080:

/ip firewall rule input add dst-port=8080 protocol=tcp action=reject
[admin@MikroTik] ip firewall rule input> print
Flags: X - disabled, I - invalid
  0   src-address= in-interface=all
      dst-address= out-interface=all protocol=tcp
      icmp-options=any:any tcp-options=any connection-state=any flow=""
      sconnection="" content="" rc-mac-address=00:00:00:00:00:00 limit-count=0
      limit-burst=0 limit-time=0s action=reject log=no

To allow not more than 4 concurrent connection from each particular IP address, you can use this rule:

/ip firewall rule forward add protocol=tcp tcp-options=syn-only connection-limit=5 \

Firewall Chains

Submenu level: /ip firewall


The firewall filtering rules are grouped together in chains. It allows a packets to be matched against one common criterion in one chain, and then passed over for processing against some other common criteria to another chain. Let us assume that, for example, packets must be matched against the IP addresses and ports. Then matching against the IP addresses can be done in one chain without specifying the protocol ports. Matching against the protocol ports can be done in a separate chain without specifying the IP addresses.

There are three predefined chains, which cannot be deleted:

When processing a chain, rules are taken from the chain in the order they are listed there from top to bottom. If a packet matches the criteria of the rule, then the specified action is performed on it, and no more rules are processed in that chain. If the packet has not matched any rule within the chain, then the default policy action of the chain is performed.

Available default policy actions include:

Usually packets should be matched against several criteria. More general filtering rules can be grouped together in a separate chain. To process the rules of additional chains, the jump action should be used with destination to this chain from a rule within another chain.

The policy of user added chains is none, and it cannot be changed. Chains cannot be removed, if they contain rules (are not empty).


Because the NAT rules are applied first, it is important to hold this in mind when setting up firewall rules, since the original packets might be already modified by the NAT.

The packets passing through the router are not processed against the rules of neither the input, nor output chains.

Be careful about changing the default policy action to input and output chains! You may lose the connection to the router, if you change the policy to drop, and there are no additional rules that allow connection to the router.


[admin@MikroTik] ip firewall> print
  # NAME                                                                 POLICY
  0 input                                                                accept
  1 forward                                                              accept
  2 output                                                               accept
[admin@MikroTik] ip firewall> add name=router
[admin@MikroTik] ip firewall> print
  # NAME                                                                 POLICY
  0 input                                                                accept
  1 forward                                                              accept
  2 output                                                               accept
  3 router                                                               none

IP Firewall Applications


In this section some IP firewalling common applications and examples of them are discussed.

Basic Firewall Building Principles

Assume we have a router that connects a customer's network to the Internet. The basic firewall building principles can be grouped as follows:

Filtering has some impact on the router's performance. To minimize it, the filtering rules that match packets for established connections should be placed on top of the chain. These are TCP packets with options non-syn-only.

Examples of setting up firewalls are discussed below.

Example of Firewall Filters

Assume we want to create a firewall that:

The basic network setup is illustraded in the following diagram:

The IP addresses and routes of the MikroTik router are as follows:

[admin@MikroTik] ip address> print
Flags: X - disabled, I - invalid, D - dynamic
  #   ADDRESS            NETWORK         BROADCAST       INTERFACE
  0      Public
  1   Local
[admin@MikroTik] ip route> print
Flags: X - disabled, I - invalid, D - dynamic, J - rejected,
C - connect, S - static, R - rip, O - ospf, B - bgp
    0  S          r      1        Public
    1 DC     r         0        Local
    2 DC        r         0        Public

To protect the router from unauthorized access, we should filter out all packets with the destination addresses of the router, and accept only those which are allowed. Since all packets with destination to the router's address are processed against the input chain, we can add the following rules to it:

/ip firewall rule input 
add connection-state=invalid action=drop \
    comment="Drop invalid connection packets"
add connection-state=established \
    comment="Allow established connections"
add connection-state=related \
    comment="Allow related connections"
add protocol=udp comment="Allow UDP connections"
add protocol=icmp comment="Allow ICMP messages"
add src-addr= \
    comment="Allow access from 'trusted' network"
add action=drop log=yes \
    comment="Reject and log everything else"

Thus, the input chain will accept only allowed connections and drop, and log everything else.

Protecting the Customer's Network

To protect the customer's network, we should match all packets with destination address that are passing through the router. This can be done in the forward chain. We can match the packets against the IP addresses in the forward chain, and then jump to another chain, say, customer. We create the new chain and add rules to it:

/ip firewall add name=customer
/ip firewall rule customer 
add connection-state=invalid action=drop \
    comment="Drop invalid connection packets"
add connection-state=established \
    comment="Allow established connections"
add connection-state=related \
    comment="Allow related connections"
add protocol=udp \
    comment="Allow UDP connections"
add protocol=icmp \
    comment="Allow ICMP messages"
add protocol=tcp dst-address= \
    comment="Allow http connections to the server at"
add protocol=tcp dst-address= \
    comment="Allow SMTP connections to the server at"
add action=drop log=yes comment="Drop and log everything else"

All we have to do now is to put rules in the forward chain, that match the IP addresses of the customer's hosts on the Local interface and jump to the customer chain:

/ip firewall rule forward
add out-interface=Local action=jump \

Thus, everything that passes the router and leaves the Local interface (destination of the customer's network) will be processed against the firewall rules of the customer chain.

Enforcing the 'Internet Policy'

To force the customer's hosts to access the Internet only through the proxy server at, we should put following rules in the forward chain:

/ip firewall rule forward
add connection-state=invalid action=drop \
    comment="Drop invalid connection packets"
add connection-state=established \
    comment="Allow established connections"
add connection-state=related \
    comment="Allow related connections"
add protocol=icmp out-interface=Public \
    comment="Allow ICMP ping packets"
add src-address= out-interface=Public \
    comment="Allow outgoing connections from the server at"
add action=drop out-interface=Public log=yes \
    comment="Drop and log everything else"

Example of Source NAT (Masquerading)

If you want to "hide" the private LAN "behind" one address given to you by the ISP (see the network diagram in the Application Example above), you should use the source network address translation (masquerading) feature of the MikroTik router. The masquerading will change the source IP address and port of the packets originated from the network to the address of the router when the packet is routed through it.

To use masquerading, a source NAT rule with action 'masquerade' should be added to the firewall configuration:

/ip firewall src-nat action=masquerade out-interface=Public

All outgoing connections from the network will have source address of the router and source port above 1024. No access from the Internet will be possible to the Local addresses. If you want to allow connections to the server on the local network, you should use destination Network Address Translation (NAT).

Example of Destination NAT

Assume you need to configure the MikroTik router for the following network setup, where the server is located in the private network area:

The server has address, and we are running web server on it that listens to the TCP port 80. We want to make it accessible from the Internet at address:port This can be done by means of destination Network Address Translation (NAT) at the MikroTik Router. The Public address:port will be translated to the Local address:port One destination NAT rule is required for translating the destination address and port:

/ip firewall dst-nat add action=nat protocol=tcp \
    dst-address= to-dst-address=