Simple port forward help needed

dkong · Tue Dec 20, 2022 10:42 am

Hello Mikrotik Forum,

I need some help with a simple port forward. Please see the diagram below:

The ISP modem is configured as a bridge. R1 (Mikrotik CCR2004-16G-2S+) has ether16 as the WAN interface and is receiving a public IP on that. I can ping the public IP.

In VLAN 12, there is a client (10.2.12.10) listening on port 5001. In the internal networks, the client is reachable on this port. I configured port forwarding as explained in the Mikrotik docs, and I also read through some topics with other folks having issues, looking for inspiration. As far as I can tell, my config is correct. I must be missing something.

Could someone please provide some assistance?

[admin@R1] > /export
# dec/20/2022 09:28:48 by RouterOS 7.5
# software id = EVY1-NYQ3
#
# model = CCR2004-16G-2S+
# serial number = XXXXXXXXXXX
/interface/list/export
/interface list
add name=WAN
add name=PRIV
add name=CAM
add name=GUEST
add name=WIFIMGT
add name=UNTRUSTED
/interface list member
add interface=vlan10-int list=PRIV
add interface=ether16 list=WAN
add interface=vlan12-int list=CAM
add interface=vlan20-int list=GUEST
add interface=vlan13-int list=WIFIMGT
add interface=vlan12-int list=UNTRUSTED
add interface=vlan13-int list=UNTRUSTED
add interface=vlan20-int list=UNTRUSTED

/ip address/export
/ip address
add address=10.2.10.254/24 interface=vlan10-int network=10.2.10.0
add address=10.2.12.254/24 interface=vlan12-int network=10.2.12.0
add address=10.2.20.1/24 interface=vlan20-int network=10.2.20.0
add address=10.2.13.254/24 interface=vlan13-int network=10.2.13.0

/ip firewall/export
/ip firewall address-list
add address=10.0.0.0/8 list=rfc1918
add address=172.16.0.0/12 list=rfc1918
add address=192.168.0.0/16 list=rfc1918
add address=0.0.0.0/0 list=any
/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="allow any from vlan10-int to any" in-interface=vlan10-int
add action=accept chain=input comment="allow ICMP from vlan12-int to vlan12-gw" dst-address=10.2.12.254 in-interface=vlan12-int protocol=icmp
add action=accept chain=input comment="allow ICMP from vlan13-int to vlan13-gw" dst-address=10.2.13.254 in-interface=vlan13-int protocol=icmp
add action=accept chain=input comment="allow ICMP from vlan20-int to vlan20-gw" dst-address=10.2.20.1 in-interface=vlan20-int protocol=icmp
add action=accept chain=input comment="allow ICMP from WAN to WAN-interface" in-interface-list=WAN protocol=icmp
add action=accept chain=input in-interface=zerotier1
add action=drop chain=input comment="implicit deny"
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related hw-offload=yes
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
add action=accept chain=forward in-interface=zerotier1
add action=drop chain=forward comment="drop any from UNTRUSTED to rfc1918" dst-address-list=rfc1918 in-interface-list=UNTRUSTED
add action=accept chain=forward comment="accept any from UNTRUSTED to internet" dst-address-list=any in-interface-list=UNTRUSTED
add action=accept chain=forward comment="accept any from vlan10-int to any" dst-address-list=any in-interface=vlan10-int
add action=drop chain=forward comment="implicit deny"
/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 dst-port=5001 in-interface-list=WAN protocol=tcp to-addresses=10.2.12.10

mkx · Tue Dec 20, 2022 12:20 pm

So if you try to connect to port 5001 from WAN (e.g. by using mobile subscription) you fail to do so? Do counters of dst-nat increase? It is possible that your ISP doesn't transparrently pass traffic to your router ...

Or is it that you're testing connectivity "from inside" but using WAN IP address? For that you need to implement hairpin NAT.

dkong · Tue Dec 20, 2022 1:02 pm

Thanks for your reply mkx. It's no hairpin scenario, I'm testing via 4G and from a VM at another location.

I thought I ruled out most ISP-related things because I can ping the WAN-interface on its public IP, but you never know. I got different sites with the same service type of the same ISP working in similar setups though. Just not with Mikrotik, I used to use PfSense everywhere, this is the first location where I'm giving Mikrotik a go.

I had to look up how to show the counters. They are increasing with additional tries, at least that's a positive indication. Do I need to do something with my filter rules or is a dst-nat rule usually enough?

[admin@R1] /ip/firewall/nat> print stats
Columns: CHAIN, ACTION, BYTES, PACKETS
# CHAIN   ACTION           BYTES  PACKETS
;;; defconf: masquerade
0 srcnat  masquerade  22 439 949  172 249
1 dstnat  dst-nat         11 696      208

mkx · Tue Dec 20, 2022 1:23 pm

Seeing dst-nat counter increase prooves that "forward" traffic is indeed hitting MT. I still wonder about return traffic though. src-nat rule somehow "pulls" return traffic towards MT ... it should pass MT anyways, but doesn't seem to happen without it. Hence my question about routing between PFsense and MT. Without clearing this piece of puzzle I don't see how I could help any further.

dkong · Tue Dec 20, 2022 2:00 pm

PfSense is not in scope of the issue at hand. PfSense is what I've used at other small businesses. The diagram in the first post shows all that is relevant, so from a routing perspective, it's just a Mikrotik with a port forward.

All other topics I've found in this forum just mention the dst-nat rule and nothing else. Those examples are mostly home users though, with a single LAN subnet. My configuration is slightly more complex, so I'm wondering if the filtering is messing things up, but I can't see it.

dkong · Tue Dec 20, 2022 2:28 pm

I tried an additional test, to rule out any misbehavior of the client 10.2.12.10. I added an additional client (just a laptop with tiny server, a simple windows web daemon). I forwarded port 80 the new client.

The test above gives me the same behavior: the hits show on the NAT rule in the Mikrotik router, but the traffic is not coming through. I listened with WireShark on the windows client, and I don't see any incoming requests either. This shows that traffic is not passing through the Mikrotik, so requests are not ever reaching internal clients through the port forwards. So it's not related to return traffic.

mkx · Tue Dec 20, 2022 4:14 pm

I hate when browser can't connect forum server when I try to post something meaningfull and I have to do it all over again

I got slightly distracted by another thread with similar contents, so I'm sorry about ny fuzzy previous post.

Anyway, here's what happens:

/ip firewall filter
...
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
...
add action=drop chain=forward comment="implicit deny"

The incoming packet gets past the first quoted rule (because it actually doesn't match all selection criteria, the failing one is connection-nat-state=!dstnat), but the second one drops it brutally. BTW, the coment of the last rule is wrong, it should say "explicit deny" ... each chain has an implicit allow rule built in (if a packets passes past the last explicit rule, it's accepted).

If you want to stick to "drop everything else" concept (which is perfectly fine), you'll have to rewrite the rest of rules to explicit accepts. The first quoted rule would then look something like this:

add action=accept chain=forward comment="accept DSTNATed from WAN" connection-nat-state=dstnat connection-state=new in-interface-list=WAN

Similarly for the rest of rules. Keep in mind that rules are evaluated top-to-bottom (inside appropriate chain) and first rule matching executes action and stops processing. Which means that likely bulk of drop rules are not necessary due to the last (brutal) rule.

anav · Tue Dec 20, 2022 5:51 pm

Yeah but his rules are full of so much extra crap useless crap that its not surprizing they get in the way of seeing the flaws........

This should do it.
from:
add action=accept chain=forward comment="accept DSTNATed from WAN" connection-nat-state=dstnat connection-state=new in-interface-list=WAN
change it to
add action=accept chain=forward comment="allow port forwarding" connection-nat-state=dstnat
add action=accept chain=forward in-interface-list=LAN out-interface-list=WAN { If required }
add action=drop chain=forward comment="drop all else"

ewu2030 · Thu Dec 22, 2022 9:51 am

I had a similar issue for years on my mikrotik with port forwarding. Apparently mine did not work because my main router network was 10.0.0.0/8 and so was the network of the ISP. My return would hit the gateway of the ISP instead of the router so the traffic was not coming back.
I "solved" it by creating a 192 network for that particular ftp on a secondary network card in the device, and it works like a charm.
Not sure if this is your case, but it bothered my for 3+ years until I solved it, so you might give it a try (especially since the inbound traffic seems to hit your nat rule properly)

mkx · Thu Dec 22, 2022 11:11 am

... mine did not work because my main router network was 10.0.0.0/8 and so was the network of the ISP.

Makes me wonder if something else did not work ... basic networking knowledge says that subnets present on any router's interfaces should not overlap or else router can't get to routing decission without any doubt. And using rfc1918 addresses (e.g. 10/8) is no other. These addresses are different than the rest only "philosophically" because they are set to be "non-routable" via public internet. Nothing about passing addresses across a single router (unless admin blocks them some way or another).
BTW, it makes me wonder why "main router network" has to be so huge (10/8 gives 16 million IP addresses ... network so huge will drown in broadcast traffic alone).

What OP's exercise shows (as well as previous post by @ewu2030) is that it is necessary to know some networking basics and understand some of router's inner workings if one starts configuring things beyond bare basics (where QuickSet actually helps).

dkong · Thu Dec 22, 2022 7:16 pm

@ewu2030: the scenario you describe is different, as mkx explained. In my case, there is a public subnet right to the WAN interface of my own router, so such routing issues as you describe are not happening here.

Thanks a lot to mkx and anav for the insights on the forwarding rules, it's much appreciated. I didn't understand the relationship between NAT and forwarding rules. For now, I have the port forward working by just making a simple adjustment.

This rule got removed:

add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN

This rule got added:

add action=accept chain=forward comment="allow port forwarding on WAN" connection-nat-state=dstnat in-interface-list=WAN

I can see how I mixed a few ways of going about things. Tomorrow I will go on site to clean up the rules some more. Some adjustments I'm afraid to make from remote

Thanks again to mkx and anav for educating me a bit about Mikrotik firewall rules, maybe I'll get the hang of it.

Just one last question: in my "explicit deny" way of doing things, is the following default rule needed?

add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid

mkx · Thu Dec 22, 2022 7:23 pm

in my "explicit deny" way of doing things, is the following default rule needed?
Code: Select all
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid

It actually is needed and should be pretty high on the rule list (after accept established,related). It blocks some exploit attempts which use specially crafted packets trying to reach targets. These packets are usually (properly) identified as invalid by connection tracking machinery and should be dropped before some other accept rule would allow them to pass (e.g. being dst-nated).

anav · Thu Dec 22, 2022 11:40 pm

Concur with MKX , to make that rule even better do this.........
Through IP firewall selections, ensure loose tcp tracking is NOT selected.
....

connection tracking.jpg

dkong · Fri Dec 23, 2022 10:13 am

Thanks again, I don't use winbox but I found the CLI command for the loose-connection-tracking. In case anybody else needs it for reference, my rules now look like this:

/ip firewall connection tracking
set loose-tcp-tracking=no

/ip firewall filter
### input rules ###
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="allow any from vlan10-int to vlan10-gw" dst-address=10.2.10.254 in-interface=vlan10-int
add action=accept chain=input comment="allow ICMP from vlan12-int to vlan12-gw" dst-address=10.2.12.254 in-interface=vlan12-int protocol=icmp
add action=accept chain=input comment="allow ICMP from vlan13-int to vlan13-gw" dst-address=10.2.13.254 in-interface=vlan13-int protocol=icmp
add action=accept chain=input comment="allow ICMP from vlan20-int to vlan20-gw" dst-address=10.2.20.1 in-interface=vlan20-int protocol=icmp
add action=accept chain=input comment="allow ICMP from WAN to WAN-interface" in-interface-list=WAN protocol=icmp
add action=accept chain=input comment="allow any from zerotier to vlan10-gw" dst-address=10.2.10.254 in-interface=zerotier1
add action=drop chain=input comment="explicit deny"

### forward rules ###
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related hw-offload=yes
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=accept chain=forward comment="allow UNTRUSTED to WAN" in-interface-list=UNTRUSTED out-interface-list=WAN
add action=accept chain=forward comment="allow any from vlan10-int to any" in-interface=vlan10-int
add action=accept chain=forward comment="allow port forwarding on WAN" connection-nat-state=dstnat in-interface-list=WAN
add action=accept chain=forward comment="allow any from zerotier to any" in-interface=zerotier1
add action=drop chain=forward comment="explicit deny"

/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="port forward synology" dst-port=5001 in-interface-list=WAN protocol=tcp to-addresses=10.2.12.10

Simple port forward help needed

Simple port forward help needed

Re: Simple port forward help needed

Re: Simple port forward help needed

Re: Simple port forward help needed

Re: Simple port forward help needed

Re: Simple port forward help needed

Re: Simple port forward help needed

Re: Simple port forward help needed

Re: Simple port forward help needed

Re: Simple port forward help needed

Re: Simple port forward help needed

Re: Simple port forward help needed

Re: Simple port forward help needed

Re: Simple port forward help needed

Who is online