Hello, I've got hAP mini, and try to set up port forwarding, but RouterOS ignores it. RouterOS adds rule to iptables, some packets pass and trigger counters, but I still have connection timeout. On local interface server responds correctly. Is there any way to fix it? I run RouterOS 6.49.2 stable.

Yes, there is nothing wrong with the router by the way, its you that ignores proper config rules...........
Blaming it a poor defenseless advice, the shame!!!

Please post your config so we can see where you went wrong!!
/export hide-sensitive file=anynameyouwish

You could also review this article for some ideas.........
viewtopic.php?t=179343

Yes, there is nothing wrong with the router by the way, its you that ignores proper config rules...........
Blaming it a poor defenseless advice, the shame!!!

Please post your config so we can see where you went wrong!!

Hello anav, I've set up port forwarding in “Quick set” → “Port mapping”.
I used to set it up on another routers, and there “It just works”.
I really have no idea how to go wrong in three input fields and one “Apply” button.

/export hide-sensitive file=anynameyouwish

Attached.

You could also review this article for some ideas.........
viewtopic.php?t=179343

So, in order to use some very simple feature, user has to RTFM? Okay.

Quickset causes more problem then its worth and should be avoided mostly.

Lets take a look at the DST NAT RULE... You have some missing information, which is basically addressed depending upon type of ISP connection (static or dynamic).
Thus far you rule says traffic headed for dst port 8123 protocol tcp send it to 192.168.88.254 ( the too ports is redundant, not needed if same as dst port). But which traffic?
Typically we state either what interface the traffic is headed to/aimed at or coming from.......

/ip firewall nat
add action=dst-nat chain=dstnat comment="TCP 8123" dst-port=8123 protocol=tcp \
MISSING PIECE HERE to-addresses=192.168.88.254 to-ports=8123

If its static/fixed IP, the you need to add the dst-address=WANIP
Clearly this is not optimal if you have a dynamic WANIP because then one would have to constantly be changing the rule so
If its a Dynamic WANIP you need to add in-interface-list=WAN

In the first case (static) we are now saying for all traffic headed to the wanip, with dst port xx and protocol blah, send to server
In the second case (dynamic) we are now say for all traffic coming in on wanip interface with dstport xx and protocol blah, send to server

Are you testing this from internet or from same LAN? Because from internet it should work, if router has public address. From LAN it currently won't, you'd need hairpin NAT to fix it, in short:

@anav: While I do agree with you that the rule is a bit incomplete and it's good to have some condition for destination, it's not what prevents it from working. You (should) know that, so it would be good to mention it. You know, so that people know what to expect and avoid disappointment, when they end up with better config, but it still doesn't work as they want.

Lets fix the dst nat rule before getting into hairpin nat please!!
Not everyone does the stupid thing of trying to access their server via the wanip vice the more direct lanip.
I always got a friend to test external access anyway............

But you do understand that your proposed change won't fix anything, right?

Yes because the rule he put in allows ALL traffic heading towards the port to be sent to the server so it should have worked.
Wide Open!

I addressed the case of trying to reach your own server using your wanip by instructing go get a friend to test.
You are correct if the assumption is that he wants all his users that are on the LAN behind the router to use the wanip for server access.
I am avoiding that assumption and only going on the fact that he was simply attempting to test the functionality without bothering anyone else,
in which case a whole sale rule change for hairpin nat is not really required.

If the OP wants to read about hairpin then have at it......
viewtopic.php?t=179343

And if you don't have friends, then use some online port tester. No problem there. But it's also not weird that when you add some config that should make e.g. your www.mydomain.tld accessible, you'll first try it from your own computer, because it's the fastest thing. And you can get stuck, because it doesn't work, even though you expected it would.

I didnt think of it in that way, in the sense that with IP cloud one has a very built in way to identify ones IP for just that sort of thing.

I have reset configuration and used quickset page to map ports. After that port forwarding worked for clients outside of LAN but didn't work inside LAN. I added rule “chain=srcnat action=masquerade dst-address=192.168.88.0/24 src-address=192.168.88.0/24” (no idea what this means) and address with global IP became accessible from LAN.

UPD: Before reset my server URL was inaccessible from both LAN and another ISP's network.

Check the thread linked by @anav, it's described there (section "1. ADDING SOURCE-NAT RULE (HAIRPIN)").

In addition keep this on your second monitor to follow along LOL.
http://gregsowell.com/?p=4242