That's because whatever device is hosting those services is only accepting connections from certain addresses. Adding a SNAT rule was a kludge to fix that misconfiguration, that's it.
Your problem has nothing to do with OpenWRT nor does it evidences any issues/bugs with OpenWRT.
18.06 doesn't have nft
Yes, and it does. You can see there's been hits against the firewall rule so the port forwarding rule has been used. I've tested the same rules and they work
The issue is nothing to do with port forwarding or OpenWRT.
Or the OP has [not] configured device to use the desired router/gateway, hence a SRC IP of 192.168.1.1 works, because the desired router then SNATs it's own IP for the connection, hence the connection over the gateway is operational because the server replies to 192.168.1.1 instead of an IP that will route over the undesired gateway. 
Maybe. I'm willing to bet there's a firewall on the device though that's dropping packets from 'unknown' addresses.
No. Redirecting 3389 to the naked device. Directly.
Just to see if we can make any progress, does this rule help?
config nat
option name 'Test'
option family 'ipv4'
list proto 'tcp'
option src 'lan'
option dest_ip '192.168.1.20'
option dest_port '80'
option target 'SNAT'
option snat_ip '192.168.1.1'
From where? How? With what outcome? As it is this is just a meaningless statement.
As others have said, that will not work. dest must be a single specific zone. Yes in theory having the destination IP address could be back-traced to uniquely determine which zone that network is in, but OpenWrt is not quite that smart.
Packet captures on lan would be useful to see the forwarded packets leaving, and the answer from the web server-- if any. This is especially useful when multiple routers are involved, you can troubleshoot them one at a time in sequence.
The answer from the web server may be being misrouted out through a VPN instead of to the raw Internet connection where the request arrived from. Packet captures will show that as well.
On 18.06
GET THIS from canyouseeme.org
Error: I could not see your service on xx.xx.xxx.xxx on port (11122)
Reason: Connection refused
Nothing is between 18,06 and 192.168.1.188
If I add those iptables rules canyouseeme.org connection successed.
That means that the section does nothing.
yes, sorry, of course )) I tried other many rules, so posted another one, but it's ON now.
canyouseeme succeded, but anyway, can't connect to RDP. This time it's another story, let me check pls
OK, look. I think I found one reason of the "problem". While I still have another...
My local network is [192.168.1.0/24] and some devices of it send all traffic via ipsec PBR routing to another tunnel-end. So it acts as a "pseudo gateway" for these devices (pseudo because all traffic goes to local router, and only then is routed to remote end).
To check port forwarding I used one of the PC, that goes to internet via remote-end, just to have external address to connect from. Seems when ip address was resolved and local router found that it's HIS address, it didn't send traffic to the remote-end, so looks like I was trying to connect to forwarded port locally, and not from remote, I mean outside internet. Quite a mess and I'm not pretty sure, but it looks like... Will dig it later.
Second is what I still need to solve. This is remote 20.03 box with its local subnet [192.168.2.0/24]. Tunnel is UP, all pings between local and remote subnets are OK.
I need to forward wan port incoming traffic to ipsec tunnel.
This is remote 20.03, I'm connecting to port 2222:
config rule
option name 'wanipsec'
option src 'wan'
option dest 'ipsec0'
list dest_ip '192.168.1.188'
option target 'ACCEPT'
config redirect
option dest 'ipsec0'
option target 'DNAT'
option name '3389'
option src 'wan'
option src_dport '2222'
option dest_ip '192.168.1.188'
option dest_port '3389'
But can't connect to 192.168.1.188, which is in local router's lan.
(Although when connecting to directly to local router, from outside, using mobile internet, it redirects to LAN, so I can connect. So it's not about the device, or anything between it and local router).
On the local router IPSEC->LAN firewall is allowed.
Took some time to disassemble what was written here...
Look, this is the scheme:
FROM WAN ---> p:2222 [Router3.1] p:8443 ---> ipsec ---> p:8443 [Router1.1] ---> p:80 192.168.1.206
If I curl 192.168.1.1:8443 from Router3.1 - I GET WEBPAGE! (And don't confuse "Apache's internal firewall" with web server's folders access rules. As you can see I could reach from 192.168.3.0 network to 192.168.1.206:80 with all default Apache conf). So you can see whole network is OK, including routing, ipsec and virtualization.
Here're FW screenshots:
ROUTER 3.1 (20.03 box)
ROUTER 1.1 (18.06 box)
Still can't get access to 1.206 from outside of R3.1 - "Connection timed out".
