Port Forwarding. So Simple. So Difficult.

RouterOS General
1

Seems many folks have issues doing something so intuitively simple with Mikrotik devices… Port forwarding… So trivial, yet so difficult.

Chateau 5G. Out of the box. IP6 disabled. Wireless network disabled. Very vanilla. Not behind any NAT from my ISP.

Reduced the setup to something very simple - web server 192.168.88.2 on TCP 81 on the internal network.

Attached pictures and text file showing config.
NAT Config.jpg
ChateauConfig.txt (7.35 KB)
Any help from those with more experience of RouterOS or Mikrotik, much appreciated.

2

two things ensure you have NAT/Masquerade rule for 192.168.88.0/24 going to WAN and your host 192.168.88.2 its next-hop / default gateway is your mikrotik router

3

You sure you have one public IP address for your own?
Usually on 5G are all shared IPs until you do not pay some extra for have your own Public IP…

you have dst-address-list=“” on test forward, check if on “Advanced” tab you do not have leaved the dst. address list filed enabled and empty.
if you set that field enabled and empty, no one IP match the empty dst-address-list and the rule not work

4

Hi Loloski and thanks for your input.

I think this (default) line in the config takes care of the outbound NAT doesn`t it?

add action=masquerade chain=srcnat comment=“defconf: masquerade” ipsec-policy=out,none out-interface-list=WAN

I tried adding an outboud NAT rule explicitly for the 192.168.88.0/24 network to see if it made any difference and it didn’t.

Also for awareness, I just checked and can see in the webserver logs, that there is no traffic getting to the server… So this is an “inbound” traffic issue…

And yes, first hop from the web server at 192.168.88.2 is the internal interface of the Mikroitik router on 192.168.88.1

Any more ideas?

5

Hi rextended and thanks for your help!

I have a publicly routable dynamic address from my ISP. I checked this by enabling an openvpn server in the Mikrotik router and telnetting to TCP 1194 using it's external address. Connected without issue.

Attached is a screenshot of the Advanced tab.... Nothing much to see...

AdvancedTab.jpg
AdvancedTab.jpg639×591 76.5 KB

Any other ideas?

6

Ok, in the export is v7, my fault to not remember it, everytime specify RouterOS version.

Check on “General” if dst.address list is “white” or “gray” like src address list.
Must be gray, click on the arrow up at the end

7

Rules have counters that increase with each matching packet. How are yours? If zero, then no such packets are coming. If non-zero, then there are such packets and since there doesn’t seem to be anything in your config that would block them, next thing to check would be the target internal server.

8

@Sob, the NAT rule, if dst-address-list=“”, probably can’t match anything…
I do not know how is possible than the rule can be set with =“”


@ross99999999
If you only have those two NAT rules in the export, paste this on the terminal:

/ip/firewall/nat set [find] !dst-address-list
9

No, that’s not it. If I do quick test with:

/ip firewall mangle
add action=log chain=prerouting dst-address-list="" dst-port=666 log-prefix=test-list protocol=tcp
add action=log chain=prerouting dst-port=666 log-prefix=test-no-list protocol=tcp

and try to connect to port 666, I see both “test-list” and “test-no-list” logged.

10

Yep - greyed out - screenshots in original post

11

With In. Interface List set to WAN, zero traffic. But… If I change this to “all”, I seem to see traffic that matches this rule… But again, it never gets to the server (nothing in the logs)
InInterfaceAll.jpg

12

Ok, you try with a smartphone outside your network, for example with LTE (and wifi off) or you testing the NAT inside your network?

Probably the answer is inside the question…

13

@ross99999999
If you only have those two NAT rules in the export, paste this on the terminal:

/ip/firewall/nat set [find] !dst-address-list

[/quote]

Nothing comes back…

[admin@MikroTik] > /ip/firewall/nat set [find] !dst-address-list
[admin@MikroTik] >
[admin@MikroTik] >

14

Testing from the internet, not from the internal network.

15

No about interface list. Nothing selected (option not active) means no restriction, any interface is allowed. You can’t improve that.

16

if the rule hits, out of curiosity can you visit http://192.168.88.2:81 or can you use /tool/fetch from the router to check if the port is open post the output here

/tool/fetch http-method=get url=http://192.168.88.2 port=81
17

Nothing logged and no traffic
NothingLoggedAndNoTraffic.jpg

18

[admin@MikroTik] > /tool/fetch http://192.168.88.2/index.html
status: failed

failure: closing connection: 192.168.88.2:80 (5)
[admin@MikroTik] > /tool/fetch http://192.168.88.2:81/index.html
status: finished
downloaded: 0KiBC-z pause]
total: 0KiB
duration: 1s

[admin@MikroTik] >

19

No, sorry for confusing you, that one with port 666 was for @rextended. You can try this:

/ip firewall nat
add chain=dstnat dst-address-type=local protocol=tcp dst-port=81 action=dst-nat to-addresses=192.168.88.2
/ip firewall mangle
add chain=prerouting connection-mark=debug-pf action=log log-prefix=port-forward
add chain=prerouting connection-state=new dst-address-type=local protocol=tcp dst-port=81 action=mark-connection new-connection-mark=debug-pf log=yes log-prefix=port-forward-NEW passthrough=yes
add chain=forward connection-mark=debug-pf action=log log-prefix=port-forward
add chain=postrouting connection-mark=debug-pf action=log log-prefix=port-forward

And you should see this in log:

port-forward-NEW prerouting: in:lte1 out:(unknown 0), …, proto TCP (SYN), c.c.c.c:xxx->p.p.p.p:81, …
port-forward forward: in:lte1 out:bridge, …, proto TCP (SYN), c.c.c.c:xxx->192.168.88.2:80, NAT c.c.c.c:xxx->(p.p.p.p:81->192.168.88.2:80), …
port-forward postrouting: in:lte1 out:bridge, …, proto TCP (SYN), c.c.c.c:xxx->192.168.88.2:80, NAT c.c.c.c:xxx->(p.p.p.p:81->192.168.88.2:80), …
port-forward prerouting: in:bridge out:(unknown 0), …, proto TCP (SYN,ACK), 192.168.88.2:80->c.c.c.c:xxx, NAT (192.168.88.2:80->p.p.p.p:81)->c.c.c.c:xxx, …
port-forward forward: in:bridge out:lte1, …, proto TCP (SYN,ACK), 192.168.88.2:80->c.c.c.c:xxx, NAT (192.168.88.2:80->p.p.p.p:81)->c.c.c.c:xxx, …
port-forward postrouting: in:bridge out:lte1, …, proto TCP (SYN,ACK), 192.168.88.2:80->c.c.c.c:xxx, NAT (192.168.88.2:80->p.p.p.p:81)->c.c.c.c:xxx, …

#1 - request from client c.c.c.c comes to public address p.p.p.p
#2 - packet is passing through router after dstnat
#3 - packet successfully passed through router and is being sent to server
#4 - response from server
#5 - response passing through router
#6 - response being sent to client

If you don’t see #1, then requests are not reaching your router at all. If you don’t see #4, then internal server is not responding.

20

Thanks everybody - really appreciate the time and effort from you guys here.

Ultimately, the most simple of router configuration (port forwarding) doesn’t work on this device when an out-of-the-box device is configured exactly according to the KB article of the manufacturer, which I must say, makes complete sense to me. I took a “punt” with Mikrotik for the first time (usually run Teltonika kit or something with OpenWRT) and it bit me. Burned more money in terms of time trying to do the most basic of thing than this hardware is worth.

Am now away from the customer site for two weeks, having caused quite some serious delay to the project. Something that should have taken 5 minutes, wasted a day and half in head scratching.

When I go back on site, I could spend more time (money) digging into this to find the cause of the issue… But I wont. I will very quickly try and make this Chateau 5G a simple bridge, stick a (proper) firewall behind it and just use the modem (which is actually the best and really only great feature of this product). If it wont bridge after 10 mins, it will go in the bin (actually 2 of them because we bought another for redundancy) and I will use something that I know will be up and running within half an hour.

But again, to everybody who offered suggestions, I really appreciate it.