Port Forwarding firewall rules

[ilja]

Hey all. Can some please help me to setup simple port forwarding which i really don’t get.
Came from D-LINK where it was super simple out-of-box UI and am a little frustrated with Mikrotik firewall settings.

All i need is to do a port forwarding the following way:

WAN(10.10.10.10) — Mikrotik ---- server(192.168.88.10:8123)
So i could access server by going to 10.10.10.10:8123 both locally and externally.

As well as SSH to the server by using 10.10.10.10:733
WAN(10.10.10.10) — Mikrotik ---- server(192.168.88.10:733)

With what i currently have i was able to connect to the server 10.10.10.10:8123, but only externally. It doesn’t work when i m trying that internally over wlan.

[admin@MikroTik] > export hide-sensitive  
# feb/23/2020 17:00:39 by RouterOS 6.46.3
# software id = 63WL-9G9C
#
# model = 2011UiAS-2HnD
# serial number = 467304B1DBAF
/interface bridge
add admin-mac=4C:5E:0C:43:D6:3E auto-mac=no comment=defconf name=bridge
/interface wireless
set [ find default-name=wlan1 ] band=2ghz-b/g/n channel-width=20/40mhz-XX country=sweden disabled=no distance=indoors installation=indoor mode=ap-bridge ssid="The Apartment" wireless-protocol=802.11
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface wireless security-profiles
set [ find default=yes ] authentication-types=wpa-psk,wpa2-psk mode=dynamic-keys supplicant-identity=MikroTik
/ip pool
add name=dhcp ranges=192.168.88.11-192.168.88.254
/ip dhcp-server
add address-pool=dhcp disabled=no interface=bridge name=defconf
/interface bridge port
add bridge=bridge comment=defconf interface=ether2
add bridge=bridge comment=defconf interface=ether3
add bridge=bridge comment=defconf interface=ether4
add bridge=bridge comment=defconf interface=ether5
add bridge=bridge comment=defconf interface=ether6
add bridge=bridge comment=defconf interface=ether7
add bridge=bridge comment=defconf interface=ether8
add bridge=bridge comment=defconf interface=ether9
add bridge=bridge comment=defconf interface=ether10
add bridge=bridge comment=defconf interface=sfp1
add bridge=bridge comment=defconf interface=wlan1
/ip neighbor discovery-settings
set discover-interface-list=LAN
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN
/ip address
add address=192.168.88.1/24 comment=defconf interface=ether2 network=192.168.88.0
/ip dhcp-client
add comment=defconf disabled=no interface=ether1
/ip dhcp-server network
add address=192.168.88.0/24 comment=defconf gateway=192.168.88.1
/ip dns
set allow-remote-requests=yes
/ip dns static
add address=192.168.88.1 comment=defconf name=router.lan
/ip firewall filter
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment="defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN
add action=dst-nat chain=dstnat comment="Raspberry Pi" dst-port=8123 in-interface=ether1 protocol=tcp to-addresses=192.168.88.10 to-ports=8123
/system clock
set time-zone-name=Europe/Stockholm
/system routerboard settings
set auto-upgrade=yes cpu-frequency=700MHz silent-boot=yes
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN

[chuckt]

Just use the local IP inside the LAN

192.168.88.10:8123

Alternatively you might be able to use “hairpin NAT” or loopback.

[ilja]

Just use the local IP inside the LAN

192.168.88.10:8123

Alternatively you might be able to use “hairpin NAT” or loopback.

Thank you, @chuckt, for your answer. I would still want/need to make it work internally with the same public ip(it’s more of a domain).

Thank you for referring to Hairpin NAT, i looked at https://wiki.mikrotik.com/wiki/Hairpin_NAT and tried:

/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN
add action=dst-nat chain=dstnat comment="Raspberry Pi" dst-port=8123 in-interface=ether1 protocol=tcp to-addresses=192.168.88.10 to-ports=8123
add action=masquerade chain=srcnat dst-address=192.168.88.10 dst-port=8123 protocol=tcp src-address=192.168.88.0/24 src-port=8123

But it doesn’t work.

[anav]

For port forwarding you need to make a dst nat rule for each port forwarding you would like to accomplish.
To allow port forwarded traffic through the firewall, a single FORWARD chain rule needs to be in place.
The default firewall rules already contain this rule last time I checked.

Quite separately from above which is external access, in internal access.
To be able to access the server via the WANIP address I believe there are two viable methods to do this./

1. Via hairpin nat - the official prescribed way. Works very well and covers a wide range of possibilities (most comprehensive).
2. Via static DNS ENTRY - believe this may be easier, work for most cases.
   
   
   hairpin the packets go to the router and back to the server when server is accessed from the LAN
   DNS, the packets go direct to the server when the server is accessed from the lan.

[ilja]

For port forwarding you need to make a dst nat rule for each port forwarding you would like to accomplish.
To allow port forwarded traffic through the firewall, a single FORWARD chain rule needs to be in place.
The default firewall rules already contain this rule last time I checked.

Quite separately from above which is external access, in internal access.
To be able to access the server via the WANIP address I believe there are two viable methods to do this./

1. Via hairpin nat - the official prescribed way. Works very well and covers a wide range of possibilities (most comprehensive).
2. Via static DNS ENTRY - believe this may be easier, work for most cases.
   
   
   hairpin the packets go to the router and back to the server when server is accessed from the LAN
   DNS, the packets go direct to the server when the server is accessed from the lan.

Thank you, @anav, for you reply. I like the idea of the first option - to do it correctly. Could you please take a look on my previously posted message, where i have attempted setting up Hairpin NAT according to the manual, but missed something? Maybe you would be able to help spotting it

[Sob]

Copy & paste from another thread:

You can’t have dstnat rules with in-interface=ether1, they can’t work from inside, because connections will be coming from LAN interface. The best is dst-address=, but if it’s dynamic, you can use dst-address-type=local instead and it will match all local addresses. In case you need those ports also on router, e.g. for management from LAN using WebFig, add additional dst-address=!<192.168.1.x> as exception (where 192.168.1.x is router’s local address; don’t forget “!” which means “not”).

[ilja]

Copy & paste from another thread:

You can’t have dstnat rules with in-interface=ether1, they can’t work from inside, because connections will be coming from LAN interface. The best is dst-address=, but if it’s dynamic, you can use dst-address-type=local instead and it will match all local addresses. In case you need those ports also on router, e.g. for management from LAN using WebFig, add additional dst-address=!<192.168.1.x> as exception (where 192.168.1.x is router’s local address; don’t forget “!” which means “not”).

That’s exactly what i have tried setting, but with no luck

/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN
add action=masquerade chain=srcnat comment="hairpin nat" dst-address=!192.168.88.1 dst-port=8123 protocol=tcp src-address=192.168.88.0/24 src-port=8123
add action=dst-nat chain=dstnat comment="Raspberry Pi" disabled=yes dst-port=8123 in-interface=ether1 protocol=tcp to-addresses=192.168.88.10 to-ports=8123
add action=dst-nat chain=dstnat dst-address=!192.168.88.1 dst-address-type=local dst-port=8123 protocol=tcp to-addresses=192.168.88.10 to-ports=8123

[anav]

Sob, I got confused reading your cryptic reply lol.
What about Stevocee’s basic approach to hairpin nat for dynamic IP.

Step 1. Add a second masquerade rule and put that as the first rule in the NAT chain. (as we want to capture lan to lan traffic before any real lan to wan traffic).

/ip firewall nat
add chain=srcnat src-address=192.168.1.0/24 dst-address=192.168.1.0/24
action=masquerade comment=“Hairpin Nat”
(assuming that we have one subnet and the server is also on that subnet)

Step 2 . The dynamic IP doesn’t allow us to use destination address as it changes (dst- address works better in the dst-nat rule then the usual In-interface=wan because now we are trying to handle both incoming from WAN and incoming from LAN instances.). A static IP address would be dirt simple and we would be done already.
The idea here is to use IP Cloud!!
(1) a. enable ip cloud
b. put in current WANIP and
c. capture the DNS name given

(2) a. create a firewall address list called MYWANIP and use the name from c. above for the address entry.
b. now modify the current dst-nat port forwarding rule ----> remove in-interface=wan and use destination address-list and put in the MYWANIP entry.

So this would look like. ILJA try this…
/ip firewall nat
add action=masquerade chain=srcnat comment=“HairpinNAT” src-address=192.168.88.0/24 dst-address=192.168.88.0/24 (new rule)
add action=masquerade chain=srcnat comment=“NAT” out-interface=WAN (standard rule)
add action=dst-nat chain=dstnat comment=“Server RPi” dst-port=8123 protocol=tcp dst-address-list=MYWANIP to-addresses=192.168.88.10 (modified standard rule)

Done and simple!

Question. Is there not a case where DNS is a better option?
I seem to recall there are two cases to consider
a. where one is attempting to reach the server when its on the same subnet as the server and
b. where one is attempting to reach the server from a different subnet but still behind the router etc…

[anav]

That’s exactly what i have tried setting, but with no luck

/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN
add action=masquerade chain=srcnat comment="hairpin nat" dst-address=!192.168.88.1 dst-port=8123 protocol=tcp src-address=192.168.88.0/24 src-port=8123
add action=dst-nat chain=dstnat comment="Raspberry Pi" disabled=yes dst-port=8123 in-interface=ether1 protocol=tcp to-addresses=192.168.88.10 to-ports=8123
add action=dst-nat chain=dstnat dst-address=!192.168.88.1 dst-address-type=local dst-port=8123 protocol=tcp to-addresses=192.168.88.10 to-ports=8123

To many rules depending on which method you use and probably some in conflict and order is important.

First rule should be new masquerade rule!
Second rule is the standard masquerade rule to cover lan to wan traffic
Only one NAT RULE is required for destination NAT you seem to have two???
If you like the ugly and confusing second dst nat rule with local address with ! , I would bet this rule has to come before the standard dst nat rule in the order.

[chuckt]

@anav

This IP Cloud looks interesting, but when I look at the documentation I see this note:

Note: IP/Cloud requires a working license on Cloud Hosted Router (CHR).

I’m not sure what this CHR is. Is that something we can setup through Mikrotik, or is that some 3rd party?

NVM:
I used my Google Fu and found that the service is available for download through Mk and the license is free up to 1Mbps upload per interface.

[chuckt]

@ilja

I don’t know if you have it working yet, but I looked at your exports and I don’t see where you’ve done what’s in the Wiki link for Hairpin NAT.

Did you try it as documented there? Also, do you have a dynamic IP form your ISP?

[Sob]

@ilja: This:

/ip firewall nat
add action=masquerade chain=srcnat comment="hairpin nat" dst-address=!192.168.88.1 dst-port=8123 protocol=tcp src-address=192.168.88.0/24 src-port=8123

is wrong. The src-port=8123 is complete nonsense, it shouldn’t be there. If you remove it, it will work, but can affect some traffic it shouldn’t, so better use @anav’s:

/ip firewall nat
add action=masquerade chain=srcnat comment="HairpinNAT" src-address=192.168.88.0/24 dst-address=192.168.88.0/24

It’s universal rule, common for all ports, so if you add another forwarded port in future, you won’t need to add another srcnat rule.

@anav: DDNS method is not wrong and it will work, but it’s not ideal, because there will be always a short period when router already has new address, but there’s still old one in address list, so port forwarding won’t work until current address list entry expires. If you want to use dst-address with dynamic address, use dhcp lease script to update it. Only case when you can’t avoid using DDNS is when you need hairpin NAT with double NAT and your router is the second one without public address.

Edit: One more, if you have:

/ip firewall nat
add action=masquerade chain=srcnat comment="HairpinNAT" src-address=192.168.88.0/24 dst-address=192.168.88.0/24
add action=masquerade chain=srcnat comment="NAT" out-interface=WAN

then the order doesn’t matter, because it will never happen that both these rules would match for same packet (unless you come up with some creative misconfiguration). When 192.168.88.0/24 is your LAN, out-interface for first rule will be always LAN. In fact, it’s better to have main NAT first, because vast majority of connections will be from LAN to internet and only few hairpin ones from LAN back to LAN. So by having main NAT first, you’ll save 0,00nothing% resources (not much, but still > 0).

[anav]

Hi Sob, thanks for the clarifying info and the delay between address update and IP change cannot really be that significant…?

[Sob]

I don’t remember what TTL MikroTik’s DDNS uses, I think it was only a minute, so not really a problem, but why not make things perfect when you can?

[mkx]

I don’t remember what TTL MikroTik’s DDNS uses, I think it was only a minute …

Yup, 60 seconds.

[anav]

Okay Sob, I am game, will go on your merry go round and hope I dont puke…

So lets say we agree on the first two source nat rules…
/ip firewall nat
add action=masquerade chain=srcnat comment=“HairpinNAT” src-address=192.168.88.0/24 dst-address=192.168.88.0/24
add action=masquerade chain=srcnat comment=“NAT” out-interface=WAN

Then we can debate having ONE DST NAT RULE aka Stevee’s method Or
Doing it via two rules without the need for IP cloud

Would this be correct??
add action=dst-nat chain=dstnat comment=“PF- From WAN” dst-port=8123 protocol=tcp in-interface=ether1 to-addresses=192.168.88.10
add action=dst-nat chain=dstnat comment=“PF- From LAN” dst-port=8123 protocol=tcp dst-address=!192.168.88.1
dst-address-type=local to-addresses=192.168.88.10

As per the source nat rules, would it be fair to say, order does not matter?

[Sob]

One dstnat rule is enough. Look closely at the options, your “PF- From LAN” rule will work for both connections from LAN and WAN, there’s no need to have the other one (“PF- From WAN”) as extra rule. And I already explained how it is with order of srcnat rules, just scroll a little bit back.

[anav]

Well I never…hmmmmmmm You cant be right
Okay here is where I lose it… the destination address type is where I get confused never having usied this line/parameter.

Okay here is what I think your are doing, (must have a unicorn on your head).
The destination address bit covers any external incoming attempt at destination nat to that port.
The local address bit covers any internal coming attempt of destination nat to that port BUT HOW>>>>>>>>>>>??

Nope thats not right either… egads feel like a pretzel.
Okay from the end user perspective sure, the destination part of the rule works.
Regardless of source of request two things are true, attempt is made to connect to WANIP on that port or to connect to any IP other than that described by the LAN.
( seems wide open and a security concern to me… just a gut feeling LOL )

But what is the purpose of the second bit, the local address bit???

AHH OKAY, so local means - local - if dst-address is assigned to one of router’s interfaces

In other words, one is stating, for any destination nat request targetting port 8123 that is destined for or being directed at ANY IP address that can be described as:
a. any IP except that coming from the LAN (as I stated not a good idea not secure) and
b. that destination IP described at a., HAS TO BE assigned one of the routers interfaces (which includes wan - and thus where we get security back)

You are a tricky soul mr sob!!
If I had to buy you a case of beer every time you were right, you would be on your third liver transplant!!

[Sob]

It’s not ideal, but not necessarily insecure either. Yes, dst-address-type=local will match any address on router, except 192.168.88.1, which we excluded using dst-address=!192.168.88.1, because we want to keep it for accessing services on router like WinBox, WebFig and such (well, probably not on port 8123, but generally we don’t want to forward connections to 192.168.88.1 elsewhere).

So if there is another address on router, it could be for example 192.168.99.1 used by VPN server or another LAN, connection coming from internet to this address will be also forwarded to internal server. But is that a problem? Most likely not. The goal is to forward port from public address to internal server, so anyone can use the public address to reach it, and this other, much more complicated way to reach the same server doesn’t make a difference.

But if you don’t like it, you can exclude also other addresses if you use dst-address-list=!. If you know that you’ll have public address directly on router, you can add whole 192.168.0.0/16 and other local ranges.

Or if you want it completely clean, then use only dst-address= as if it was static and keep it updated using lease script. You can use the same simplified way as with routes (http://forum.mikrotik.com/t/dual-dynamic-isp-wan-dual-lan-setup/132893/5).

[ilja]

Hey, gentleman.

Thank you so much for all your comments and help! Unfortunately, i have been a little caught up with work the past week. Will try to implement all your recommendations during the weekends and get back to you.
Thank you!