Hello forum, first things first. I'm new to Mikrotik and the world of corporate / enterprise level networking. I have inherited my position, since the manager left the company, management informed me they will not replace him any time soon. I have been task to make sure the list below is in order and working properly asap. I have read a lot of forum posts and attempted a few things myself, but no success. I need some help understanding what is the proper / best practices to be followed in configuring, because something or multiple things are wrong since a simple task like port forwarding isn't working. I thank in advance anyone here who helps me understand how to properly configure my mess.

I'm willing to wipe everything and start over if that is what it takes to make the Mikrotik Router work flawlessly.

Here is what I am trying to do.
1. Configure WAN with inbound ISP
2. Configure Multiple LAN ports with both inbound / outbound traffic
3. Setup Router security (Firewall Hardening)
3. Setup VLAN (Guest, Employee, HR, Management, VPN, VoIP)
4. Several Internal Servers, need to enable proper internal redirection without having send/receive packet loss or NAT confusion
5. Configure Port Forwarding
6. Enable ability to monitor traffic (websites, protocols, IPs, MAC, etc)
7. Configure VPN remote access
8. Allows Active Directory to be the authentication for VPN users
9. Proper White listing of inbound server traffic to our network

Network Equipment
Router: CCR1036-8G-2s+
- Firmware: tilegx, 3.41
- RouterOS: 6.40.4 (Update to 6.42.1 is scheduled during maintenance this month.)
Network Switches HPE Pro Curve v1920
Aruba IAP-105


Network Topology
ISP (Fiber to RJ45) > Mikrotik (Port 1 = WAN) > Mikrotik (Port 2 = LAN) > HPE Pro Curve > Aruba IAP
- HPE Pro Curve are daisy chained to each floor
- Aruba IAP's are connected directly to the HPE Pro Curves on each floor

Export of current configuration

Very challenging. First things first. Make good test of the newer version with your configuration to be sure it works as you need before you decide to upgrade productive device. You know why...

Very challenging. First things first. Make good test of the newer version with your configuration to be sure it works as you need before you decide to upgrade productive device. You know why...

Jarda,
Thank you for your post, but please pardon my ignorance here, but how would I test the updated firmware 6.42.1? Is there a sandbox environment or a virtual way of testing the update / settings?

Virtually you can run CHR. Because running ros on particular device might bring different unwanted effects, you should test on the same device model if you would like to be sure. You can also make the tests on productive device using the partitions for different versions of ros.

Virtually you can run CHR. Because running ros on particular device might bring different unwanted effects, you should test on the same device model if you would like to be sure. You can also make the tests on productive device using the partitions for different versions of ros.

Thank you Jarda,
I looked up the wiki article https://wiki.mikrotik.com/wiki/Manual:CHR on CHR and will see if I can spin up a Hyper-V tonight for testing the new firmware upgrade.

Are there any suggestions you might have towards cleaning up the configuration or fine tuning it to work properly? If you provide forum links, or wiki links, I'll read through them. Though I'm looking for experienced members to help guide me through cleaning up my configuration. It just doesn't make sense to me why our Port forwarding isn't working and as a byproduct, I cannot implement other features and trust the configuration to work properly.

It just doesn't make sense to me why our Port forwarding isn't working and as a byproduct, I cannot implement other features and trust the configuration to work properly.

When You say it is not working, what exactly is (isn't) happening?

1) People on the Internet cannot access the internal server?
2) People inside the network cannot access one of the internal servers, using its public IP?

If the problem is 2), then You need to look at hairpin NAT. The official documentation has an example. Look at the NAT section.

It just doesn't make sense to me why our Port forwarding isn't working and as a byproduct, I cannot implement other features and trust the configuration to work properly.

When You say it is not working, what exactly is (isn't) happening?

1) People on the Internet cannot access the internal server?
2) People inside the network cannot access one of the internal servers, using its public IP?

If the problem is 2), then You need to look at hairpin NAT. The official documentation has an example. Look at the NAT section.

Paternot,
It is number two. I read through the Mikrotik Hairpin NAT article https://wiki.mikrotik.com/wiki/Hairpin_NAT and I attempted to follow the hairpin NAT setup from the example. I lost the ability to do port forwarding from that moment on. Before the hairpin NAT I had successfully setup the Port Forwarding for RDP, SSH, and FTP to a server inside the network. But once the hairpin NAT was setup for faster local resource access, it broke those connections. I'm not sure how to test to provide proof. But if I remove the hairpin NAT, it breaks whatever connect is made to resolve a FQDN sub-domain name pointed to our Public IP to access an internal resource NAS.
I will say it doesn't make sense to me because in my head it would make sense to do the following and have it work.

• Setup Sub Domain at Authority
• Point Sub Domain to Public IP Address
• Configure Port forwarding to say, when port XXXX is accessed send to IP XXX.XXX.XXX.XXX and Port XXXX

It should just work.

Because it doesn't work, it means to me I've probably set it up wrong and therefore have these issues.
I believe these are the lines I used to setup the main outbound NAT rule and the hairpin NAT.

add action=masquerade chain=srcnat comment="Outbound traffic" out-interface=ether2-master-local src-address=10.10.10.0/23
add action=masquerade chain=srcnat comment=Loopback out-interface=ether2-master-local to-addresses=X.X.X.243
add action=masquerade chain=srcnat comment=Loopback disabled=yes out-interface=ether1
add action=dst-nat chain=dstnat comment=Loopback dst-address=X.X.X.243 to-addresses=10.10.10.3

At this point I have my company accustom to using the easy to remember FQDM instead of the internal IP. While I can update each computers host file, it would be a pain and I'd rather have it at one location like the Router since it is central and easier to manage.

I am open to suggestions or additional reading material to better understand why the hairpin NAT is effecting the port forwarding.

Virtually you can run CHR. Because running ros on particular device might bring different unwanted effects, you should test on the same device model if you would like to be sure. You can also make the tests on productive device using the partitions for different versions of ros.

Thank you Jarda,
I looked up the wiki article https://wiki.mikrotik.com/wiki/Manual:CHR on CHR and will see if I can spin up a Hyper-V tonight for testing the new firmware upgrade.

Are there any suggestions you might have towards cleaning up the configuration or fine tuning it to work properly? If you provide forum links, or wiki links, I'll read through them. Though I'm looking for experienced members to help guide me through cleaning up my configuration. It just doesn't make sense to me why our Port forwarding isn't working and as a byproduct, I cannot implement other features and trust the configuration to work properly.

I downloaded a CHR for Hyper-V, set it up and am testing the configuration with it this afternoon. Thank you Jarda for the suggestion, I didn't realize this was possible until you pointed it out. Hopefully everything works and I can run the updates soon.

Please remember that you should stick with bugfix channel for production routers.

The problem with NAT, from internal address, is that the answer comes from the wrong IP - all due to the NAT shenanigans. This is my hairpin relevant section:
There are 3 NATs here:

1) UDP ports, from 27000 to 27300. Used to Left 4 Dead servers (an FPS game).
2) UDP ports, from 29000 to 29100. Used to Team Fortress servers (another FPS game).
3) A default src NAT, to default access to the Internet.

How they work:
The first dst-nat forwards Internet traffic, from UDP ports 27000 to 27300, to the internal IP 10.10.2.247

Then we get the hairpin rule. It will do a src-nat, when the destination is the INTERNAL IP of the server (10.10.2.247). The server will see a packet arriving from the router, not from the client who started the connection.
Why? Because it would, then, answer to the client - but this answer would have the internal IP, not the external one. So the client would discard it as invalid.
This way the packet transverses the firewall two times: from client to server, and from server to client.

Take a look ate the second server.
The packets with UDP ports 29000 to 29100 destination are forwarded to the internal server (10.10.2.102). If they are from Internet, that's it. If they are from the intranet, they are src-nated, to look like they come from the router.

Exactly like the first one.

The reference page is quite good:
https://wiki.mikrotik.com/wiki/Hairpin_NAT

Even the chr is amazing and you can do anything with it, don't forget to use partitions and keep previous version to be able to switch immediately back to untouched system with its original working config if whatever happens.

The problem with NAT, from internal address, is that the answer comes from the wrong IP - all due to the NAT shenanigans. This is my hairpin relevant section:

Code: Select all

/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" out-interface-list=WAN
add action=dst-nat chain=dstnat comment=L4D2 dst-address-list=IP_externo dst-port=27000-27300 log-prefix=l4d2 protocol=udp to-addresses=10.10.2.247
add action=masquerade chain=srcnat comment="l4d2 - hairpin NAT (acerta a resposta do servidor)" dst-address=10.10.2.247 dst-port=27000-27300 log-prefix="hairpin masq l4d2" out-interface-list=Intranet protocol=udp src-address=10.10.2.0/24
add action=dst-nat chain=dstnat comment="TF2 port forward" dst-address-list=IP_externo dst-port=29000-29100 log-prefix=tf2 protocol=udp to-addresses=10.10.2.102
add action=masquerade chain=srcnat comment="tf2 - hairpin NAT (acerta a resposta do servidor)" dst-address=10.10.2.102 dst-port=29000-29100 log-prefix="hairpin masq tf2" out-interface-list=Intranet protocol=udp src-address=10.10.2.0/24

There are 3 NATs here:

1) UDP ports, from 27000 to 27300. Used to Left 4 Dead servers (an FPS game).
2) UDP ports, from 29000 to 29100. Used to Team Fortress servers (another FPS game).
3) A default src NAT, to default access to the Internet.

How they work:
The first dst-nat forwards Internet traffic, from UDP ports 27000 to 27300, to the internal IP 10.10.2.247

Then we get the hairpin rule. It will do a src-nat, when the destination is the INTERNAL IP of the server (10.10.2.247). The server will see a packet arriving from the router, not from the client who started the connection.
Why? Because it would, then, answer to the client - but this answer would have the internal IP, not the external one. So the client would discard it as invalid.
This way the packet transverses the firewall two times: from client to server, and from server to client.

Take a look ate the second server.
The packets with UDP ports 29000 to 29100 destination are forwarded to the internal server (10.10.2.102). If they are from Internet, that's it. If they are from the intranet, they are src-nated, to look like they come from the router.

Exactly like the first one.

The reference page is quite good:
https://wiki.mikrotik.com/wiki/Hairpin_NAT

Paternot, Thank you for that information. I'll take a look at my hairpin NAT tonight to see if it matches your suggestions.

I have updated to the latest Firmware 6.43rc21. Everything is stable and running fine. I think I am going to rebuild my NAT rules from the ground up. See if I can isolate why the hairpin NAT is causing so many issues with my port forwarding.

Any advice on hardening the firewall from outside threats? I don't want our system to be hacked. Would like to keep the Public IP locked down, but allow for my IP and VPN connections to be allowed.

Good plan to start with latest OS.
Typically I accept the default setup which is secure and then start modifying slowly USING THE SAFE MODE ( i use winbox ).
That way if you do something destructive you dont have to start from scratch.

Right off the bat what I noticed was this
add action=accept chain=input comment=winbox dst-port=8291 protocol=tcp

WRONG!!! it appears to me that this allows anybody anwhere to connect to your router.
Typically the way to do this is...
add action=accept chain=input in-interface={the LAN interface the admin is typically using} source-address-list=adminaccess
or source-address=192.168.1.0/24 (whatever subnet the admin uses)

In the /ip firewall address-lists (enter in the PCs that will be used by the admin to access the router or perhaps the subnet up to you)
pc1 IP name=adminaccess
pc2 IP name=adminaccess

IN WINBOX turn off all items in
/ip service list except winbox and SSH but change SSH to a different port and set ssh crypto to strong.
/ip ssh set strong-crypto=yes

ON that page you can list the only IPs from the subnet above if not using admin access list or use both for both winbox and ssh entry permission.
Go into packages and disable all the ones not being used.

I tend to prefer DROP all at the end of input chain and forward chain.
In other words 99.9% of rules are only for those things I want to allow.

...Typically I accept the default setup which is secure and then start modifying slowly USING THE SAFE MODE ( i use winbox ).
That way if you do something destructive you dont have to start from scratch.

I am also using WinBox (ver 3.14rc1). What is "Safe Mode" and how do I utilize it? Sounds like a good step towards not breaking the internet while I'm working/making changes.

Right off the bat what I noticed was this
add action=accept chain=input comment=winbox dst-port=8291 protocol=tcp

WRONG!!! it appears to me that this allows anybody anwhere to connect to your router.
Typically the way to do this is...
add action=accept chain=input in-interface={the LAN interface the admin is typically using} source-address-list=adminaccess
or source-address=192.168.1.0/24 (whatever subnet the admin uses)

This was setup before I got here. I'll accept your recommendation and issue those changes ASAP.

In the /ip firewall address-lists (enter in the PCs that will be used by the admin to access the router or perhaps the subnet up to you)
pc1 IP name=adminaccess
pc2 IP name=adminaccess

Is this just under the IP > FIREWALL > ADDRESS LIST? or is this another section of the Mikrotik I could/should be utilizing to make my life easier?

IN WINBOX turn off all items in
/ip service list except winbox and SSH but change SSH to a different port and set ssh crypto to strong.
/ip ssh set strong-crypto=yes

I didn't think about this, but now that I am seeing it. It is an enlightening moment and I completely agree! Implementing ASAP.

ON that page you can list the only IPs from the subnet above if not using admin access list or use both for both winbox and ssh entry permission.
Go into packages and disable all the ones not being used.

I tend to prefer DROP all at the end of input chain and forward chain.
In other words 99.9% of rules are only for those things I want to allow.

How will this effect NAT port forwarding rules? Or will this only effect the WinBox and SSH inbound traffic?

Thank you again, this is exactly the type of information I was hoping to receive from more experience people. I am so grateful for your help.

Properly configured firewall rules should not interfere with NAT rules.
Remember NAT rules at least destination NAT rules are actually FIREWALL RULES For inbound unsolicited traffic being forwarded across the router.
( a destination NAT rule is in my small mind equivalent to saying ALLOW WAN to LAN traffic on port XX to LANIP 192.168.x.yy )

This is the point where I point out that IF POSSIBLE, limit the external access to that PC or server by source address list. If you access or other access it not from fixed IPs then that is not possible. For example I have dst rules for access to my solar panel and septic panel from fixed vendor IPs..........

( a destination NAT rule is in my small mind equivalent to saying ALLOW WAN to LAN traffic on port XX to LANIP 192.168.x.yy )

Not by itself. Destination NAT only changes destination address and/or port, nothing else. You still need to allow packets through firewall filter. But yeah, combined with popular "allow everything dstnatted" rule, it can have described effect.

To illustrate Sobs point so that it becomes practical,
I have a drop everything Firewall Chain concept, where one has to explicitly allow TYPES of traffic, otherwise they are dropped'

examples
input chain
-allow valid traffic (established, etc
-allow admin to access router
-allow lan to access dns on the router
drop everything else

forward chain
-allow valid traffic (established,etc)
-allow lan to wan traffic
-allow ipsec traffic
- allow dsnatted traffic****************
drop everything else

Which does beg a question I do have separate drop invalid traffic rules and am wondering if i still need those????????????

...
Which does beg a question I do have separate drop invalid traffic rules and am wondering if i still need those????????????

It is your choice, if you want invalid to be dropped before any other rules, then yes, if you ok with it being dropped last with the default drop rule, then no

CZFAN, I have lots of wishes and desires but they are emotional entities LOL, in terms of dropping invalid packets,
are you of the camp that says

a. drop invalid first even before established, connected, untracked accept rule ---> but why???
b. drop invalid RIGHT AFTER established, connection, untracked ---> but why????
c. don't include invalid drop rule if you have drop everything at the end.


The question really becomes two fold.
1. LOAD on CPU, is there any difference where in the food chain invalid connections are dropped??? (efficiency to be gained and is it significant)
2. SECURITY, is there an increasing level of risk the longer one waits to drop invalid connections???

So lets focus on facts, and not emotions.

@anav: Connection state of each packet is established OR related OR untracked OR invalid OR new. So your option b) takes care of 4 of 5 at the beginning and any rule after that applies only to "new". Option c) leaves you with "new" and "invalid", so unless you add connection-state=new to following rules, they will apply to both.

@anav, for me personally, it really depends on the direction the wind blows....

At home, where I have a combined number of maybe 10 - 15 rules for both input and forward, I don't really care where I drop it, so drop it in default drop rule. On clients network, which has many, many rules, is a very busy network, etc, I drop it as soon as possible to save on resources

As @CZFan wrote it all ends with router's CPU load. Which is proportional to sum of number of packets times number of FW rules passed (by each packet). To lower CPU load, most frequently matched rules should be at top of list. With one notable exception: drop all at the end. If that last one is executed too frequently, some deep analysis of dropped packets is in place to check if some specific drop rule higher in the chain would be benefitial.

A side note: as the evilness of internet evolves, alert FW administrator would regularly re-evaluate FW rules and their ordering. N.B. I'm not one of alert FW administrators

Thanks CZ, Ive dropped the FAN part because obviously there is too much wind blowing in your area (could be hot gasses?)
Good points and exactly what i was looking for, same same MKX.

Properly configured firewall rules should not interfere with NAT rules.
Remember NAT rules at least destination NAT rules are actually FIREWALL RULES For inbound unsolicited traffic being forwarded across the router.
( a destination NAT rule is in my small mind equivalent to saying ALLOW WAN to LAN traffic on port XX to LANIP 192.168.x.yy )

I looked at the hairpin NAT and disabled it. Enabled a Port Forwarding rule to allow access from FQDN and set A-Record to point to the Public IP. The NAT Port Forwarding is working properly and allowing the internal device to be accessed by the outside world. Praise the maker! This should clean up my NAT rules a little.

examples
input chain
-allow valid traffic (established, etc
-allow admin to access router
-allow lan to access dns on the router
drop everything else

forward chain
-allow valid traffic (established,etc)
-allow lan to wan traffic
-allow ipsec traffic
- allow dsnatted traffic****************
drop everything else

If I was to clean up / configure my NAT Filter Rules, what will I need to do in order to maintain my current Port Forwarding configuration?
I assume I would need to configure an input and forward, connection, accept Filter Rule. But what would it look like?
I have in the past followed the instructions in this wiki article about hardening the access to the Mikrotik. ( https://wiki.mikrotik.com/wiki/Tips_and ... f_RouterOS )
Most of these rules and filters are currently disabled, due to some SIP / VoIP delays we were receiving and I disabled them them as they were, at the time a new addition around the time of the delay and in response I disabled them. But I'd prefer to have the protection if they are correct and I can address the SIP / VoIP priority packet issue.

While my company uses port 80 pretty heavily for all of our web based applications, I'm not sure there is a heavy work load. But I like the concept of dropping packets sooner than later to save on system resources.

Thank you CZFan, Sob, and anav for all of your help. I feel like I am learning a great deal about these Mikrotik routers and how they are or should be configured.
Any reading material or help for setting up VLANs? My next priority will be to establish priority for SIP / VoIP track to and from our phones that also have a data connection for computers.
I think this relates to the Filter Rules and NAT configurations too, because I want to make sure that SIP / VoIP get priority over other packets in order to maintain a high quality audio with no delays.

Thank you Sobs and Anav, for your help in identifying the Hairpin NAT issue. I think this was the main culprit of why my network was acting funny.

Could I get some assistance with configuring a series of VLAN's? I found some information on the forum here viewtopic.php?t=77627 about attaching VLAN's to one or more ports. I certainly do not feel confident in myself yet to do this without more experienced eyes looking at the code or GUI settings before I implement them. I do not understand the difference between untagged and tagged VLANs. As in what it means for the network and the devices on the network to have a untagged/tagged packet.

My current configuration is as follows.

• ISP to ether1
• ether2-5 in a bridge
• ether6-8 unassigned

I only have the default VLAN ID=1 running. I'd like to do the following.

• VLAN ID=10 for LAN DATA
• VLAN ID=20 for WLAN DATA
• VLAN ID=30 for Voice

Have all three VLAN ID's assigned to the Bridge and assign them to ether2-5 port.
I also need to set priority to the Voice VLAN ID=30 so our VoIP does not experience delays of voice packet delivery. I am unclear of how to set priority at the moment.

Topology:
Mikrotik Router

• Port 1: ISP
• Port 2: LAN-Bridge > HPE 1920-24 switch
• Port 3: LAN-Bridge > HPE 1920-24 switch
• Port 4: LAN-Bridge > HPE 1920-24 switch
• Port 5: LAN-Bridge > HPE 1920-24 switch
• Port 6: Empty
• Port 7: Empty
• Port 8: Empty