Clearing up some gray areas with my current NAT rules.

RouterOS Beginner Basics
1

I’m digging around in an effort to get more of a firm grasp on appropriate setups for port forwarding. The current situation is using a HEX750 as my main router. I have a web server running Apache that I’d like to access both internally and externally. With my current setup I have it working, but I question if I have it set up in the most appropriate manner. I feel like Mikrotik gives you enough rope to hang yourself, so this has me interested in making sure that not only are things working but they are set up correctly. It’s also worth noting that I have a dynamic IP from my ISP, so I’ve found myself hesitant to just plug in my (current and of course temporary) IP into my rules since we all know that may inevitably change in the future.

Currently my forward rule list is as follows:

 0    ;;; defconf: masquerade
      chain=srcnat action=masquerade out-interface=ether1-WAN 

 1    ;;; Hairpin NAT
      chain=srcnat action=masquerade src-address=192.168.0.0/24 dst-address=192.168.0.0/24 

 2      chain=dstnat action=dst-nat to-addresses=192.168.0.21 to-ports=443 protocol=tcp dst-address-type=local dst-port=443 log=no log-prefix="" 

 3      chain=dstnat action=dst-nat to-addresses=192.168.0.21 to-ports=80 protocol=tcp dst-address-type=local dst-port=80 log=no log-prefix=""

The curious part comes in with the fact that I do not have in-interface set. Many guides suggest to use this. Whenever I employ it, I lose connection to these services internally. Likewise, I also have dst-address-type=local set, which I’ve only managed to find on one guide so far, yet the other ~20 guides have neglected to mention this. Given the magnitude of folks not using dst-address-type=local and replying back that everything is working, it raises an eyebrow. I’m sure we all have different setups, but some of these cases did not sound complex at all and some suggested they were very similar to mine.

My understanding from dst-address-type=local is “Basically that means if the dst-address is “local” to the router (e.g. it is assigned to one of the interfaces on the router).” (quoted from another user on here). The server in question is not directly connected to the Mikrotik router. The only thing connected to the Mikrotik router is WAN (ether1) and LAN (ether2), where LAN/ether2 goes to a larger network switch. Perhaps I’m splitting hairs and that’s still considered directly connected, but the exact verbosity of that quote had me curious.

A video guide from another user that was linked here on the forums suggested the importance of setting in-interface, and even went as far as to say “without it you’ll have all sorts of routing problems.” I haven’t had much luck with setting in-interface and having things remain in working order, so there’s another eyebrow raise.

Lastly, I understood that the Hairpin NAT was to work cohesively with my forwarded ports, to the point I could just forward ports with dstnat as the vast majority of the documented examples provided and the hairpin would be the “gotcha” that makes them also work internally. Despite this, I’m still finding I need to tailor things a bit outside of what most examples provide (dst-address-type=local, lack of in-interface being set, etc). Perhaps this is par for the course with different setups, but like I said, I was curious enough to keep looking.

Anyway I guess I’m asking if someone here would have any advice for me as a pretty new Mikrotik user. I’m not really built to just “accept things as is” without understanding what they are doing. My current list of rules above seem to work fine (such as my web server working both internally and externally), but not having a firm grasp on the ‘why’ took me through many guides, and ultimately, here to ask.

Thanks ahead of time for any insight!

2

the importance of setting in-interface

If your port mapping is not one-to-one (8080 → 80) you’ll have issues if you don’t set the in-interface to be your WAN interface.

I challenge anyone to best these rules! Study them carefully, and be enlightened.


# Hairpin and Standard port forwarding example
# 10.1.0.1 is the router
# 10.1.0.2 is an internal server needing Hairpin
# 10.1.0.3 is an internal server serving outside traffic 

/ip firewall filter
add chain=input action=accept connection-state=established,related comment="Allow established related"
add chain=input action=accept in-interface=bridge-LAN comment="Allow LAN access to router and Internet"
add chain=input action=drop   comment="Drop all other input"

add chain=forward action=accept connection-state=established,related comment="Allow established related"
add chain=forward action=accept connection-state=new in-interface=bridge-LAN comment="Allow LAN access to router and Internet"
add chain=forward action=accept connection-nat-state=dstnat comment="Allow Port forwards"
add chain=forward action=drop   comment="Drop all other forward"

/ip firewall nat
add chain=srcnat action=masquerade out-interface=ether-WAN  comment="Default masq"

# Hairpin port forward
add chain=srcnat action=masquerade out-interface=bridge-LAN dst-address=!10.1.0.1 src-address=10.1.0.0/24 comment="Hairpin"
add chain=dstnat action=dst-nat    dst-address-type=local   dst-address=!10.1.0.1 to-addresses=10.1.0.2   dst-port=80 to-ports=80 protocol=tcp comment="Hairpin"

# Standard Port forward
add chain=dstnat action=dst-nat in-interface=ether-WAN protocol=tcp to-addresses=10.1.0.3 dst-port=123 to-ports=123 comment="Sample Port Forward"
3

@pcunite: So if you’d want to forward e.g. external port 8080 to internal 80, and you’d want it work also from inside, you’d have two rules like this?

/ip firewall nat
add chain=dstnat action=dst-nat protocol=tcp dst-port=8080 to-addresses=10.1.0.2 to-ports=80 \
    dst-address-type=local dst-address=!10.1.0.1
add chain=dstnat action=dst-nat protocol=tcp dst-port=8080 to-addresses=10.1.0.2 to-ports=80 \
    in-interface=ether-WAN

Why? The first one works just fine also for connections from internet.

To OP, the reason why many guides insist on in-interface is because they don’t care about hairpin NAT. Either they’re happy with just external functionality, don’t know about dst-address-type=local (and it “broke their internet” when they tried to forward common port like 80 without any destination specification), or they use local DNS for accessing internal server. In a way, using DNS is more clean solution, but it’s harder to maintain (you need to keep DNS setting up to date) and doesn’t work if there’s no DNS (with direct connection to numeric address). Hairpin NAT is sort of a hack, but extremely convenient, set & forget it, and it works for everything.

Also, just in-interface= without any specification of address is not exactly correct. It works fine in most cases, because most cases is just one public addres. But do it on router which also has another subnet routed to in and it will match connections to any of those addresses.

4

Hm, I see. Thanks for that explanation. I do have a static DNS entry set up for my web server, however I suppose that’s a far more mild beast to the DNS setup you’re referring to. Likewise I have a number of ServerName etc entries in my Apache config which seems to reroute what the URL looks like if I even try to hit the server via it’s local-host-name/cloud as opposed to official-domain-name/cloud when internal.

Can I ask for you to elaborate on one point? The “it broke my internet” regarding the dst-address-type=local without a destination designation part. You’re simply referring to what local IP that port would be forwarded to, right? I’m trying to read into that and see if that was part of what I ran into with the Mikrotik. I couldn’t access the Mikrotik webfig at first because I had set up 80 and 443 to my web server. I ended up just changing the http port on the Mikrotik and all the issues went away, but I questioned if your remark was along the same vein of what I ran into.

I guess part of my hesitancy with my config I posted above was the lack of certainty as to whether or not it was in some capacity correct. Since I’m trying to experiment and test things out as much as possible, I was trying to iron out if the config appears good or if I was doing this in some wild outlandish way. The last thing I’d want to do is assume what i’m doing is right (since it functions) and find out later I was borking it the whole time. :stuck_out_tongue: That explanation helps. :slight_smile:

5

The “DNS way” works by using different DNS records for local clients. Lets say you’re running www.example.com and the A record for that points to your WAN address 1.2.3.4. If you don’t want to use hairpin NAT, you can do (or set it somewhere else, if you don’t use router as resolver):

/ip dns static
add address=192.168.0.21 name=www.example.net

But it has some downsides. When you add another site, you need to add another record. Then when you stop hosting some site and move it elsewhere, you need to remove its record. You must also make sure that all devices in your LAN use your DNS resolver. Because if they don’t (e.g. have manually set 8.8.8.8 or something), they will get WAN address 1.2.3.4 and the website won’t work for them. Then there are cases when DNS is not used. It’s probably not a problem with web, but some other services might use numeric address. I don’t have any good example right now, but it’s possible.

With hairpin NAT, you have none of those problems. You add one universal rule and live happily ever after. Of course nothing is perfect, the traffic needs to go to router and then back to LAN, which is less effective than direct connection to server. So I’d suggest to combine both. By default, use hairpin NAT and if you know that some specific site will be used heavily, add DNS record for it.

“Broken internet” was slightly different. Some people will start with just:

/ip firewall nat
add chain=dstnat action=dst-nat protocol=tcp dst-port=80 to-addresses=192.168.0.21

And guess what happens. Their webserver is visible from outside, but they have no time to appreciate that, because they can’t access anything on internet themselves. Dstnat rule matches also any outgoing connection to port 80 and redirects it to internal server (but it doesn’t work either, when there’s no hairpin NAT). And because dst-address-type=local is less known, they are likely to solve it using in-interface=.

Not being able to access services on router using same port as forwarded one is different problem. If you add:

/ip firewall nat
add chain=dstnat action=dst-nat dst-address-type=local protocol=tcp dst-port=80 to-addresses=192.168.0.21

Then it matches not only WAN address but also router’s LAN address. The solution is to exclude it by adding dst-address=!192.168.0.1. Then the rule matches any local address, except that specific one.

6

Ahh, I remember that now. I remember reading about !192.168.x.x in some guide. For kicks I just set my Mikrotik http port back to 80 just to instigate the issue. After I clearly saw the issue I added a dst-address of !my.mikrotik.router.ip and bingo, seemed to be better just as you said. This is coming back to me now from what I experienced before. In this particular instance I wasn’t able to hit the Mikrotik webfig at all though. It would just auto-resolve to my web server which I believe is different than what I ran into before. I still had connectivity to web sites though, it was just the webfig I couldn’t hit. Last time I think I basically forwarded my Mikrotik webfig login UI to the world, and instead it was the web server that wasn’t accessible at the time. I’m not sure what I had set then compared to now (been a while), but I think that was the order it went in. At any rate, it makes more sense. I guess depending on the flow of settings you just may (accidentally) dictate that a particular device (web server in my recent case I just tested) just sucks up all of the traffic on that port.

It’s good to know that the local setting is simply lesser known. When I was seeing how infrequently it was coming up in my search results I began to question if that approach was less “proper” and wondered if there was a better way to go about that.

Thanks for all the info provided here. Definitely appreciate your time!

7

Those aren’t my rules. Mine are shown below. The first hairpin reference is generic and applies to anything coming from the bridge (as opposed to incoming from WAN). It works for any other NAT rules that might follow (that you want to hairpin). Then I have the specifics rule for different hairpins. Are you saying that one rule can work to allow hairpin?


/ip firewall nat
add chain=srcnat action=masquerade out-interface=ether-WAN  comment="Default masq"

# Allow hairpin port forwards
add chain=srcnat action=masquerade out-interface=bridge-LAN dst-address=!10.1.0.1 src-address=10.1.0.0/24 comment="Hairpin"

# Port forward with HairPin support
add chain=dstnat action=dst-nat dst-address-type=local dst-address=!10.1.0.1 to-addresses=10.1.0.2 dst-port=80 to-ports=80 protocol=tcp comment="Hairpin"

# another
add chain=dstnat action=dst-nat dst-address-type=local dst-address=!10.1.0.1 to-addresses=10.1.0.2 dst-port=90 to-ports=90 protocol=tcp comment="Hairpin2"
8

I took these from your first post:

# Hairpin port forward
add chain=dstnat action=dst-nat    dst-address-type=local   dst-address=!10.1.0.1 to-addresses=10.1.0.2   dst-port=80 to-ports=80 protocol=tcp comment="Hairpin"

# Standard Port forward
add chain=dstnat action=dst-nat in-interface=ether-WAN protocol=tcp to-addresses=10.1.0.3 dst-port=123 to-ports=123 comment="Sample Port Forward"

and just changed port numbers and addresses, and rearranged the order of options, to better see the difference between them. So they sort of are your rules, or lets say descendants, or at least strongly inspired by your rules. You see that the only difference is “dst-address-type=local dst-address=!10.1.0.1” vs. “in-interface=ether-WAN”. Clearly, the latter can’t work for hairpin, because the connection won’t be coming from ether-WAN. But the former will work from outside, because both conditions are satisfied, destination address will be public one on WAN, which is local and not 10.1.0.1. If you’d have them in the order I posted, all hits would be taken by first one, and the other would have none (under normal conditions; unless you connected to 10.1.0.1 from outside).

In short, one dstnat rule for both internal and external connections is enough.

9

Okay, I get you now. Because my default masquerade specified an interface, I required the rule for the local interface. Please edit my rules down to a fully working example.


/ip firewall filter
add chain=input action=accept connection-state=established,related comment="Allow established related"
add chain=input action=accept in-interface=bridge-LAN comment="Allow LAN access to router and Internet"
add chain=input action=drop   comment="Drop all other input"
add chain=forward action=accept connection-state=established,related comment="Allow established related"
add chain=forward action=accept connection-state=new in-interface=bridge-LAN comment="Allow LAN access to router and Internet"
add chain=forward action=accept connection-nat-state=dstnat comment="Allow Port forwards"
add chain=forward action=drop   comment="Drop all other forward"

/ip firewall nat
add chain=srcnat action=masquerade out-interface=ether-WAN  comment="Default masq"

# Hairpin port forward, 10.1.0.1 is the router
add chain=dstnat action=dst-nat dst-address-type=local dst-address=!10.1.0.1 to-addresses=10.1.0.2 dst-port=80 to-ports=80 protocol=tcp comment="Hairpin"
10

I’m not sure if we completely understand each other.

You want to keep your other masquerade rule, that’s what makes hairpin work. Even though it would be possible to do this:

/ip firewall nat
add chain=srcnat action=masquerade src-address=10.1.0.0/24 comment="Universal all in one masquerade"

and it would work for both internet access and hairpin. But it would also affect other traffic (e.g. if you’d have some VPN), and you’d need other rules (with action=accept before this one) to exclude it from masquerade. So personally I’d just keep two rules, one for main NAT and other for hairpin (like you had it before), it seems easier to understand to me.

What I was talking about was the dstnat part. If you use rule with in-interface=, it can only work from outside, and you’d have to add another to make it work also from inside. OR, and that was the point, just use only the “inside” one, because it’s also good for outside.

11

Ahhh, gotcha. Yeah I was doing a in-interface=ether-WAN on what I was calling “standard” port forwarding as opposed to Hairpin rules. Thank you, good point.