View source for How to configure a home router

==The CLI==
Winbox is a fantastic program. It is extremely powerful, and is a very quick way to edit or monitor RouterOS routers. It is, however, also a fairly poor tool for sharing configuration across the Internet. You can take screenshots, but screenshots are large files and might not display right. Depending on where they are hosted they might not stay around for very long as the file host takes them down. Most importantly there simply isn't enough space in most Winbox dialogs to show all the relevant information in one small area. Firewall rules in Winbox, for example, consist of many tabs. To adequately show all properties of a rule - when troubleshooting it, for example - you'd have to share one screenshot for each tab. CLI output, on the other hand, shows all that information in just one line. Text is also universal - everything can display text. You can also copy and paste text, which means it's much easier to apply a firewall rule that someone gave you as a CLI command than it is to click through all the tabs in Winbox and set all the fields accordingly.

The CLI may initially seem somewhat daunting but actuallt organized very well. There are only 9 different commands that really are important for basic configuration tasks.
===Structure===
The RouterOS CLI mirrors the GUI (or rather, the GUI mirrors the CLI). The configuration is divided into menu structures, several levels deep. For example, IP services are configured under "/ip" with subsections for the specific related tasks: ARP is configured under "/ip arp", the firewall is configured under "/ip firewall", and so on.

All commands can be prefaced with an absolute or relative reference to the context in which the command is to be executed. If no context is given, the current context is used. Below three examples:
<pre>
[admin@Example-Router] /ip address> print
</pre>
This "print" command will be executed in the "/ip address" context, and will therefore print all configured IP addresses.
<pre>
[admin@Example-Router] /ip address> /ip arp print
</pre>
This "print" command is prefaced with an absolute context of "/ip arp" and will be executed in that context, and will therefore print all ARP entries the router knows about.
<pre>
[admin@Example-Router] /ip address> .. arp print
</pre>
This "print" command is prefaced with a relative context of ".. arp". The current context is "/ip address", ".." goes one level up to "/ip", and "arp" goes into "/ip arp". Therefore the command will print all ARP entries the router knows about.

The <tab> key triggers auto completion, if the current word cannot be auto completed because several possibilities exist pressing <tab> a second time shows all possible completions. '?' shows help for existing options at the current position of the command. 

Commands are syntax highlighted - command words are pink, items are cyan, and parameter names are green. When syntax highlighting stops the OS cannot parse the command, and the command will not execute properly.

Commands can be abbreviated when they are unambiguous. For example, "/ip address add address=1.1.1.2/24 interface=WAN" can - at an extreme - be abbreviated as "/ip ad a a=1.1.1/24 i=WAN".

Parameters are passed as key/value pairs separated by '=' signs. In the example above the address parameter is set to 1.1.1.2/24, and the interface parameter is set to the interface named "WAN".

There are two different types of configuration: one simply exists and has parameters set on it (e.g., the internal DNS server can be turned on or off), others are items added to a section as instances in a list of items in the same context (e.g., VLAN interfaces that can be freely created, or IP addresses assigned to interfaces).

For purposes of displaying commands it is possible to split one very long line over several lines. This is indicated by a backslash at the end of a line - the next line continues that line. Here an example:
<pre>
[admin@Example-Router] > /ip address add \
   interface=outside \
   address=1.1.1.2/30
</pre>
This is used in this tutorial to wrap long configuration commands.

===Basic commands===
The same basic commands are used to configure all aspects of the OS. Commands exist to look at configuration, to add configuration, to remove configuration, and to edit existing configuration.
====print====
The "print" command prints configuration items in the current context. It has several qualifiers that can be used to change what information is output, and how it is formatted. The most important qualifier is "print detail". "print detail"'" shows all properties of an item, ensures that everything gets printed ("print" by default shows everything neatly organized into rows and columns of a table, but may truncate strings to make them all fit on the screen), and outputs everything as neat key/value pairs. This is especially valuable when sharing information on the forums when asking for help.

<pre>
[admin@Example-Router] > /ip arp print
Flags: X - disabled, I - invalid, H - DHCP, D - dynamic
 #   ADDRESS         MAC-ADDRESS       INTERFACE
 0 D 1.1.1.2         00:0B:BF:93:68:1B outside
[admin@Example-Router] >

[admin@Example-Router] > /ip arp print detail
Flags: X - disabled, I - invalid, H - DHCP, D - dynamic
 0 D address=1.1.1.2 mac-address=00:0B:BF:93:68:1B interface=outside
[admin@Example-Router] >
</pre>

The print command in its first column returns an item number. In subsequent commands the item number can be used to refer to that item.

====export====
The "export" command prints the configuration applied in a format that can be copied and pasted to duplicate the same configuration on another router. The "export" command will return the configuration of the current section, and all child sections. For example, the "/ip firewall" context has child contexts for NAT and filters. "/ip firewall export" would return those child section configurations as well.
====remove====
The "remove" command deletes an item from a list of configuration items. It refers to an item number, or the result of a "find" command.
<pre>
[admin@Example-Router] > /ip address print
Flags: X - disabled, I - invalid, D - dynamic
 #   ADDRESS            NETWORK         BROADCAST       INTERFACE
 0   10.1.0.1/24        10.1.0.0        10.1.0.255      inside
 1   1.1.1.2/29         1.1.1.0         1.1.1.7         outside
 2   10.2.0.1/24        10.2.0.0        10.2.0.255      dmz
[admin@Example-Router] > /ip address remove 2
[admin@Example-Router] > /ip address print
Flags: X - disabled, I - invalid, D - dynamic
 #   ADDRESS            NETWORK         BROADCAST       INTERFACE
 0   10.1.0.1/24        10.1.0.0        10.1.0.255      inside
 1   1.1.1.2/29         1.1.1.0         1.1.1.7         outside
[admin@Example-Router] >
</pre>
====add====
The "add" command adds an item to a list of configuration items. It will ask for all parameters that are required but not specified.
<pre>
[admin@Example-Router] > /ip address print
Flags: X - disabled, I - invalid, D - dynamic
 #   ADDRESS            NETWORK         BROADCAST       INTERFACE
 0   10.1.0.1/24        10.1.0.0        10.1.0.255      inside
 1   1.1.1.2/29         1.1.1.0         1.1.1.7         outside
[admin@Example-Router] > /ip address add address=10.2.0.1/24 interface=dmz
[admin@Example-Router] > /ip address print                                      
Flags: X - disabled, I - invalid, D - dynamic
 #   ADDRESS            NETWORK         BROADCAST       INTERFACE
 0   10.1.0.1/24        10.1.0.0        10.1.0.255      inside
 1   1.1.1.2/29         1.1.1.0         1.1.1.7         outside
 2   10.2.0.1/24        10.2.0.0        10.2.0.255      dmz
[admin@Example-Router] >
</pre>
====set====
The "set" command edits parameters of an existing item.
<pre>
[admin@Example-Router] > /ip address print
Flags: X - disabled, I - invalid, D - dynamic
 #   ADDRESS            NETWORK         BROADCAST       INTERFACE
 0   10.1.0.1/24        10.1.0.0        10.1.0.255      inside
 1   1.1.1.2/29         1.1.1.0         1.1.1.7         outside
 2   10.2.0.1/24        10.2.0.0        10.2.0.255      dmz
[admin@Example-Router] > /ip address set 2 interface=inside
[admin@Example-Router] > /ip address print
Flags: X - disabled, I - invalid, D - dynamic
 #   ADDRESS            NETWORK         BROADCAST       INTERFACE
 0   10.1.0.1/24        10.1.0.0        10.1.0.255      inside
 1   1.1.1.2/29         1.1.1.0         1.1.1.7         outside
 2   10.2.0.1/24        10.2.0.0        10.2.0.255      inside
[admin@Example-Router] > /ip address set 2 interface=dmz
[admin@Example-Router] > /ip address print
Flags: X - disabled, I - invalid, D - dynamic
 #   ADDRESS            NETWORK         BROADCAST       INTERFACE
 0   10.1.0.1/24        10.1.0.0        10.1.0.255      inside
 1   1.1.1.2/29         1.1.1.0         1.1.1.7         outside
 2   10.2.0.1/24        10.2.0.0        10.2.0.255      dmz
[admin@Example-Router] >
</pre>
====disable====
The "disable" command disables a configuration item rendering it inoperative, but leaving it in the configuration.
<pre>
[admin@Example-Router] > /ip address print
Flags: X - disabled, I - invalid, D - dynamic
 #   ADDRESS            NETWORK         BROADCAST       INTERFACE
 0   10.1.0.1/24        10.1.0.0        10.1.0.255      inside
 1   1.1.1.2/29         1.1.1.0         1.1.1.7         outside
 2   10.2.0.1/24        10.2.0.0        10.2.0.255      dmz
[admin@Example-Router] > /ip address disable 2
[admin@Example-Router] > /ip address print
Flags: X - disabled, I - invalid, D - dynamic
 #   ADDRESS            NETWORK         BROADCAST       INTERFACE
 0   10.1.0.1/24        10.1.0.0        10.1.0.255      inside
 1   1.1.1.2/29         1.1.1.0         1.1.1.7         outside
 2 X 10.2.0.1/24        10.2.0.0        10.2.0.255      dmz
[admin@Example-Router] >
</pre>
====enable====
The "enable" command enables a previously disabled item.
<pre>
[admin@Example-Router] > /ip address print
Flags: X - disabled, I - invalid, D - dynamic
 #   ADDRESS            NETWORK         BROADCAST       INTERFACE
 0   10.1.0.1/24        10.1.0.0        10.1.0.255      inside
 1   1.1.1.2/29         1.1.1.0         1.1.1.7         outside
 2 X 10.2.0.1/24        10.2.0.0        10.2.0.255      dmz
[admin@Example-Router] > /ip address enable 2
[admin@Example-Router] > /ip address print
Flags: X - disabled, I - invalid, D - dynamic
 #   ADDRESS            NETWORK         BROADCAST       INTERFACE
 0   10.1.0.1/24        10.1.0.0        10.1.0.255      inside
 1   1.1.1.2/29         1.1.1.0         1.1.1.7         outside
 2   10.2.0.1/24        10.2.0.0        10.2.0.255      dmz
[admin@Example-Router] >
</pre>
====find====
The "find" command returns a set of items that can then be acted on by other commands. When "find" is executed without any parameters, it returns all items. When "find" is executed with parameters only items that match the parameters are returned. The most common matcher is "=" to exactly match a parameter value, it is also possible to match regular expressions with the "~" operator.

The below enables all IP addresses that exist:
<pre>
[admin@Example-Router] > /ip address print
Flags: X - disabled, I - invalid, D - dynamic
 #   ADDRESS            NETWORK         BROADCAST       INTERFACE
 0   10.1.0.1/24        10.1.0.0        10.1.0.255      inside
 1   1.1.1.2/29         1.1.1.0         1.1.1.7         outside
 2 X 10.2.0.1/24        10.2.0.0        10.2.0.255      dmz
[admin@Example-Router] > /ip address enable [/ip address find]
[admin@Example-Router] > /ip address print
Flags: X - disabled, I - invalid, D - dynamic
 #   ADDRESS            NETWORK         BROADCAST       INTERFACE
 0   10.1.0.1/24        10.1.0.0        10.1.0.255      inside
 1   1.1.1.2/29         1.1.1.0         1.1.1.7         outside
 2   10.2.0.1/24        10.2.0.0        10.2.0.255      dmz
[admin@Example-Router] >
</pre>
The below disables all IP addresses that are on interface "dmz":
<pre>
[admin@Example-Router] > /ip address print
Flags: X - disabled, I - invalid, D - dynamic
 #   ADDRESS            NETWORK         BROADCAST       INTERFACE
 0   10.1.0.1/24        10.1.0.0        10.1.0.255      inside
 1   1.1.1.2/29         1.1.1.0         1.1.1.7         outside
 2   10.2.0.1/24        10.2.0.0        10.2.0.255      dmz
[admin@Example-Router] > /ip address disable [/ip address find interface=dmz]
[admin@Example-Router] > /ip address print                                      
Flags: X - disabled, I - invalid, D - dynamic
 #   ADDRESS            NETWORK         BROADCAST       INTERFACE
 0   10.1.0.1/24        10.1.0.0        10.1.0.255      inside
 1   1.1.1.2/29         1.1.1.0         1.1.1.7         outside
 2 X 10.2.0.1/24        10.2.0.0        10.2.0.255      dmz
[admin@Example-Router] >
</pre>
The below enables all IP addresses that are on interfaces that start with the letter "d":
<pre>
[admin@Example-Router] > /ip address print                                      
Flags: X - disabled, I - invalid, D - dynamic
 #   ADDRESS            NETWORK         BROADCAST       INTERFACE
 0   10.1.0.1/24        10.1.0.0        10.1.0.255      inside
 1   1.1.1.2/29         1.1.1.0         1.1.1.7         outside
 2 X 10.2.0.1/24        10.2.0.0        10.2.0.255      dmz
[admin@Example-Router] > /ip address enable [/ip address find interface~"^d"]
[admin@Example-Router] > /ip address print
Flags: X - disabled, I - invalid, D - dynamic
 #   ADDRESS            NETWORK         BROADCAST       INTERFACE
 0   10.1.0.1/24        10.1.0.0        10.1.0.255      inside
 1   1.1.1.2/29         1.1.1.0         1.1.1.7         outside
 2   10.2.0.1/24        10.2.0.0        10.2.0.255      dmz
[admin@Example-Router] >
</pre>
====move====
The "move" command moves items in ordered lists where order is important for flow of execution. Order is especially important for rules in the IP firewall filter, mangle, and NAT facilities. Items can be moved by referring to the ID of the item that is being moved, and the ID of the item the rule should be moved to. The below moves rule number 3 into the place of rule number 0, and all other rules shift down. The firewall rules shown are non-sensical and only for demonstration of the "move" command:
<pre>
[admin@Example-Router] > /ip firewall mangle print where action="mark-routing"
Flags: X - disabled, I - invalid, D - dynamic
 0   chain=prerouting action=mark-routing new-routing-mark="mark-a"
 1   chain=prerouting action=mark-routing new-routing-mark="mark-b"
 2   chain=prerouting action=mark-routing new-routing-mark="mark-c"
 3   chain=prerouting action=mark-routing new-routing-mark="mark-d"
[admin@Example-Router] > /ip firewall mangle move 3 0
[admin@Example-Router] >
[admin@Example-Router] > /ip firewall mangle print where action="mark-routing"
Flags: X - disabled, I - invalid, D - dynamic
 0   chain=prerouting action=mark-routing new-routing-mark="mark-d"
 1   chain=prerouting action=mark-routing new-routing-mark="mark-a"
 2   chain=prerouting action=mark-routing new-routing-mark="mark-b"
 3   chain=prerouting action=mark-routing new-routing-mark="mark-c"
[admin@Example-Router] >
</pre>
===Context===
Contexts can also be set for a set of commands by enclosing a set in braces, saving keystrokes. The below enables all IP addresses:
<pre>
[admin@Example-Router] > /ip address print
Flags: X - disabled, I - invalid, D - dynamic
 #   ADDRESS            NETWORK         BROADCAST       INTERFACE
 0   10.1.0.1/24        10.1.0.0        10.1.0.255      inside
 1   1.1.1.2/29         1.1.1.0         1.1.1.7         outside
 2 X 10.2.0.1/24        10.2.0.0        10.2.0.255      dmz
[admin@Example-Router] > /ip address { enable [find] };
[admin@Example-Router] > /ip address print
Flags: X - disabled, I - invalid, D - dynamic
 #   ADDRESS            NETWORK         BROADCAST       INTERFACE
 0   10.1.0.1/24        10.1.0.0        10.1.0.255      inside
 1   1.1.1.2/29         1.1.1.0         1.1.1.7         outside
 2   10.2.0.1/24        10.2.0.0        10.2.0.255      dmz
[admin@Example-Router] >
</pre>

==Example network==
This tutorial uses an example network to explain configuration. The router has a public IP address of 1.1.1.2/30 with a default gateway of 1.1.1.1, and port 'ether1' (later renamed to 'outside') is used to connect to the ISP. Port 'ether2' (later renamed to 'dmz') is a network that is a true DMZ, this network uses IP address 10.2.0.1/24. Ports 'ether3' through 'ether5' are switched together and all are available for use on the LAN network, later renamed to 'inside'. This network uses 10.1.0.1/24.

Other SoHo routers refer to unconditional port forwarding to a LAN machine as a DMZ. In more advanced networks DMZ refers to a third network other than WAN and LAN, where hosts run services accessible to the Internet at large. Running this in a different network further protects the LAN network: hosts in the DMZ are exposed to the Internet and may be under attach. If breached this doesn't gain the attached access to the LAN network as a firewall doesn't permit DMZ hosts to establish new connections to the LAN.

[[File:How-to-configure-a-home-router-diagram.png‎]]

==Router interfaces (ports)==
===Physical interfaces===
Different router models have different sets of physical interfaces. RB1000s have a total of 4 1000Base-TX ports. RB1100s have 10 1000Base-TX ports (2 groups of 5 ports with a 1Gbps pipe to the CPU per group, each group has a switch chip for wire speed layer 2 throughput), and 3 100Base-TX ports. RB750Gs have 5 total 1000Base-TX ports with a switch chip for wire speed layer 2 throughput. [http://routerboard.com routerboard.com] has all the data sheets and specs.
===Switch Chip===
Some routers have a built in switch chip that can be activated on physical interfaces to permit wire speed throughput between those interfaces. Those interfaces will essentially act like a switch would. By default this is enabled in the SoHo models. While more advanced configuration is possible most small networks simply need to activate or deactivate the feature. Within the switch chips interfaces are either master ports or slave ports. The master port is where all the router configuration happens (such as the IP address), and the slave ports refer to the master port. The below configures interfaces ether3, ether4, and ether5 as slaves to interface ether2:
<pre>
/interface ethernet
set [find name=ether3] master-port=ether2
set [find name=ether4] master-port=ether2
set [find name=ether5] master-port=ether2
</pre>
The switch chip is capable for small networks, but can't do advanced VLAN configurations.
===Bridging vs routing===
Bridging (which is what switches do) is something that switches do a lot better than routers. This is just a personal opinion, but whenever I find myself thinking that I should bridge wired interfaces I almost always end up using a switch instead. One counterexample are wireless interfaces, which are commonly bridged into wired networks.
===Named interfaces===
All configuration of interfaces in RouterOS is done against the name of an interface. Names can be arbitrarily set. 

It is good practice to make the names informative. A good name for the interface used to connect to the Internet is 'outside' or 'WAN', a good name for the the interface used to connect to inside customers or your home network is 'inside' or 'LAN'. When using the switch chip the names for the slaved interfaces are unimportant in all but fairly advanced configurations since any router configuration will be limited to the master port. It can still make good sense to name the interfaces after what they connect to.
===Example network===
In our example network we want ether1 to be named 'outside', ether2 to be named 'dmz', and ether3 - ether5 to be switched with an interface name of 'inside'.
<pre>
/interface ethernet
set [find name=ether1] name=outside
set [find name=ether2] name=dmz
set [find name=ether3] name=inside
set [find name=ether4] name=inside-slave master-port=inside
set [find name=ether5] name=inside-slave2 master-port=inside
</pre>
==IP addresses==
Each interface can carry one or more IP addresses on it. Usually only one IP address per interface is defined. While viewing IP addresses shows parameters for the network and broadcast address of the network, these should usually not be defined manually and will automatically be added when left out. When adding the IP address the subnet mask is given in CIDR notation.
<pre>
[admin@Example-Router] /ip address> print
Flags: X - disabled, I - invalid, D - dynamic
 #   ADDRESS            NETWORK         BROADCAST       INTERFACE
 0   10.1.0.1/24        10.1.0.0        10.1.0.255      inside
[admin@Example-Router] /ip address> add address=1.1.1.2/29 interface=outside
[admin@Example-Router] /ip address> print
Flags: X - disabled, I - invalid, D - dynamic
 #   ADDRESS            NETWORK         BROADCAST       INTERFACE
 0   10.1.0.1/24        10.1.0.0        10.1.0.255      inside
 1   1.1.1.2/29         1.1.1.0         1.1.1.7         outside
[admin@Example-Router] /ip address>
</pre>
===DHCP client===
In many small environments the router will receive a dynamic IP address via DHCP on its WAN interface from the ISP. The DHCP client can also be used to populate the routing table with a default route via the ISP, and pull in DNS servers for the router - and the networks behind it - to use. The DHCP client must be given an interface to run on, as well as whether to listen to the DHCP options for DNS and a default route.
<pre>
/ip dhcp-client
add interface=outside add-default-route=yes use-peer-dns=yes
</pre>
===PPPoE client===
The other common method for SoHo routers to receive a public IP address is via PPPoE, which is used in DSL connections. Most DSL modems can be set into a bridge mode where the modem performs the translation between the DSL network and regular Ethernet, the router then becomes the PPPoE client and directly talks to the ISP network through the modem. PPPoE assigns an IP address to the interface the PPPoE client is running on, and can also be used to learn about a default route as well as DNS servers. It is very important to note that the PPPoE client creates a new logical interface (in the example below it is named 'pppoe-WAN') which now becomes the interface to refer to for WAN traffic. The 'outside' interface will only be used for the PPPoE encapsulated traffic, as far as the router is concerned IP traffic will be leaving the router via the PPPoE client interface.
<pre>
/interface pppoe-client
add name=pppoe-WAN interface=outside add-default-route=yes use-peer-dns=yes
</pre>
===Example network===
In our example network we want the 'outside' interface to have a static IP address of 1.1.1.2/29, the 'dmz' interface to have a static IP address of 10.2.0.1/24, and the 'inside' interface to ave a static IP address of 10.1.0.1/24.
<pre>
/ip address
add address=1.1.1.2/29 interface=outside
add address=10.2.0.1/24 interface=dmz
add address=10.1.0.1/24 interface=inside
</pre>

==IP routes==
Just like on other routing platforms dynamic connected routes are created for all networks that the router has IP addresses to - after all, if the router has an IP address in the 10.1.0.1/24 network on the "inside" interface then it can reach hosts on that network via that interface. Static routes can be added by defining a destination address and a gateway. Usually at least one static route is required: a default route for the router pointing out to the ISP network. RouterOS can of course also run dynamic routing protocols such as RIP, OSPF, and BGP, but that is outside the scope of this article.
<pre>
[admin@Example-Router] > /ip route print
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
B - blackhole, U - unreachable, P - prohibit
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 ADC  10.1.0.0/24        10.1.0.1        inside             0
 1 ADC  1.1.1.0/29         1.1.1.2         outside            0
[admin@Example-Router] >
</pre>
While RouterOS will let you configure an IP address within the smae network on two different routed interfaces it would be very bad to do so. The router now would think that it can reach the hosts within that network via either interface, which is unlikely to be the case.
===Adding a default route===
New static routes can be added as per below. The example shows adding a default route (a route for destination 0.0.0.0/0) via the ISP gateway 1.1.1.1:
<pre>
[admin@Example-Router] > /ip route add dst-address=0.0.0.0/0 gateway=1.1.1.1
[admin@Example-Router] > /ip route print
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
B - blackhole, U - unreachable, P - prohibit
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 A S  0.0.0.0/0                          1.1.1.1            1
 1 ADC  10.1.0.0/24        10.1.0.1        inside             0
 2 ADC  1.1.1.0/29         1.1.1.2         outside            0
[admin@Example-Router] >
</pre>
It is interesting to note that technically two routes are now involved for traffic to the Internet: the router looks at the packet and finds that the default route matches, and that it should send traffic via 1.1.1.1. It then needs to figure out how to send traffic to 1.1.1.1, looks at its routing table again, and finds that it can get to 1.1.1.1 via the "outside" interface via the directly connected route for that network.

Also note that it is not necessary or recommended to add a static default route if your router receives its WAN IP address via DHCP or PPPoE. Static default routes should only be used when the public IP address on the WAN interface is also static.
===Example network===
In our example network we want the router to use 1.1.1.1 as a default gateway:
<pre>
/ip route
add dst-address=0.0.0.0/0 gateway=1.1.1.1
</pre>
==DHCP server==
DHCP server services consist of three components: the IP pool that defines the range of IP addresses clients can receive a lease for, the DHCP server network that defines the parameters clients are passed (such as gateway IP address and DNS servers), and the DHCP server instance itself that ties a pool to an interface.
===IP Pools===
IP pools define the range of IP addresses available for users to obtain as a DHCP lease. Any IP address in a subnet not covered by the pool range is available for static use.

IP pools simply consist of a name that they can be referred to by, as well as a range of IP addresses. The OS will let you set a range that is out of the bounds of the subnet of the network users will actually be on, leading to IP addresses unable to reach their default gateway. Be careful when adjusting ranges to check that the range chosen is actually covered by the IP network configured on the interface.

To add a pool:
<pre>
[admin@Example-Router] /ip pool> export
/ip pool
add name=DHCP-Pool-inside ranges=10.1.0.10-10.1.0.100
[admin@Example-Router] /ip pool>
</pre>
To edit a pool:
<pre>
[admin@Example-Router] /ip pool> print                                           
# NAME               RANGES
 0 DHCP-Pool-inside  10.1.0.10-10.1.0.100
[admin@Example-Router] /ip pool> set [find name="DHCP-Pool-inside"] ranges=10.1.0.100-10.1.0.200
[admin@Example-Router] /ip pool> print
# NAME               RANGES
 0 DHCP-Pool-inside  10.1.0.100-10.1.0.200
[admin@Example-Router] /ip pool>
</pre>
===DHCP Server Networks===
DHCP server networks define parameters (DHCP options) to pass on to DHCP clients. The minimum set of options include the default gateway and name servers. The default gateway is usually the IP address of the router on the network interface, and the name servers usually is as well - at least as long as the router is configured as a DNS caching resolver. That is covered in a different section of this document.

To add a DHCP server network:
<pre>
[admin@Example-Router] /ip dhcp-server network> export
/ip dhcp-server network
add address=10.1.0.0/24 comment=inside dns-server=10.1.0.1 gateway=10.1.0.1
[admin@Example-Router] /ip dhcp-server network>
</pre>
Note that multiple DNS servers are specified as a comma separated list without spaces.

To edit a DHCP server network:
<pre>
[admin@Example-Router] /ip dhcp-server network> print
 # ADDRESS            GATEWAY         DNS-SERVER      WINS-SERVER     DOMAIN
 0 ;;; inside
   10.1.0.0/24        10.1.0.1        10.1.0.1
[admin@Example-Router] /ip dhcp-server network> set [find comment="inside"] dns-server=8.8.8.8
[admin@Example-Router] /ip dhcp-server network> print
 # ADDRESS            GATEWAY         DNS-SERVER      WINS-SERVER     DOMAIN
 0 ;;; inside
   10.1.0.0/24        10.1.0.1        8.8.8.8
[admin@Example-Router] /ip dhcp-server network>
</pre>
===DHCP Servers===
DHCP server instances cause the DHCP server process in the router to listen for client requests on the specified interfaces. Each interface that is to offer DHCP to clients must have a dedicated DHCP server instance. The instance sets basic parameters such as whether the server is authoritative and the client lease time, and ties IP pools to interfaces.

To add a DHCP server instance:
<pre>
[admin@Example-Router] /ip dhcp-server> export
/ip dhcp-server
add address-pool=DHCP-Pool-inside authoritative=yes bootp-support=static \
   disabled=no interface=inside lease-time=3h name=DHCP-inside
[admin@Example-Router] /ip dhcp-server>
</pre>

To edit a DHCP server instance:
<pre>
[admin@Example-Router] /ip dhcp-server> print
Flags: X - disabled, I - invalid
 #   NAME     INTERFACE     RELAY           ADDRESS-POOL     LEASE-TIME ADD-ARP
 0   DHCP-... inside                        DHCP-Pool-Ins... 3h
[admin@Example-Router] /ip dhcp-server> set [find interface=inside] lease-time=1h
[admin@Example-Router] /ip dhcp-server> print
Flags: X - disabled, I - invalid
 #   NAME     INTERFACE     RELAY           ADDRESS-POOL     LEASE-TIME ADD-ARP
 0   DHCP-... inside                        DHCP-Pool-Ins... 1h
[admin@Example-Router] /ip dhcp-server>
</pre>

===Lease time considerations===
The below usually isn't really very important for home networks, but can become worth considering for routers that serve constantly changing clients.

Client's renew their DHCP lease after half the lease time interval has passed. It is generally better to create larger networks so that stale leases for clients no longer attached don't eat up all available IP addresses on the netowrk, and set long lease times.

By way of example, if a network has 1,200 users attached to it and a DHCP lease time of just 10 minutes each user will send lease renewal requests to the DHCP server on the router every 5 minutes. On average the DHCP server would see (1,200 users / 300 seconds) = 4 DHCP requests per second. With a lease time set to 2 hours the DHCP server would only see (1,200 users / 3600 seconds) = one DHCP request every 3 seconds, which leaves more router resources available to route packets, rate limit users, or do whatever else the router is configured to do. Private IP address space is free, it is better to optimize for router utilization than for IP address conservation.
===The wizard===
The above explained how DHCP servers work internally. Alternatively you can simply let the router create all the configuration items for you by running "/ip dhcp-server setup" and answering the interactive prompts, many of which will have pre-filled values that you can accept.
===Example network===
In our example network we want the router to act as a DHCP server for the 'inside' network on 10.1.0.0/24. The pool of DHCP leases is to be 10.1.0.200-10.1.0.254. The router will act as the default gateway for the DHCP clients, and will also act as the DNS server.
<pre>
/ip pool
add name=DHCP-Pool-inside ranges=10.1.0.200-10.1.0.254
/ip dhcp-server network
add address=10.1.0.0/24 comment=inside dns-server=10.1.0.1 gateway=10.1.0.1
/ip dhcp-server
add address-pool=DHCP-Pool-inside authoritative=yes bootp-support=static \
   disabled=no interface=inside lease-time=3h name=DHCP-inside
</pre>

==IP firewall==
The IP firewall is responsible for filtering packets (accepting or dropping them), as well as changing their properties. Three facilities exist: filter, mangle, and NAT. Only filter and NAT are discussed here.
===Filters===
Filters are used to drop or accept packets going through the router or going to the router. All packets that the router sees will traverse a series of chains. The default action - i.e., the action that is taken if the packet doesn't match any of the rules in a chain - is to accept the packet. This is called a 'default permit' firewall. 'Default permit' firewalls are related to the concept of blacklisting, which refers to the practice of explicitly identifying all things that are bad and accepting everything else as implicitly good. Blacklisting is generally not a very good or secure approach as it is very easy to forget to define a known bad thing. Additionally new bad things are continuously being developed. A more secure approach is whitelisting in 'default deny' firewall: first everything that is known to be good is permitted, and then everything else is denied. Because the RouterOS firewall filters are 'default permit' we will have to explicitly drop everything we didn't explicitly permit before.
====Chains====
The mangle and filter facilities have 5 built in chains:
* prerouting
* input
* forward
* output
* postrouting
It is also possible to define custom chains and jump into them. That approach is very useful when the same actions should be applied to packets identified in different rules. However, custom chains are outside the scope of this article.

All packets being sent to the router always traverse the 'prerouting' chain. At the end of 'prerouting' the router determines whether a packet is destined to the router itself (for example a packet that is part of a Winbox connection going from the management host to the router), or whether the packet should be sent out another interface. Packets to the router itself will then traverse the 'input' chain. Packets that will go through the router will traverse the 'forward' chain. Packets to the router itself will never be in the 'forward' chain, and packets through the router will never be in the 'input' chain. Packets that are generated by the router itself (for example a packet that is part of a Winbox connection going from the router to the managment station) will traverse the 'output' chain. Both packets through the router as well as packets from the router will then traverse the 'postrouting' chain.

Though somewhat complicated, realistically only two chains are important for simple SoHo routers: the router itself is secured in the 'input' chain, and the hosts on networks behind the router are secured in the 'forward' chain.

To learn about all the details of chains and how packets move through the firewall refer to the single best page on the wiki: the [http://wiki.mikrotik.com/wiki/Manual:Packet_Flow Packet Flow] page. While daunting at first it becomes easier to decipher the more time you spend with RouterOS, and answers most questions about where and when to do something.
====State====
Like other advanced firewall platforms RouterOS can keep state of connections by tracking them. That means that it knows what connection a packet belongs to, and can make decisions on the packet based on how other packets in the connection have been treated. This is very useful in that it allows a firewall approach where the only decisions being made are which connections can be established in the first place. All packets in connections that were allowed to be established are then simply permitted, and all other packets are dropped.

There are three connection states: 'established' means the packet is part of an already established connection, 'related' means that the packet is part of a connection that is related to an already established conncetion. The canonical example here is FTP, which has both a data and a control channel: first a control channel is established, which then negotiates the details of the data channel that will actually transfer files. By inspecting the control channel the router can learn about the dynamically negotiated data channel. And 'invalid' means that the packet is part of a connection that the router doesn't know anything about. 
====Example network====
In our example network we want the router to permit devices on the 'inside' network to establish connections to the Internet behind the 'outside' interface, as well as to the web server in the DMZ. The web server is allowed to establish connections to the Internet behind the 'outside' interface, but can not establish connections to the 'inside' network. The Internet can establish HTTP and HTTPS connections to the web server in the DMZ, but cannot establish any other connections to local devices.

The router itself can only be managed from the 'inside' network - devices on the Internet or in the DMZ cannot establish any management connections to the router at all.

Those policies are all implement via connection state. The rules are surpsingly readadble in English:
<pre>
/ip firewall filter
add chain=input connection-state=established action=accept
add chain=input connection-state=related action=accept
add chain=input connection-state=invalid action=drop
add chain=input in-interface=inside action=accept
add chain=input action=drop</pre>
First all packets in established and related connections are permitted. Then all invalid packets are dropped. Then packets coming in via the 'inside' interface are permitted - this allows hosts on the 'inside' network to establish connections to the router. Finally any packets that don't match those rules are dropped.
<pre>
/ip firewall filter
add chain=forward connection-state=established action=accept
add chain=forward connection-state=related action=accept
add chain=forward connection-state=invalid action=drop
add chain=forward in-interface=inside action=accept
add chain=forward in-interface=dmz out-interface=outside action=accept
add chain=forward dst-address=10.2.0.10 protocol=tcp dst-port=80,443 action=accept
add chain=forward action=drop
</pre>
First all packets in established and related connections are permitted. Then all invalid packets are dropped. Then packets coming in via the 'inside' interface are permitted - this allows hosts on the 'inside' network to establish connections to anywhere, including the Internet and the DMZ. Then any packets coming in via the 'dmz' interface are permitted as long as the router is going to send them out the 'outside' interface - this allows the DMZ hosts to access the Internet, but keeps them out of the 'inside' network. Then connections to 10.2.0.10 (the web server IP) on tcp/80 and tcp/443 are permitted - this allows the Internet to connect to the web server. Finally any packets that don't match those rules are dropped.

===NAT===
NAT refers to changing IP addresses in IP packet headers. This is often a requirement when private IP addresses from the RFC1918 range are used on a network: private IP addresses cannot be routed across the Internet, so the router has to subsitute its own public IP address in their places. There are two types of NAT: destination NAT changes the IP address in the destination header field, and source NAT changes the IP address in the source header field. They are processed in the 'srcnat' and 'dstnat' chains of the NAT facility. NAT requires connection tracking, and NAT is only evaluated for the first packet in a connection. All other packets in the same connection will then have the same action as the first packet applied to them, for the lifetime of the connection. For packets flowing in the other direction the opposite source NAT action is taken. This is best illustrated with an example:

10.1.0.10 on the 'inside' network is sending a packet to a web server with an IP address of 5.5.5.5 on the Internet. When the packet leaves the host it has a destination IP address of 5.5.5.5 and a source IP address of 10.1.0.10. When the packet gets to the router and sent out the 'outside' interface to the Internet the router applies source NAT and changes the source IP address from 10.1.0.10 to 1.1.1.2, the IP address on its WAN interface. When the packet gets to the web server and the server replies it sends the packet with a source IP address of 5.5.5.5 and a destination IP address of 1.1.1.2. Once the packet gets to the router it is found to be part of an existing connection, and that the original source address was 10.1.0.10. The router replaces the destination IP address in the packet header with 10.1.0.10 and sends the packet out the 'inside' interface to the host. It is important to note that this destination NAT action doesn't have to be configured - it happens automatically, as part of undoing the original source NAT action that was explicitly configured. Each explicit source NAT rule has an implicit destination NAT action that undoes the translation in the other direction, and each explicit destination NAT rule has an implicit source NAT action for the same reason.

It is also important to know when NAT happens: because NAT changes the IP address in the packet headers different chains see different IP addresses for the same packet. Destination NAT (both explicit and implicit) happens after the 'prerouting' chain. Source NAT happens after the 'postrouting' chain. Because of the sequence of actions the prerouting chain always sees packets with their original IP address, and the 'input' and 'forward' chains see packets with destination IPs as changed by destination NAT. 
====Source NAT====
Source NAT comes in two different flavors: 'masquerade' and 'src-nat'. Both change the source IP address in a packet header, but use different mechanisms to derive the new IP address. 'masquerade' dynamically looks at the primary IP address on the interface that the packet will leave the router through, and uses that as the new source IP address. This is perfect for interfaces that received their IP address via DHCP or PPPoE. 'src-nat' requires a parameter called 'to-addresses' that statically configures the source IP address to use. This is perfect for interfaces with static IP addresses. Source NAT should only ever be applied when absolutely needed at the border where private IP addresses can no longer be routed. In most small networks that means source NAT should only be applied on the WAN interface.
=====Masquerade=====
The below configures an interface for masquerade source NAT, and refers to the outbound interface to make sure only traffic leaving through the WAN interface is subject to source NAT:
<pre>
/ip firewall nat
add chain=srcnat out-interface=outside action=masquerade
</pre>
=====Static source NAT=====
The below configures an interface for static source NAT, and again refers to the outbound interface. The only additional information required is the static address:
<pre>
/ip firewall nat
add chain=srcnat out-interface=outside action=src-nat to-address=1.1.1.2
</pre>
====Destination NAT====
Unlike source NAT all destination NAT is static. Destination NAT is often used for port forwarding to allow Internet resources to access devices on the local network. It is possible to forward all IP traffic, or just specific ports for specific protocols. It is important to be very specific when writing destination NAT rules: for example, it is easily possible to forget to specify a destination IP address and to just apply destination NAT to all HTTP and HTTPS traffic. This would break web browsing for other computers behind the router.
The below forwards ports tcp/80 and tcp/443 (HTTP and HTTPS) to the web server with IP address 10.2.0.10 in the DMZ network. 
<pre>
/ip firewall nat
add chain=dstnat dst-address=1.1.1.2 prototocol=tcp dst-port=80,443 \
   action=dst-nat to-addresses=10.2.0.10
</pre>

====Example network====
In our example network we need to source NAT out to the Internet and translate all inside and DMZ traffic to our static IP address, and forward web traffic to the web server in the DMZ as shown above.
<pre>
/ip firewall nat
add chain=srcnat out-interface=outside action=src-nat to-address=1.1.1.2
add chain=dstnat dst-address=1.1.1.2 prototocol=tcp dst-port=80,443 \
   action=dst-nat to-addresses=10.2.0.10
</pre>

==Date and Time==
RouterBOARDs do not have batteries that keep time when the routers shut down or are power cycled. Because of this the routers will reset their internal tim to January 1st, 1970 when they reboot. NTP is a protocol that allows devices to sync their time over the network. This is necessary for the router to have the correct time. Having the correct time is usually a good idea simply because it allows log entries (which are timestamped) to make sense when troubleshooting. It's hard to do the math and figure out what the real timestamps are hwn the router is the current date showing March 19, 1971 and the log shows an interface went down on March 17, 1971 12:05.

To configure NTP requires NTP servers to sync again. The best option for this is to go to the [http://www.pool.ntp.org NTP Pool Project] web site and find a pool close to you.

There are two different NTP options: you can install the NTP package and get a full NTP server and client, or you can use the simple NTP client built into the base package. This manual only shows the simple client.
===Example network===
Because people tend to blindly copy and paste from tutorials the below NTP server addresses do not work: 2.2.2.2 and 3.3.3.3 are not a valid NTP server. Please find one or more public NTP servers near you instead and replace their IP addresses below.
<pre>
/system ntp client
set enabled=yes primary-ntp=2.2.2.2 secondary-ntp=3.3.3.3
</pre>