There is nothing unusual in your configuration, so since it "doesn't work", my first question is how do you test it. If you try to connect to x.x.x.123 from a device in 192.168.88.0/24, you would have to set up a "hairpin NAT" to make it work when the server is also in 192.168.88.0/24. But there are better approaches if you need clients in LAN to access a server in LAN via the public address, and if you only need it for testing, it is better to test it from the internet, i.e. the same way it will work in production.

Also, you only need to set to-ports in NAT rules if you want them to change the ports - in your case, it is not necessary. But nor is it harmful.

1-I am testing from outside, but that doesn't matter—it should work from both sides. I have the exact same setup with my CCR2004, and I can see the port is open from both outside and inside.

@Techsystem: could you be so kind and edit your post to apply proper tags for code?

1-I am testing from outside, but that doesn't matter—it should work from both sides. I have the exact same setup with my CCR2004, and I can see the port is open from both outside and inside.

Open a command line window, make it as wide as your screen allows, run /tool sniffer quick port=3389 in it, and try establishing a RDP connection from the test client to the server. It should show you whether the connection attempt arrives at all and if yes, what happens next.

What does /ip arp print where address=192.168.88.200 show? The firewall rules are OK, there are no IPsec policies, no routing tables except main, no rules in raw... so unless there is a typo in the .123 address in the dst-nat rules, if the server at 192.168.88.200 can be pinged from the router itself, it looks like a bug.

What does /ip arp print where address=192.168.88.200 show? The firewall rules are OK, there are no IPsec policies, no routing tables except main, no rules in raw... so unless there is a typo in the .123 address in the dst-nat rules, if the server at 192.168.88.200 can be pinged from the router itself, it looks like a bug.

1. The first problem I see is that you have both
an IP address for WAN on ether1 AND a dhcp client on ether1.
It cannot be both!!!

@Paternot, the first sniff result shows that the initial packet for port 3389 did arrive to ether1, so the ISP does not block it.

Is the target host a Windows machine ?
No host-firewall issues ?

If a Linux, can you do a quick "tcpdump" to see what actually ARRIVES there ?
If a Windows, perhaps quickly install "Wireshark" or something for a test.

Have you ever modified the dst-nat rules or have you put them in exactly the way they look now?

In recent ROS 7 versions, there is a nasty bug with some configuration items - if you modify them, the changes do not make it from the "visible" configuration to the "running" one. In some cases, disabling and enabling that item helps, in other cases it apparently doesn't. I don't know since when the bug is there so 7.12.2 may or may not be affected.

In any case, please try the following:
/ip firewall nat add chain=dstnat in-interface=ether1 protocol=tcp dst-port=3389 action=dst-nat to-addresses=192.168.88.200 place-before=[find where dst-port~"3389"]
and then try testing while sniffing like in the first case again.

@Paternot, the first sniff result shows that the initial packet for port 3389 did arrive to ether1, so the ISP does not block it.

@Techsystem, @jvanhambelgium's suggestion made me realize I may have jumped to conclusions too quickly - for the bridge port via which the server at .88.200 is reachable, set hw on the corresponding /interface bridge port row to no and run the sniffer again. Sniffing on ports with hw=yes may not show some traffic.

1. The first problem I see is that you have both
an IP address for WAN on ether1 AND a dhcp client on ether1.
It cannot be both!!!
If your certain about the IP address disable the dhcp client.

2 Suggest changing this default rule to three rules which are clearer as to the functionality and a bit more secure as well.
from:
add action=drop chain=forward comment=\
"defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
connection-state=new in-interface-list=WAN
TO:
add action=accept chain=forward comment="internet traffic" in-interface-list=LAN out-interface-list=WAN
add action=accept chain=forward comment="port forwarding" connection-nat-state=dstnat
add action=drop chain=forward comment="drop all else"

3. Masquerade rules are misleading in that the comments should be removed ( these are action sourcenat NOT masquerade )
I dont think you need source address of the lan either but probably no harm.

/ip firewall nat
add action=src-nat chain=srcnat comment="defconf: masquerade" ipsec-policy=\
out,none out-interface-list=WAN src-address=192.168.88.0/24 to-addresses=\
xxx.xx.xx.123
add action=src-nat chain=srcnat comment="defconf: masquerade" ipsec-policy=\
out,none out-interface-list=WAN src-address=192.168.88.0/24 to-addresses=\
xxx.xx.xx.122

4. Other than that, dont see anything.

@Paternot, the first sniff result shows that the initial packet for port 3389 did arrive to ether1, so the ISP does not block it.

Port 3389. He was complaining about port 443, wasn't he? Here is quite common for ISPs to block ports below 1024. Don't know about his case though.

1. The first problem I see is that you have both
an IP address for WAN on ether1 AND a dhcp client on ether1.
It cannot be both!!!

Of course it can be both, but one need to /really/ know that's what they want.

Case in point, DOCSIS cable modems have the hard-coded-in-standard 192.168.100.1 IP for the management interface.
I have the modem configured in bridge mode, so it assigns me an upstream IP by DHCP and a gateway IP somewhere "up there" in ISP's network. It does not do any routing tasks.
And so, I have secondary static 192.168.100.2 IP configured on the very same WAN interface next to the DHCP client, so I can access the modem and the internet at the same time.

here is the result after I set hw to off in the target port.

1. a packet to ..123:3389 arrives in via ether1
2. a packet to ..88.200:3389 is sent out via bridge-the-IP-interface, so the dst-nat worked
3. the same packet is shown to leave the bridge-the-virtual-switch via ether2
4. a response from the server (source address ..88.200:3389) arrives via ether2
5. the same packet is shown to enter routing via bridge-the-IP-interface
6. the same packet is sent out via ether1 after un-dst-nating the source address, i.e. from ..123:3389

here is the result after I set hw to off in the target port.

This sniffing result clearly shows that the port forwarding on Mikrotik works as expected and the issue is somewhere else.

Look at the packets with timestamps 13.3xx (from the 3rd packet from the top on the picture):

1. a packet to ..123:3389 arrives in via ether1
2. a packet to ..88.200:3389 is sent out via bridge-the-IP-interface, so the dst-nat worked
3. the same packet is shown to leave the bridge-the-virtual-switch via ether2
4. a response from the server (source address ..88.200:3389) arrives via ether2
5. the same packet is shown to enter routing via bridge-the-IP-interface
6. the same packet is sent out via ether1 after un-dst-nating the source address, i.e. from ..123:3389

As you haven't shown the complete rows, it is impossible to say whether the server rejects the incoming connection requests or whether the responses get lost on their way from the L009 to the external client, but the L009 does its job properly.

So I'd now try the same again and instead of snapshoting the graphical window, I'd stop the sniffer and run (within a few minutes, the buffer gets cleared afterwards) /tool sniffer packet print detail file=rdp-attempt, download the resulting file rdp-attempt.txt, use text substitution to replace the public address, and post the modified file here for further analysis.

1. how comes that the fact that there are two other public addresses, probably attached to another WAN, was not visible from your configuration export? Did you remove some rows you've assumed not to be relevant?

2. the srcnat rules in your export that only differ from each other by the to-addresses parameter will not work the way you expect. The first (upper) one shadows the second (lower) one, so all connections initiated from the LAN side will be src-nated to ..123.

I'm not good in Windows, but I'd say you can make use of to-ports and use a single service you know to work alright on the server (e.g. SSH at TCP port 22) and use one dst-nat rule at a time to forward the individual "outer" ports to it, like
chain=dstnat in-interface=ether1 protocol=tcp dst-port=3389 action=dst-nat to-addresses=192.168.88.200 to-ports=22
Of course, you would have to use an SSH client to test and tell it to contact port 3389 at ...123.

Other than that, it was exactly the point of my question - if the other two public addresses in the same subnet were not attached to another interface of the same Mikrotik, it could not be the reason why it behaved like it did (and still does).

But maybe the server at 192.168.88.200 has multiple network interfaces and each is connected to another Mikrotik?

Okay, in this case, I can see that all my ports are open, but is this the right way to open ports?

is this the right way to open ports?

is this the right way to open ports?

Of course it is not the right way to open ports, but it is the right way to analyze the issue you experience, and I've suggested it for the latter purpose.

You have got an issue somewhere on a complex network path between the client application and the server application; in these cases, the first step is to identify the particular part of the path which causes the problem. So by redirecting all the ports you want to use, one by one, to a known-good port (22) on the server using the Mikrotik, we have proven that all the way from the client via the internet to the Mikrotik, the connections to all those ports work alright, so the issue must be between the Mikrotik and the server application. Since the server did respond somehow to incoming packets to port 3389, chances are very high that the issue is in fact in the networking configuration of the server.

So on the Mikrotik, the target configuration is to redirect incoming traffic to the desired ports to the address of the server without changing the port, but before we get there, we have to find out why the server handles incoming connections to port 22 alright but struggles with the rest.

So we come back to my original question, how many network interfaces does the server have?

One option: use source address list on dstnat rule to make ports appear closed on scans and of course limits access........ ( external wanips can be spoofed )
Second option: have users wireguard in to the router and then access servers
Third option: Future case when Mikrotik adds zerotrust cloudflare tunnel so that ALL MT folks, one day, can safely host servers free from attacks........ circa 2050 maybe.......

The server has four interfaces: the first one is connected directly to the ONU unit with a public IP, and the second is connected to the MikroTik with the IP address 192.168.88.200.
(...)
I assume they know how to configure the network interface for it.

The server has four interfaces: the first one is connected directly to the ONU unit with a public IP, and the second is connected to the MikroTik with the IP address 192.168.88.200.
(...)
I assume they know how to configure the network interface for it.

Assumption is good, knowledge is better. Professionals are just people who get paid for what they do, but we all make mistakes, regardless whether we currently wear the professional hat or the enthusiast one. There must be a deterministic reason why the server responds alright on port 22 but doesn't on the other ones.

A server that has multiple interfaces and at least one of them is behind a NAT must use some kind of policy routing (or VRF or network "namespace") to make sure to send responses to incoming requests from the same address to which those requests arrived and via the same interface through which they arrived, otherwise the responses will not get properly un-dst-nated and the client will not recognize them even if the ISP lets them get through despite their incorrect (from its perspective) source address. This part seems to be configured properly as the response did come back to the Mikrotik although its destination was a public address somewhere in the internet, so without policy routing, it would have taken the other route.

However, most server processes can be told to listen on all addresses of the server or only on specific ones. So if the incoming connections to port 3389 are actively rejected (sniffing as described earlier will clearly show whether it is the case), the reason may be that the process only listens on other address(es) than 192.168.88.200; in such a case (and several other ones), the TCP stack would reject the connection by sending a RST packet in response to the SYN one.

first, I just want to make sure that everything is properly configured on the ether2 interface on the server.