Greetings!

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

1. Is it feasible to use an interface to port forward?
2. What configuration would that be?

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.

@pimmie, yes.

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?

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.

Will have to research this one. I am also new to mikrotik. I just used their available equipment which happens to be mikrotik ccr

@pimmie, yes.

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?

The exisitng configuration of the clients are on default. They also used default ports like port 80

Will have to research this one.

@pimmie is essentially proposing the inverse of a typical PCC load-balancing configuration. Instead of one LAN fed by two ISPs, you have two LANs accessed from the one-and-only Internet.

They also used default ports like port 80

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

I get the error "outgoing interface matching not possible in input and prerouting chains" when I put out interface

That’s why you need the mangle rules and additional routing tables @pimmie initially suggested.

Study that PCC doc I linked above. Once you understand it, you will understand how to invert the configuration to meet your needs.

Here's my export. Please bear with me since I'm new to mikoritk

RouterOS 7.8

/interface ethernet
set [ find default-name=ether1 ] name=ether1-WAN
set [ find default-name=ether2 ] name=ether2-Client1
set [ find default-name=ether3 ] name=ether3-Client2


/routing table
add disabled=no fib name=to_Client1
add disabled=no fib name=to_Client2


/ip address
add address=192.168.150.2/24 interface=ether2-Client1 network=192.168.150.0
add address=192.168.150.3/24 interface=ether3-Client2 network=192.168.150.0
add address=10.10.10.23/24 interface=ether1-WAN network=10.10.10.0

/ip firewall mangle
add action=accept chain=prerouting dst-address=192.168.150.0/24 in-interface=ether1-WAN
add action=accept chain=prerouting dst-address=192.168.150.0/24 in-interface=ether1-WAN
add chain=prerouting action=mark-connection new-connection-mark=Client1_conn passthrough=yes connection-mark=no-mark in-interface=ether2-Client1 log=no log-prefix=""
add chain=prerouting action=mark-connection new-connection-mark=Client2_conn passthrough=yes connection-mark=no-mark in-interface=ether3-Client2 log=no log-prefix=""
add action=mark-routing chain=prerouting connection-mark=Client1_conn in-interface=ether1-WAN new-routing-mark=to_Client1 passthrough=yes
add action=mark-routing chain=prerouting connection-mark=Client2_conn in-interface=ether1-WAN new-routing-mark=to_Client2 passthrough=yes
add action=mark-routing chain=output connection-mark=Client1_conn new-routing-mark=to_Client1 passthrough=yes
add action=mark-routing chain=output connection-mark=Client2_conn new-routing-mark=to_Client2 passthrough=yes


/ip firewall nat
add action=dst-nat chain=dstnat dst-address=10.10.10.23 dst-port=9999 in-interface=ether1-WAN protocol=tcp routing-mark=to_Client1 to-addresses=192.168.150.150 to-ports=80
add action=dst-nat chain=dstnat dst-address=10.10.10.23 dst-port=9998 in-interface=ether1-WAN protocol=tcp routing-mark=to_Client2 to-addresses=192.168.150.150 to-ports=80

add action=masquerade chain=srcnat out-interface=ether2-Client1
add action=masquerade chain=srcnat out-interface=ether3-Client2


/ip route
add check-gateway=ping distance=1 dst-address=0.0.0.0/0 gateway=192.168.150.2 pref-src="" routing-table=main scope=30 suppress-hw-offload=no target-scope=10
add check-gateway=ping distance=1 dst-address=0.0.0.0/0 gateway=192.168.150.3 pref-src="" routing-table=main scope=30 suppress-hw-offload=no target-scope=10
add check-gateway=ping distance=1 dst-address=0.0.0.0/0 gateway=192.168.150.3 pref-src="" routing-table=to_Client2 scope=30 suppress-hw-offload=no target-scope=10
add check-gateway=ping distance=1 dst-address=0.0.0.0/0 gateway=192.168.150.2 pref-src="" routing-table=to_Client1 scope=30 suppress-hw-offload=no target-scope=10

Where is the rest of the config, firewall rules, NAT, etc.....

That's the config under test environment.

@patterno

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

@patterno

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

Added this

dst-address=192.168.150.2/32 interface=ether2-Client1 action=lookup-only-in-table table=to_Client1
dst-address=192.168.150.3/32 interface=ether3-Client2 action=lookup-only-in-table table=to_Client2

Still can't get it to work

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