It would be nice to have a Reverse Proxy functionality built into ROS such that dst-nat would forward traffic to different web servers on the internal networks based on the DNS name requested. It would also be pretty cool if this functionality allowed for traffic to be passed to a VPN server interface on the router as well, i.e. requests for sstp.yourdomain.com on port 443 get forwarded to the SSTP server binding (assuming you’re using SSTP for remote access), but requests for webmail.yourdomain.com on 443 get forwarded to an internal or DMZ server hosting your webmail platform.
It would be nice. Maybe I am not enough educated but how the router having only one public ip on its wan interface can know to which of more internal servers the incoming http get packet belongs to?
Most web servers these days support SNI, which allows a single web server to server different web sites depending on the hostname that is in the HTTP request. A web server set up as a reverse proxy is capable of doing the same thing. See here (https://httpd.apache.org/docs/2.4/vhosts/examples.html) in the “Using virtual host and mod_proxy together” section. Effectively, by implementing a reverse proxy on the router that supports SNI/virtual hosts, the router would examine the hostname requested in the HTTP header, and then lookup the corresponding internal address:port to which it should proxy that connection.
You could do a poor-man’s version of this by specifying a range of to-addresses…
e.g. action=dst-nat to-addresses=192.168.3.1-192.168.3.10
As long as all 10 of these addresses were running http services and had the same content, then this would work - the biggest concern would be that they (the servers) would need to be able to share session tokens for dynamic content so subsequent http requests that round-robin to a different server will still be serviced with the correct session information… but that’s a task that’s still required in a reverse-proxy scenario as well.
The biggest drawbacks with this method are that it doesn’t detect and remove dead servers from the address pool, and it doesn’t do effective load sharing - if server3 is really busy, but the next connection hashes to server 3 as well, then server 3 is getting the new connection, even if server 4 has zero clients at the moment.
Also it doesn’t cache the content like a reverse proxy does, so it doesn’t alleviate as much load from the actual server pool as a reverse proxy would.
You can go even one step further and have almost real reverse proxy, with different domains on different backends, see wiki example. The major drawback of this one is that it’s http only, no https. And I’m also almost sure that web proxy was not intended by MikroTik to be used like this, it’s more like clever hack.
Btw, I think there are two ways how to look at reverse proxy in RouterOS:
-
Simple way to solve address shortage. You have one public address and need to host two or more websites, that for some reason have to be on separate internal servers. No need for any fancy stuff like caching or load balancing. With all what’s there already, it should be very easy to implement if MikroTik wanted to. Basically reuse web proxy code, add proper config for backends, instead of above dns hack, then ability to listen on https port and it’s done. And it would be very useful for many people.
-
Real reverse proxy with everything. Should I be the first one to yell “but it’s a router!”? Just kidding, I’m for every possible feature (bigger ones could always be as separate packages), but someone was bound to say it sooner or later.
Yes please to this!