Hello Forum.
I've just getting my Internet connection upgraded, but unfortunably there is only 1 public IP available.

Therefor I would like to hear if its possible to filtering the incomming traffic using a Domain name insted of a destination IP.
I've got some servers at home and would like to filtering the traffic in the firewall insted of using Proxy in the apache server.

I would like to get this up and running.
If the destionation is domain1.dk - then the forwarded port should be forwarded to 192.168.0.10
All others domains (many) - the the forwarded port should be forwarded to 192,168,0,20

Is this possible to make work ?
Mostly becarse I'm needing 2 seperate mailservers - but still using the same incomming ports

Thanks in advance

No, this is impossible.
This has nothing to do with limitations of MikroTik, it is just impossible.

OK Thanks for the Reply

So there's no way to make this work properly unless you'll have 2 public IP's .
I was hoping the Firewall was able to filter incomming traffic depending oin the DNS name instead of the IP!

I think this could be possible, with some scripting. If I understand correctly you have 1 static public IP and more dynamic IPs that are connected with some A records ?

You could do two nat rules, with diffrent dst-addresses. Than create script that every 10 seconds resolves dns name, and use that IP on one of the NAT rules, and the other one stays without dst-address only in-interface=wan_interface.

So if connection to port 25 would come to domain-name.com it would go to that specified NAT rule, otherwise it would skip the NAT rule, because it is not meant for this connection, and would capture itself on the nat rule for any dst-address on wan_interface.

I hope I understood you correctly.

OK Thanks for the Reply

So there's no way to make this work properly unless you'll have 2 public IP's .
I was hoping the Firewall was able to filter incomming traffic depending oin the DNS name instead of the IP!

It is not possible because the Firewall never sees that DNS name.
The user at the other end wants to connect to your services, THEY go to DNS and retrieve the address, then they
connect to that address and you get their connection not knowing what name they used to get to it.

Now, in some protocols that information may be part of the information exchange.
That is why a system like Apache can do it, in a webserver or a reverse-proxy.
But this cannot be done by simple "port forwarding".
Similar for mail: the user will tell the mail server where the mail has to go to. You can run a single mail server and
make it accept mail for the 2nd domain, then forward it. But the port forwarding needs to make the decision
at the time the connection comes in, and that is impossible.

So indeed you will need a second public IP address to do it using port forwarding and have two completely
separate servers.

If you can use different ports, you should be able to achieve this using SRV DNS records.

_smtp._tcp.domain1.dk.   86400 IN    SRV 10       10     2525 smtp.domain1.dk.
_smtp._tcp.example.com.   86400 IN    SRV 10       10     25 smtp.example.com.

where smtp.domain1.dk and smtp.example.com have the same public IP.

And on the router, you port forward 25 & 2525 to the appropriate servers.

That's not going to work well. To be honest, I have no idea if current mail servers support SRV records or not. But even it they did, there are too many old ones still in use (and will be for many years to come) that definitely don't.

I haven't looked into it specifically, but you can probably set up a single postfix server to act as a proxy/relay for both domains.  Effectively, you would forward all mail ports to this one postfix server which would accept inbound mail for both domains, and then forward them on to their respective individual servers on the internal network.  This would also allow you to offload any spam recognition and other security functions to the proxy/relay and cover both domains with the same setup instead of having to manage those functions separately on each domain's respective server.

I haven't looked into it specifically, but you can probably set up a single postfix server to act as a proxy/relay for both domains.  Effectively, you would forward all mail ports to this one postfix server which would accept inbound mail for both domains, and then forward them on to their respective individual servers on the internal network.  This would also allow you to offload any spam recognition and other security functions to the proxy/relay and cover both domains with the same setup instead of having to manage those functions separately on each domain's respective server.

Thank you, this was helpfull.

I am trying to do a similar thing. The proxy works and I get to the user access page on the individual servers behind the one public address using the reverse proxy. The problem is that after logging into my services the API is not http so the connection breaks. I am trying to find a way to get the proxy access rule to mark the connection so that it can be moved to a source address list (short duration 5min) this new rule would then allow new traffic to be dst-nat to the correct internal IP. I am not sure if this is the right direction to be looking into for a solution.

Thank you, this was helpfull.

I am trying to do a similar thing. The proxy works and I get to the user access page on the individual servers behind the one public address using the reverse proxy. The problem is that after logging into my services the API is not http so the connection breaks. I am trying to find a way to get the proxy access rule to mark the connection so that it can be moved to a source address list (short duration 5min) this new rule would then allow new traffic to be dst-nat to the correct internal IP. I am not sure if this is the right direction to be looking into for a solution.

I would avoid using the transparent proxy feature of RouterOS since it doesn't support https. Instead, set up an Apache web server as a reverse proxy. Using that kind of setup for the webmail access allows you to use https, and it can serve up different certificates based on the requested URL. Personally, I like to use CentOS with Apache. You'll have to do a little bit of work with SELinux to get everything working right (I think you need to change the httpd_can_network_connect setting...maybe some others as well), but it makes for a good solution.