How to create a port forwarding NAT cascade?

Hello.

I have a double routed LAN due to a slightly unusual kind of internet connection technology (side access to a rural directional WiFi AP). My internet connection already passes a Mikrotik router (RB750) with default gateway 192.168.88.1.

I want to allow access via internet to network devices in a deeper LAN, behind another router (192.168.88.0/24 to 192.168.0.0/24), which have IP addresses 192.168.0.17x and provide HTTP portals at port 8080 each. With the help from the managing internet provider, a dst-nat rule was added to prepare incoming access, selected via port numbers (our.dynamic.dns:817x to second.router.ip:817x):

[General]
Chain = dstnat
Protocol = 6 (tcp)
Dst. Port = 8170-8179
In. Interface = pppoe-out1

[Action]
Action = dst-nat
To Addresses = 192.168.88.252

Previously, there was a Windows Server 2012 R2 as NAT router for the LAN, running some additional services. Via WireShark I could confirm that packets arrived as expected. Then I tried to add NAT routing rules to the server, using two different techniques (via port forwarding dialogs, and via “netsh interface portproxy”). In both cases, connections were refused, no port forwarding happened. Eventually someone convinced me that a Windows Server 2012 R2 may simply refuse to do some services for security reasons … so I bought another Mikrotik router (hEX lite) to do what it is supposed to do.

Internet IP = 192.168.88.243different device, different DHCP IP from the first router, where I adapted the previously reported NAT rule: To Addresses = 192.168.88.243
Local IP = 192.168.0.1 – like the usual default of the Windows server, to avoid reconfiguring all clients with fixed IP’s

Here I added a NAT route with specific port translation:

[General]
Chain = dstnat
Protocol = 6 (tcp)
Dst. Port = 8170
In. Interface = ether1-gateway

[Action]
Action = dst-nat
To Addresses = 192.168.0.170
To Ports = 8080

But to my disappointment, same result: wget our.dynamic.dns:8170 => Connection refused.

Now I wonder if I lack of some general knowledge regarding such a cascade (our.dynamic.dns:8**170** => second.router.ip:8**170** => 192.168.0.170:8080). Is that possible at all?

Which is the IP of RB750 and which is the IP of hEX?

(Internet DHCP) -{RB750}-> 192.168.88.1 ==> 192.168.88.243 -{hEX Lite}-> 192.168.0.1

And what is that?

[Action]
Action = dst-nat
To Addresses = 192.168.88.252

That used to be the IP of the Windows Server 2012 R2, while it was in use, before I introduced the hEX Lite. As I wrote, I changed this rule from 252 to 243 after the hEX Lite substituted the WS2012R2 as router. So I believe, after this change, the NAT target is correct again, for the current setup.

On RB750 try:

[Action]
Action = dst-nat
To Addresses: 192.168.88.243
To Ports: 8170-8179

No change, still: Connection refused.

IMHO, it seems to be correct for the first half of the cascade. To me, at least…

I hope one can configure the hEX Lite to log some cases, that may reveal a few details (e.g. if packets arrive at 192.168.88.243:817x at all)..

Put an export of your configs of both routers

“Make supout.rif”, or a different procedure?

From “New Terminal” type export and copy and paste it here in “code”

See attachments.

Note: The RB750 is managed by our internet provider; I won’t change much there unless I am sure it won’t hurt.
config_hEX-Lite.log (2.49 KB)
config_RB750.log (12.8 KB)

First of all you can do this work only with the RB750. No need for hEX.
You can change all IPs from 192.168.88.X to 192.168.0.X in RB750 and remove the hEX from your lan. Also change IP DHCP Server, IP Pool, IP DNS etc.
Second. In RB750 on IP-Firewall-Nat, did you see any packets on port forward rule?
Third. In hEX on IP-Firewall-Nat, did you see any packets on port forward rule?
If yes, check your firewall on machine with IP 192.168.0.170 if is open for 8080 port.

Last. Are you sure that your provider has open those ports in his side?

Not easily. There are more network devices connected to the first .88 net. Furthermore, I am not sure if our internet provider would appreciate this amount of changes in a configuration under their management.

Both are 0. That surprises me. But using the “Packet sniffer” in WinBox, and seeing similar results as with WireShark earlier when I used a Windows Server, I believe I misinterpreted the results.

I expected that this NAT rule would also open these ports for listening. If this assumption is wrong, then I would have to enable them in addition to the NAT rule…

Try to put in dst rule only one port (eg. 8170) in the RB750 and see what happens.
Cause you make the dst rule in RB750 that’s not mean that the ports are open on provider side. Just ask them.
From where you have test that port forward not working? You test the wan side from inside of your lan or outside of your lan?