You need to read the complete article, snippets can get you in trouble........ context is always critical.
viewtopic.php?t=179343
Being in a different subnet absolves the admin of the need for the sourcenat hairpin rule yes, but it doesnt excuse the OP from constructing a proper
combination of forward chain rule and dst-nat rule based upon
a. whether the IP is dynamic
OR
b. whether the IP is static.
If you already have a dyndns URL, iP address, then its simple as using your IP cloud address.....
/ip firewall address list
add address=mynetname list=mywanip
OR
add address=duckdns.org list=mywanip
/ip nat
add chain=dstnat action=dst-nat dst-address=mywanip dst-port=XXXX protocol=udp/tcp? to=addresss=IPofServer to-ports= ( only required if diff from dst port! )
This in effect mimics the format of the static IP address.
Why do we do this,
a. because we want the rule to work in all cases aka when the iP changes,
b. because we recognize that in-interface=WAN is not accurate as it does not include members for different subnets accessing the router INTERNALLY via the WANIP. They are not comiing in on the in-interface=WAN!!!
Now as to the forward chain rule.......
What works in all cases and is generally recommended
add action=accept chain=forward comment="allow port forwarding" connection-nat-state=dstnat
This ensures both internal and external users will have no problem reaching the server.
However I do not understand this comment.......
.......... then anything crossing the router port 4322 goes to the SSH server, which isn't desirable.
Can you clearly describe what user traffic should access the server????