What ROS can do with DST-NAT is to pass packets to another server.
What ROS (by itself) can not do is to redirect clients to another address. This means that e.g. browser gets new URL and new url is then visible in address bar of the browser.
The way you described intended solution means you’re trying to do the former. There are two potential problems and none are specifically bound to Mikrotik:
the new server has to know it’s replying to requests for the original host name. Which includes installation correct SSL certificate when using HTTPS.
when only doing dst-nat and new target server can reply to client via route which bypasses NAT device, then client will drop packets. The reason is that client thinks it’s talking to MT router (i.e. its IP address) but starts to receive reply packets from end server because end server tries to send replies directly to client. This problem can be avoided by performing also src-nat, making server believe it’s MT router connecting it, so it sends replies to MT router which in turn undoes both nats and delivers client expected replies.
And, as @rextended already wrote: by using NAT you can’t change application protocol … http and https are different beasts and each has its own default port number. You can’t do dst-nat from port 80 to 443 (or vice versa) and expect that communication would succeed.
The above description is a bit theoretical. If you describe what exactly are you trying to achieve (in plain english, don’t bother with configuration code snippets), then you may get some more concrete advice.
Are there any alternative solutions for redirecting them?
well, basically - a port is just a port.
but… a port will be in different state if it was used by an app.
some app can take redirection - some with ssl (read: certificate) planted in it can’t take redirection.
there are differences between redirection and interception (proxying).
mostly, generally speaking
redirection could mean just redirecting traffic to other location - without terminating those traffic.
interception literally mean mitm which terminates traffic on/as if - behalf the remote end . legitimate proxy should have legitimate certificate planted inside that machine to forward the traffic to remote end.
it is ssl job to make sure any kind of proxying unavailable.
examples:
your sshd server config listen on port 22
for internal lan - it will be direct.
but then you need to open this ssh access to enable remote admin from home, you then dstnat your office router port 22345 to 22.
or… internal www at wan ip port 3456 to internal server port 8080.
those are simple redirection. no problem.
but it will be different thing when you do web proxying - for example: squid or haproxy (traffic interceptions).
for non-ssl traffic ie. http, no problem.
but for ssl traffic ie. https. no you can’t. your proxy needs to be ssl termination point - which needs a certificate for itself and other remote server certificate as well - to be able to forward traffic.
IMO there are two distinct things (on service level), but many people don’t discern them:
forward a request
In this case original device (transparently) forwards request to another server. The other server returns result and original device passes it to client.
Client doesn’t know that server, which prepares answer, is not the device it’s talking to.
Prime example of such behaviour is port forwarding. Another example is reverse proxy (for some services this is possible, such as http/https).
2. redirect a request
In this case original device replies to service request with “redirect” message. Next step for client is to finish connection to original device and establish new connection to server, indicated in redirect message.
Prime example of such behaviour is http/https response code 301 moved permanently (or many of 3xx response codes).
So when reading original post in this thread, I understand it according to bullet #2 above. And that can not be done using ROS device because it lacks proper http/http server. As things are, neither can properly do it according to bullet #1 above (except for a very few services, such as http, which don’t allow client to verify server’s authenticity), the reason is the same - lack of proper reverse proxy.
And no, port forwarding is mostly not an option for such task, it doesn’t cover most of different use cases.
Use browser developer tools to inspect network requests and redirects. you can use online tool such as this tool Redirect checker This can get detail redirection report along with status code.