Being a recent hire, my job was to port forward the web servers of clients 1 and 2 to the cloud. Their server was initially configured as a stand-alone, and since they are on entirely separate networks, their IP addresses were in conflict for unknown reasons. They have some current network configuration, thus I advised that they alter their IP subnet, but they are hesitant for some reason.
My inquiries are
Is it feasible to use an interface to port forward?
I think you should be able to add two routing tables, add each interface to their own routing table (using a routing rule) and then use a mangle rule to forward incoming traffic to either routing table using a routing mark.
The only remaining question is how will they discriminate the incoming connections? Will it be acceptable to port-forward $PUBLIC_IP:8000 to Web Server 1 and :9000 to Server 2, or are they going to want some type of domain name-based routing?
If all Internet clients connect to port 80 on your RouterOS gateway, how will the router know which private LAN server to direct the traffic to?
If you can do it with a different port number per back-end server, the routing is easy.
If it has to take a domain name instead — server1.example.com, server2…, etc — then you need a reverse-proxy in the middle, which not only adds complexity, it means we have to ask where that proxy server lives.
If by “ccr” you mean one of the ARM-based CCR2xxx series units, then you could install a Traefik proxy container, or similar. (I picked Traefik as a container-native example, but there are others, including the ever-popular ngnix.)
If instead you’re speaking of the older TILE-based CCR1xxx units, then you’ll need a separate server, at which point one wonders why you don’t multi-home it and do the routing with that instead of the RouterOS box?
Regardless, this isn’t trivial; you can’t expect to be provided canned configurations for all this, for free.
@tangent OP said the following and I assume he meant that each client has a separate external ip / network range
they are on entirely separate networks
@pattemo Assuming the two servers can already be reached at the moment, can you draw a network diagram of how it works now? And how/why does the new situation differ from the current one?
Where are those ‘separate networks’ you mentioned terminated? Does that happen on the Mikrotik CCR in your diagram or is there another device you didn’t show in the diagram? If it’s on the CCR, then just adjust your mangle rules to filter on the dst-address of each client
I think we’re getting caught up in a confusing use of “client” here. Study the diagram. OP refers to two business client hosts running servers on the same IP. The network clients are across the Internet, if I’m reading this correctly.
Yeah, it’s starting to get confusing but I also meant the dst-address of the business client not network client. As in I assume that client 1 has their own external ip A.B.C.1 that was being forwarded to 192.168.150.150 and client 2 had A.B.C.2 that was also being forwarded to 192.168.150.150.
In any case, I guess OP needs some form of ingress filtering but we can’t advise on that without a better understanding of how the networks of those clients were separated originally. Maybe OP could make a diagram of the original situation he mentioned:
Their server was initially configured as a stand-alone, and since they are on entirely separate networks
Basically we need to port forward the ip addresses of client1 (ether2) and client2 (ether3) which is 192.168.150.150. In this case, they have a same ip address. Both client1 and client2 are connected on a single mikrotik CCR. We will use a single wan ip(ether1) which is 10.10.10.23
The scenario is the when a user access 10.10.10.23:9999(sample port only) then it will redirect to client1 192.168.150.150:80.
Then if another user access 10.10.10.23:9998(sample port only)then it will redirect to client2 192.168.150.150:80
In the config, I get the error “outgoing interface matching not possible in input and prerouting chains” when I put out interface
You are at least missing a routing rule, you’ve created a routing table but those are empty atm and you have to add each client ethX to the correct table using a routing rule (with action=lookup-only-in-table).
And the static routes you added should be tweaked a bit more too
The dst-address are not needed in the routing rules, you should remove those. Only add a rule that says interface=ether2-Client1 action=lookup-only-in-table table=to_Client1 etc
It might help to divide the task up into smaller steps so you limit the amount of complexity and things that can go wrong in each step you take. You mentioned you have a test environment, try to make it work without the port dst-nat first. So instead of forwarding 10.10.10.23:9999 to client1 and 10.10.10.23:9998 to client 2, try to get it to work with forwarding 10.10.10.23:80 to client1 and 10.10.10.24:80 to client2. That should be a pretty basic routing setup (look at the PPC setup that @tangent mentioned). Only after you managed to get the routing tables to work you should look into port forwarding.
So the best advise I can give you is to:
Break the task down into smaller, easier to understand steps
Upgrade to the latest RouterOS (your export says you are still on 7.8, why?)
If not already, use Winbox not cli or web
Use tools → torch extensively to see what traffic is coming in and if/where traffic returns (ie check if there is both tx as rx). Note that when using torch ingress & egress traffic can be visible on different interfaces, especially when routing is misconfigured. So try to run torch both on ether1 as on ether2
Set up a terminal that sends continuous traffic to the client you are interested in so you know for sure that there should be traffic visible in torch. If you skip the port dst-nat and just try to get it work with the 10.10.10.23/24 ip addresses at first, you can open a terminal and setup a ping to 10.10.10.23 or 24
Add ip firewall rules that log the traffic you are interested in, both in the firewall as the nat tables. The logged packets could show you fe which in/out interfaces the packets you are interested in are using.
As already said in my previous message, it seems your ip routes & ip firewall mangle needs a bit more tweaking still
