: Netmap is not necessary.
It's only advantage is, that it allows range of addresses to be translated to another range of addresses. In this case, dst-nat is fine because OP needs just one ip/port. I have done this kind of forwarding countless times and there is no special catch on it.
: Is it possible that some other firewall rule interfere with it? I tried to set it up on completely blank lab router and it worked without issue. Following is my config:
/ip firewall filter
add action=accept chain=forward comment="Allow established traffic" connection-state=established,related
add action=accept chain=forward comment="Allow new SSH traffic from WAN to LAN" dst-address=10.245.25.95 dst-port=22 protocol=tcp
add action=accept chain=forward comment="Allow traffic from LAN to WAN" in-interface=ether5 out-interface=ether2
add action=drop chain=forward comment="Drop everything else" log=yes
/ip firewall nat
add action=masquerade out-interface=ether2
add action=dst-nat chain=dstnat dst-address=10.245.24.229 dst-port=8122 protocol=tcp to-addresses=10.245.25.95 to-ports=22
(10.245.24.0/24 is lab's WAN, 10.245.25.0/24 is internal network)
With this, all I need is to run the SSH command (for example on linux):
ssh firstname.lastname@example.org -p 8122
Instantly after running this command, I see that both counters on forward rule (allow ssh traffic) and on dstnat rule got increased - that proves that my connection reached router.
It is important to allow forward on the way back, typically using filter (chain forward, allow established/related)
If your counters don't increase, your router is not even being reached on that port number. It is not uncommon for ISP to block some port numbers.
If your counters increase, that proves your router was reached and ip+port were translated.
If you can't figure out, you can either share rest of your config (as always - feel free to mask sensitive info) or you can try to use packet sniffer to see where do you lose your data. there should be clearly visible packet coming into your WAN interface, then out from your LAN interface. After that, there should be reply coming into your LAN interface and again out from WAN interface. If some of these steps does not show up, that's where your problem is
: Good point with non-public IP on WAN! I didn't think about that