Hello, everyone!

The issue is in the title, and it drives me mad. I've searched all over the internet and tried every solution I could find with no success.
I originally needed to open port 80 for a small web-app I have been trying to set up. Through numerous attempts to do that I tried 8080, 8888, etc., and now I ended up with dst-nat rule on port 49999. It does work for my local clients, due to Hairpin NAT, but remote machines are getting timeouts.

192.168.88.100 is where my http-server is hosted

Things I've tried so far:
dst-nat on 192.168.88.100 port 49999 with my public IP as dst-address,
dst-nat on 192.168.88.100 port 49999 with my PPPoE as in-interface
dst-nat on 192.168.88.100 port 49999 with my WAN as in-interface
netmap on 192.168.88.100 port 49999 with all aforementioned combinations
and numerous other tricks and tweaks

Please, I need help.

[admin@MikroTik] > ip address print
Flags: X - disabled, I - invalid, D - dynamic
# ADDRESS NETWORK INTERFACE
0 ;;; defconf
192.168.88.1/24 192.168.88.0 bridge_local
1 D 100.64.68.8/32 94.229.236.4 mts-pppoe

[admin@MikroTik] > interface print
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU MAX-L2MTU MAC-ADDRESS
0 R ;;; WAN
ether1 ether 1500 1598 2028 CC:2D:E0:17:BC:CC
1 RS ether2-master ether 1500 1598 2028 CC:2D:E0:17:BC:CD
2 S ether3 ether 1500 1598 2028 CC:2D:E0:17:BC:CE
3 RS wlan1 wlan 1500 1600 2290 CC:2D:E0:17:BC:D0
4 R ;;; defconf
bridge_local bridge 1500 1598 CC:2D:E0:17:BC:CD
5 R mts-pppoe pppoe-out 1480

[admin@MikroTik] >> ip firewall filter print
Flags: X - disabled, I - invalid, D - dynamic
0 D ;;; special dummy rule to show fasttrack counters
chain=forward action=passthrough

1 ;;; defconf: drop invalid
chain=input action=drop connection-state=invalid log=no log-prefix=""

2 ;;; defconf: accept ICMP
chain=input action=accept protocol=icmp log=no log-prefix=""

3 ;;; defconf: drop all not coming from LAN
chain=input action=drop in-interface-list=!LAN log=no log-prefix=""

4 ;;; defconf: accept in ipsec policy
chain=forward action=accept log=no log-prefix="" ipsec-policy=in,ipsec

5 ;;; defconf: accept out ipsec policy
chain=forward action=accept log=no log-prefix="" ipsec-policy=out,ipsec

6 ;;; defconf: fasttrack
chain=forward action=fasttrack-connection connection-state=established,related log=no log-prefix=""

7 ;;; defconf: accept established,related, untracked
chain=forward action=accept connection-state=established,related,untracked log=no log-prefix=""

8 ;;; defconf: drop invalid
chain=forward action=drop connection-state=invalid log=no log-prefix=""

9 ;;; defconf: drop all from WAN not DSTNATed
chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface-list=WAN log=no log-prefix=""

10 ;;; defconf: accept established,related,untracked
chain=input action=accept connection-state=established,related,untracked log=no log-prefix=""

[admin@MikroTik] >> ip firewall nat print
Flags: X - disabled, I - invalid, D - dynamic
0 ;;; defconf: masquerade
chain=srcnat action=masquerade out-interface=mts-pppoe log=no log-prefix="" ipsec-policy=out,none

1 chain=dstnat action=netmap to-addresses=192.168.88.100 to-ports=49999 protocol=tcp dst-port=49999 log=yes log-prefix=""

2 chain=srcnat action=masquerade protocol=tcp src-address=192.168.88.0/24 dst-address=192.168.88.100 out-interface=bridge_local dst-port=49999 log=no
log-prefix=""

3 chain=srcnat action=src-nat to-addresses=192.168.88.1 protocol=tcp src-address=!192.168.88.0/24 dst-address=192.168.88.100 dst-port=49999 log=no
log-prefix=""

Please post your config (complete)
/export hide-sensitive file=yourconfigmar17

Looking at the assigned WAN IP address it appears your ISP is using CGNAT

1 D 100.64.68.8/32 94.229.236.4 mts-pppoe

Without a public IP no amount of tinkering with your router will allow your web server to be accessed from the internet.

Thanks for your support!
I suspect that might be my ISP as well, but it was working fine on my old D-LINK router, though It was some times ago.
Config is in attachement

Hi,

You wrote your nat rule by the wrong way.

/ip firewall nat
add action=dst-nat chain=dstnat dst-address=your-public-address dst-port=49999 log=yes protocol=tcp \
to-addresses=192.168.88.100 to-ports=80(your desire port)

Hi,

You wrote your nat rule by the wrong way.

I am sorry, I wasn't clear. My server now also listens to 49999. I can reach it through my public IP by any device within my LAN thanks to Hairpin NAT rule. Still unreachable from the outside.

I would update your firmware for starters. There is no such thing as master slave in newer firmwares.

Make sure this rule is first on your input chain
add action=accept chain=input comment=\
"defconf: accept established,related,untracked" connection-state=\
established,related,untracked

Get rid of this rule............ wrong use of it.. I believe
add action=netmap chain=dstnat dst-port=49999 log=yes protocol=tcp \
to-addresses=192.168.88.100 to-ports=49999

Instead, use
add action=dst-nat chain=dstnat dst-port=49999 log=yes protocol=tcp \
in-interface-list=WAN to-addresses=192.168.88.100

Get rid of these rules as well, they are not destination nat rules.......and you already have a masquerade rule that covers outgoing traffic
add action=masquerade chain=srcnat dst-address=192.168.88.100 dst-port=49999 \
out-interface=bridge_local protocol=tcp src-address=192.168.88.0/24
add action=src-nat chain=srcnat dst-address=192.168.88.100 dst-port=49999 \
protocol=tcp src-address=!192.168.88.0/24 to-addresses=192.168.88.1

I would update your firmware for starters. There is no such thing as master slave in newer firmwares.

Make sure this rule is first on your input chain
add action=accept chain=input comment=\
"defconf: accept established,related,untracked" connection-state=\
established,related,untracked

Get rid of this rule............ wrong use of it.. I believe
add action=netmap chain=dstnat dst-port=49999 log=yes protocol=tcp \
to-addresses=192.168.88.100 to-ports=49999

Instead, use
add action=dst-nat chain=dstnat dst-port=49999 log=yes protocol=tcp \
in-interface-list=WAN to-addresses=192.168.88.100

Get rid of these rules as well, they are not destination nat rules.......and you already have a masquerade rule that covers outgoing traffic
add action=masquerade chain=srcnat dst-address=192.168.88.100 dst-port=49999 \
out-interface=bridge_local protocol=tcp src-address=192.168.88.0/24
add action=src-nat chain=srcnat dst-address=192.168.88.100 dst-port=49999 \
protocol=tcp src-address=!192.168.88.0/24 to-addresses=192.168.88.1

Just did all of that.
No success unfortunately.
That input rule which I moved up the chain doesn't receive any packets when I try to access the web app. Could that mean anything?

Nope, the input chain is access to the router, not the LAN behind the router (only for admins for the most part).

How are you trying to access your servers (from an external site, or from your own network using the app and thus accessing it from the external IP address but from behind your LAN).,

Also
Please go to grc.com
https://www.grc.com/x/ne.dll?bh0bkyd2
and scan your port number to see if it is VISIBLE but CLOSED. (or whatever service you use).

I use https://portchecker.co/check
Says port is closed.
I try to access it using my phone over 4G. I do occasionally ask my friends to check it for me as well.

Made "User specified custom port probe" on port 49999 from the one you've provided
Says Stealth"
Unknown Protocol for this port
Unknown Application for this port

Okay post your config again with the updates and I will have another look please.

Here it is.
in-interface in dst-nat rule is set to my pppoe, but I've tried physical WAN port ether1 too with no avail.

These I would remove from the interface list members........
The bridge being part of the LAN covers all the components under the bridge so to speak.

add interface=wlan1 list=discover
add interface=ether2-master list=discover
add interface=ether3 list=discover
add interface=bridge_local list=discover
add interface=mts-pppoe list=discover

I would add however add this rule because It may be the show stopper......
add this line to the interface list members!
add interface=mts-pppoe list=WAN

That will help ensure this rule is working properly
(add action=drop chain=forward comment=\
"defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
connection-state=new in-interface-list=WAN)

This rule seems fine........
add action=dst-nat chain=dstnat dst-port=49999 in-interface=mts-pppoe log=yes \
protocol=tcp to-addresses=192.168.88.100 to-ports=49999

Since the dst-ports and to-ports are the same you do not need to add the to-ports but it doesnt hurt and its easy to read as it is!!

Nothing else stands out at the moment.

I think you should pay more attention to third post in this thread. If it's true that your router has 100.64.68.8 on WAN interface, it's not public address, it's not possible to connect to it from internet. Only way it could work would be if ISP forwarded traffic from real public address to you (NAT 1:1 or something). Do you have any indication that it's the case here? If it worked in the past with old router, but not necessarily right before you got RB (correct me if I'm wrong), it doesn't mean anything. Unless you're promised to have public address, ISP can put you behing NAT any time.

Why do people put up with getting non public IP addresses from providers, its crazy???

Not really crazy, just consequence of IPv4 address shortage: Large/old ISP obtained enormous blocks of IPv4 ages ago for ridiculously low prices and they will probably never have an issues. However, small/new ISPs nowadays have serious issues to acquire some reasonable blocks. They often don't have much choice than place customers behind CGNAT.
For example, my ISP here in Tasmania had to buy few /23 blocks from Romania in order to cover the demand for public IP. And they still have majority of customers on CGNAT because ordinary people don't really care or need public address...

If people knew and cared about IP addresses, by now we would already have IPv6 everywhere for several years.
Since we don't already have IPv6 everywhere for several years, it's clear that most people don't know or care about IP addresses.

Thank you everyone for your insight and support!
The issue was solved, It was indeed my ISP's fault. I've acquired Static IP and everything works fine.
Just wanted to give update on my problem for those who might stumble upon this thread looking for a solution.