firstly - the enable redirects is not what you’re thinking - that’s referring to whether the router should send ICMP redirect messages when applicable, but this has to do with routing and choice of default GW vs more specific gateway… not what you’re doing.
The rules you’ve set should work just fine - except that your web server must now accept ANY web site name and then redirect to your own website.
Consider this:
- I type http://www.example.com/examples/basic.html into my browser.
- My computer finds the IP address of the host http://www.example.com in DNS to be 192.0.2.101
- My computer sends request to open a TCP socket to 192.0.2.101 on port 80.
- The Mikrotik does dstnat and re-writes the destination IP address on the packet to be 192.168.88.250 and then forwards the packet to your web server
- The web server accepts the connection and TCP is established (nat happens on each packet in this process, so I won’t mention it anymore)
- My computer will then ask the HTTP daemon on your server to please serve the file /examples/basic.html from host http://www.example.com
This is where things go off the rails…
If your server is configured to always “just be itself” regardless of the host name specified by clients, then that’s fine - but it will then look for the file my browser requested - it will look in the HTML folder for a sub-folder called “examples” and in that folder, it wants a file called “basic.html” - chances are almost certain that you don’t have this file on your server, so the server is going to say “Sorry, buddy - I don’t have that file. Error code 404”
OR - if your server DOES know what hostnames are, it will connect the session to the default website regardless of name, where the above problem happens… OR - if the server will ONLY respond to requests for its specific host name - then who knows what error it’s going to give, but it’s going to fail in some way…
So the solution is to tell your web server that it should use a custom 404 (file not found) error page - and you make a custom 404 page that has a redirect header instructing the browser to go instead to http://192.168.88.250/mywebsite.html (or if you have DNS inside your network, you could use http://your-website-name-here/)
One more problem with your dstnat rule is that you specify tcp ports 80,443 to match, but specify to-ports=80
This means that connection attempts to reach port 443 on the web will be redirected to your server on port 80.
SSL won’t work on port 80, so I suggest that you remove the to-ports=80 (leave that unspecified, and the port won’t get modified)
Of course now you have another problem - that being you need an SSL certificate for your server so that it can operate on port 443 as well, and unfortunately, this is going to give users a warning message “WARNING: the certificate doesn’t match the site you requested” - but there’s not really any easy way around this for SSL, but it’s probably better to have this happen so that at least the users will know that the connection is doing something. If you just drop port 443 (or map it to port 80) then the connection is just going to sit there until the browser gives up, giving the illusion that they’re having a problem with their connection.
Realize that these days, many people’s browsers’ default pages are going to be SSL-enabled websites, so you’d rather give the SSL warning than just let the browser open up and not do anything. You could perhaps just reject port 443 (reject with tcp-reset) so that browsers will tell the user “connection refused” immediately, and then they’ll try typing in something different - almost certainly without putting https:// at the beginning - and then you’ll have them on your website.