Port forward

RouterOS Beginner Basics
1

Hello,

I have a question about portforwarding.
My home setup as two routers behind each other. A Mikrotik is behind a zyel router.
I forwarded a port from the zyxel to the mikrotik and in the mikrotik I did:


add action=dst-nat chain=dstnat comment="" dst-port=XXXX in-interface=ether1 protocol=tcp to-addresses=X.X.X.X to-ports=XX

But I still cant reach my NAS via webdav from outside the LAN.
I have some firewall rules:

[size=85][font=Helvetica Neue, Helvetica, Arial, sans-serif]add action=drop chain=forward comment="Drop invalid connections" connection-state=invalid[/font][/size]
add chain=forward comment="Allow connections from the LAN" connection-state=new in-interface=bridge-LAN
[size=100]add chain=forward comment="Allow established connections" connection-state=established[/size]
add chain=forward comment="Allow related connections" connection-state=related
add action=drop chain=forward comment="Drop all other traffic through the router"
add chain=input comment="Allow acces to the router from the LAN using address list" src-address-list=OurLocalLAN
add chain=input comment="Allow established connections to the router" connection-state=established
add chain=input comment="Allow related connections to the router" connection-state=related
add action=drop chain=input comment="Drop all other traffic to router"

If I add this rule everything is working.

add chain=forward comment="" connection-state=new dst-address=X.X.X.X in-interface=ether1 port=XX protocol=tcp

My question is… is this the right way to do it or is there another (better) way?

2

You need the forward rule or a rule which matches on dstnat (as is present in the default config), with only the NAT rule it will not work.

3

The NAT table only tells the router that it should play with the IP headers in some way. It says nothing about the permission to forward such packets.
The filter table is where the permissions are specified.
So yes, what you did is normal.

What pe1chl was referring to is a matching criteria on filter rules “connection nat state” where you can match packets that have been modified by dstnat or srcnat, regardless of what protocol/port/ip was used.

So if you say this:
/ip firewall filter add chain=forward connection-nat-state=dstnat action=accept
This means that you want to allow ANY pinhole to work, so you don’t have to go in and specifically accept each pinhole.

4

Ah Thx. This works indeed. Thx.
Are the firewall rules oke? Or do I need more?

5

Other than some port knocking rules, my firewall is quite short, boiling down to:
out = accept
reply-in = accept
new-in = drop

To me, if a firewall is already going to drop everything that wasn’t asked for, then why make two dozen rules that all end up doing the same thing: dropping new stuff from the Internet.
The time that fancier things like SYN flooding testing are called for is on open ports. If ports are closed, then why waste CPU cycles to determine one of 10 ways to drop the packets?