Hello All,

I have just bought MikroTik RB962UiGS-5HacT2HnT and trying to set it up.

I have done all basic configuration and router works well.
Now I am on fine settings.
I nee to setup port forwarding as I have webserver behind router and I want it be accessible from Internet.

Let say external router ip 32.32.32.32 and local webserver ip : 192.168.0.10 and port is 1111 (just an example)

I went to IP->Firewall->NAT and created new NAT Rule:

General:
Chain: dstnat
Protocol: 6 (tcp)
Dst. Port: 1111
In. Interface: ether1-WAN - input internet port

Action:
Action: netmap
To Address: 192.168.0.10
To Ports: 1111

Once the rule was created I am able to access my webserver from Internet : 32.32.32.32:1111

But I got another problem I can not access that webserver from my LAN, I can not access 32.32.32.32:1111 from local host 192.168.0.11.
192.168.0.10:1111 works well but external IP doesn't work.

Anyone able to help how to resolve the issue? I will be very grateful.

Thanks in advance.
Sergey

If one rule is enough, why add more.

This last part is about making FTP server on router accessible from anywhere. So you need exactly one rule to allow connections to main control port. Connections to data ports can be allowed automatically using conntrack and related state.

For ports forwarded inside, you don't need too many rules either. Dstnat rule(s) are required, but everything in firewall filter can be simply solved with one universal rule allowing connections with connection-nat-state=dstnat. If you need filtering based on source IP, you can do it in dstnat, i.e. not forward the port(s) for given source at all.

/ip firewall nat
add action=dst-nat chain=dstnat in-interface=WAN1 <other conditions>
<other 998 rules for WAN1>
add action=dst-nat chain=dstnat in-interface=WAN1 <other conditions>
add action=dst-nat chain=dstnat in-interface=WAN2 <other conditions>
<other 998 rules for WAN2>
add action=dst-nat chain=dstnat in-interface=WAN2 <other conditions>
add action=dst-nat chain=dstnat in-interface=WAN3 <other conditions>
<other 998 rules for WAN3>
add action=dst-nat chain=dstnat in-interface=WAN3 <other conditions>

/ip firewall nat
add action=jump chain=dstnat in-interface=WAN1 jump-target=<dedicated chain for WAN1>
add action=jump chain=dstnat in-interface=WAN2 jump-target=<dedicated chain for WAN2>
add action=jump chain=dstnat in-interface=WAN3 jump-target=<dedicated chain for WAN3>
add action=dst-nat chain=<dedicated chain for WAN1> <other conditions>
...

Somehow then, the Router Has the ability to check the traffic against the NAT rules to see if it matches a DST NAT RULE and if so says JUMP or GO TO PORT FORWARD process.

I am not seeing any advantage or savings but instead see creating more rules and processes than is required??????

One little problem, we didn't define exact setup for the example, so there are multiple ways how to handle it. What I posted could be for one ISP connection with two public addresses. That's how I understood your "WANIP 1234/5678", as two public addresses assigned to router, and that rule #2 should work with one and rule #3 with the other. And in-interface=<WAN> (or in-interface-list=<WANs> if there would be more than one internet connection) in rules #1 and #4 is the basic port forwarding config, where you don't care about destination (and which is in many cases wrong; sorry, I took a shortcut)...
EDIT: Yes, I meant them to be outside users public WANIPS and the miscommunication created issues in of itself.

So, lets try it like this:
When I have conditional dstnat rule, then when the condition is not met, dstnat does not happen, packets keeps original destination address (public IP of router), which will send them to input chain and there they will be dropped by default firewall.
EDIT: Okay so I can identify a source address or source address list in my dstnat rule, it makes it conditional and if its not matched then gets dropped on the input chain and hence already covered in Filter rules(and making another is not required.


Another possible problem is that sometimes you want to be able to access same hostname also from LAN (the same one where's the target server). For that, you need another thing called hairpin NAT, but it can't work when your dstnat rules don't work for connections from LAN. And with in-interface=WAN they won't.
EDIT: Yes I see where using in-interface WAN would stop hairpin NAT from working.

About jumps example, imagine you have several WANs, you want different sets of dstnat rules for each, and you have a lot of them:

Code: Select all

/ip firewall nat
add action=dst-nat chain=dstnat in-interface=WAN1 <other conditions>
<other 998 rules for WAN1>
add action=dst-nat chain=dstnat in-interface=WAN1 <other conditions>
add action=dst-nat chain=dstnat in-interface=WAN2 <other conditions>
<other 998 rules for WAN2>
add action=dst-nat chain=dstnat in-interface=WAN2 <other conditions>
add action=dst-nat chain=dstnat in-interface=WAN3 <other conditions>
<other 998 rules for WAN3>
add action=dst-nat chain=dstnat in-interface=WAN3 <other conditions>

If you do it like this and a new incoming connection comes to WAN4, router will have to check all 3000 rules, before realizing that none is applicable. But if you do:

Code: Select all

/ip firewall nat
add action=jump chain=dstnat in-interface=WAN1 jump-target=<dedicated chain for WAN1>
add action=jump chain=dstnat in-interface=WAN2 jump-target=<dedicated chain for WAN2>
add action=jump chain=dstnat in-interface=WAN3 jump-target=<dedicated chain for WAN3>
add action=dst-nat chain=<dedicated chain for WAN1> <other conditions>
...

Then for the same connection, only three rules will be checked.

Somehow then, the Router Has the ability to check the traffic against the NAT rules to see if it matches a DST NAT RULE and if so says JUMP or GO TO PORT FORWARD process.

There's really no "port forward process", it's just a simple change of destination address, as described above. And similar to this, all conditions you can use for any rule are just simple checks, if current packet has given property or not. Don't look for anything complicated, it's not there.
Ok, there is some "magic" involved, a connection tracking, which understands the traffic flow, recognizes packets that belong to same connection, etc. It's the thing that makes stuff like connection-nat-state work. But don't worry about that, just know it's there and it "just works".

I am not seeing any advantage or savings but instead see creating more rules and processes than is required??????

Again, it doesn't do much, when you have only few rules and it might not be worth it to do something like this. Some things only start to make sense when you're dealing with large amount of stuff.