The MikroTik Security Guide and Networking with MikroTik: MTCNA Study Guide by Tyler Hart are available in paperback and Kindle!
One of the most common tasks that a network administrator will need to perform is forwarding ports across a router using Network Address Translation (NAT) - also known as "pinholing". This process can be set up statically by an administrator, only forwarding a few ports as needed. It can also be handled dynamically by processes like UPnP that pinhole the router on their own using instructions from devices that request ports be opened. Ports are forwarded across routers to make internal services like email and web servers available to the outside world.
For security these servers should be located in a separate network segment from the rest of the internal network, and only the necessary ports should be forwarded across the router to keep the attack surface as small as possible. One of the most frequently seen implementations of this is forwarding HTTP(S) access across the router from an external static IP to an internal Apache, NGINX, or IIS server. This could be put in place to facilitate outside access to an Exchange OWA portal, a line of business web application, Sharepoint server, etc.
In this case we have a single Mikrotik router with a static IP address on the WAN interface and an internal Apache server running on a Linux box. We need to forward HTTP (TCP port 80) across the router so that the web server is accessible from the Internet. No other ports should be forwarded for security - we don't want someone running a port scan and finding that SSH or some other protocol exposed on that Linux server. Here is the topology:
Mikrotik NAT Topology
This is as straightforward as it gets - one WAN connection, one server. We've identified our internal (ether2) and external (ether1) interfaces, and we know what protocol (TCP), port (80), and internal IP address (192.168.88.198) we need to NAT to.
Here is the NAT rule we'll use to accomplish the port forwarding:
/ip firewall nat add action=dst-nat chain=dstnat comment="NAT in HTTP" dst-port=80 in-interface=ether1-gateway protocol=tcp to-addresses=192.168.88.198 to-ports=80
First, we add a new action (dst-nat) using the NAT chain DSTNAT. The chain DSTNAT handles traffic that is headed inbound toward an internal network, like the traffic we want to handle coming in from the WAN to the internal server. The other unused chain - SRCNAT - handles traffic leaving a NAT'd internal network and going to some other segment, like the WAN. We'll discuss SRCNAT more when we talk about Port Address Translation (PAT). In this command we're also indicating the dst-port (80) that traffic will be hitting coming in from the WAN, and the type of protocol (TCP). We also indicate that this traffic we want to NAT internally is coming into interface ether1. By being so specific with our NAT rule we're restricting the attack surface that's getting presented to the outside world.
The final part of the command indicates what internal IP address to NAT the traffic to (to-addresses=192.168.88.198) and what port to use (to-ports=80). Everything hitting the router on WAN port ether1 that is TCP/80 will be sent to internal IP 192.168.88.198:80 - that's all there is to it. If a port scan were to be run on the router now we would see one extra port open, with an Apache server responding to HTTP requests. We've forwarded only the necessary traffic, and assuming that the web server is patched regularly there should be no security issues with this configuration.
This is a simple task, but be mindful going forward of the security implications of exposing an internal server to external requests. Only forward what needs to be forwarded, and be sure to patch your servers regularly to reduce the risk of someone compromising your server and then using it to access your internal network segments.
