Hello,
I have 2 standalone machines that are identical and use the same IP addresses.
They are currently not integrated in any network.
I would like to access these 2 machines (VNC) from a remote PC, but I can’t change their IP addresses.
Is it possible to make this setup work using NAT based on physical port / interface?
Or a port forwarding based on physical port may also work?
Here a schema of the configuration:
I think I have seen a similar question recently and if I’m not mistaking, you need to use some sort of address remapping based on port.
Edit: I knew I saw it already before not too long ago 
http://forum.mikrotik.com/t/map-devices-with-identical-ip-to-external-ip-based-on-port/180074/1
Yep, but we have no final report of success (if any) on that thread.
There is however a similar one where everything is seemingly working:
http://forum.mikrotik.com/t/hex-lite-for-routing-between-subnets/180206/1
(though still not a fully working complete configuration)
Thank you both for your answer.
I started following the first thread, and had some issues until I realized there was a small typo in the firewall nat rules, where action and chain are swapped.
Once this was fixed, the solution was working as intended.
The issue is here:
add action=dst-nat chain=netmap dst-address=192.168.1.200 to-addresses=10.1.1.20
add action=dst-nat chain=netmap dst-address=192.168.1.201 to-addresses=10.1.1.20
which should be:
add action=netmap chain=dst-nat dst-address=192.168.1.200 to-addresses=10.1.1.20
add action=netmap chain=dst-nat dst-address=192.168.1.201 to-addresses=10.1.1.20
Edit:
Here is the full working config in case someone has the same issue:
/ip address
add address=192.168.1.1/24 interface=ether1 network=192.168.1.0
add address=10.1.1.1/24 interface=ether2 network=10.1.1.0
add address=192.168.1.200 interface=ether1 network=192.168.1.0
add address=192.168.1.201 interface=ether1 network=192.168.1.0
add address=10.1.1.1/24 interface=ether3 network=10.1.1.0
...
/ip firewall mangle
add action=mark-connection chain=prerouting dst-address=192.168.1.200 new-connection-mark=port1
add action=mark-connection chain=prerouting dst-address=192.168.1.201 new-connection-mark=port2
add action=mark-routing chain=prerouting connection-mark=port1 new-routing-mark=port1 passthrough=no
add action=mark-routing chain=prerouting connection-mark=port2 new-routing-mark=port2 passthrough=no
...
/ip firewall nat
add action=netmap chain=dst-nat dst-address=192.168.1.200 to-addresses=10.1.1.20
add action=netmap chain=dst-nat dst-address=192.168.1.201 to-addresses=10.1.1.20
add action=masquerade chain=srcnat out-interface=ether2
add action=masquerade chain=srcnat out-interface=ether3
...
/ip route
add distance=1 dst-address=10.1.1.0/24 gateway=ether2 routing-mark=port1
add distance=1 dst-address=10.1.1.0/24 gateway=ether3 routing-mark=port2
Good job !
Very good. 
What still needs to be cleared (at least to me) is whether the netmap and the dst-nat actions can be exchanged at will or not (it seems that in cases like this one both work, so it is not clear if there is a reason to prefer the one over the other).
To be fair sindy did attempt to explain the difference:
the difference between netmap and (src|dst)-nat actions is that in case of netmap, the to-addresses parameter holds a prefix that is used to replace the prefix of the original address, leaving the suffix unchanged, whereas in case of (src|dst)-nat, to-addresses contains a list or range from which a whole address is “randomly” chosen to replace the original one. But same like (src|dst)-nat, the netmap action also replaces only one address, destination or source, depending on the chain where it is used (dstnat or srcnat).
but I still fail to appreciate the (possibly too subtle for my limited experience) difference in practice, i.e. when to use the one or the other.
@neoraptor
JFYI, the solution advised by sindy on the second thread:
http://forum.mikrotik.com/t/hex-lite-for-routing-between-subnets/180206/1
is actually more elegant as - by cleverly making use of interface list and address ranges - the number of firewall rules are reduced.
I checked sindy proposal and it indeed simplify the configuration a bit (less firewall rules).
Here is the updated config:
/ip address
add address=192.168.1.1/24 interface=ether1 network=192.168.1.0
add address=10.1.1.1/24 interface=ether2 network=10.1.1.0
add address=192.168.1.200 interface=ether1 network=192.168.1.0
add address=192.168.1.201 interface=ether1 network=192.168.1.0
add address=10.1.1.1/24 interface=ether3 network=10.1.1.0
...
/ip firewall mangle
add action=mark-routing chain=prerouting dst-address=192.168.1.200 in-interface=ether1 new-routing-mark=via-ether2 passthrough=yes
add action=mark-routing chain=prerouting dst-address=192.168.1.201 in-interface=ether1 new-routing-mark=via-ether3 passthrough=yes
...
/interface list
add name=DEVICES
/interface list member
add interface=ether2 list=DEVICES
add interface=ether3 list=DEVICES
...
/ip firewall nat
add action=dst-nat chain=dstnat dst-address=192.168.1.200-192.168.1.201 in-interface=ether1 to-addresses=10.1.1.20
add action=masquerade chain=srcnat out-interface-list=DEVICES
...
/ip route
add distance=1 dst-address=10.1.1.0/24 gateway=ether2 routing-mark=via-ether2
add distance=1 dst-address=10.1.1.0/24 gateway=ether3 routing-mark=via-ether3
As you pointed out, both variants with netmap and dst-nat are working in this case.
Sandy explained the difference more in detail in this post > http://forum.mikrotik.com/t/netmap-vs-srcnat/143946/1
I noticed a weird behavior with both versions though:
It looks like the default dynamic route is used when the interface is not reachable.
How can I prevent this ?
edit: my routes are:
/ip route> print
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
B - blackhole, U - unreachable, P - prohibit
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 A S 10.1.1.0/24 ether2 1
1 A S 10.1.1.0/24 ether3 1
2 ADC 10.1.1.0/24 10.1.1.1 ether2 0
ether3
3 ADC 192.168.1.0/24 192.168.1.1 ether1 0
What are the routes (/ip route print) at the time the machine is disconnected (pull the cable)?
Very likely the routing rule (that is for “new-routing-mark=port1”) that in your posted output is #0 is not anymore AS (Active, Static) but becomes just S or IS (Inactive), and either the “generic” route takes precedence or (for whatever reason) the other identical route (which should be for “new-routing-mark=port2” only) is used.
I suspect the first, the router tries desperately to reach destination, but cannot say for sure.
In these cases usually a blackhole rule is added with a higher distance, you would need two of them, like:
/ip route
add blackhole distance=2 dst-address=10.1.1.0/24 routing-mark=via-ether2
add blackhole distance=2 dst-address=10.1.1.0/24 routing-mark=via-ether3
The idea is that since distance is 2 these two are never actually used when the devices are present and working.
But when one (or both) the routes with distance 1 become inactive, the rules with higher distance become instantly in use.
Thanks for the explanation. It was indeed the default rule that took precedence (#0 became S when cable is unplugged).
Adding the 2 blackholes rules solves this issue and is required to maintain clear separation between the 2 machines when one of them is unplugged.
Here the full working config in case someone needs it:
/ip address
add address=192.168.1.1/24 interface=ether1 network=192.168.1.0
add address=192.168.1.200/24 interface=ether1 network=192.168.1.0
add address=192.168.1.201/24 interface=ether1 network=192.168.1.0
add address=10.1.1.1/24 interface=ether2 network=10.1.1.0
add address=10.1.1.1/24 interface=ether3 network=10.1.1.0
...
/ip firewall mangle
add action=mark-routing chain=prerouting dst-address=192.168.1.200 in-interface=ether1 new-routing-mark=via-ether2 passthrough=yes
add action=mark-routing chain=prerouting dst-address=192.168.1.201 in-interface=ether1 new-routing-mark=via-ether3 passthrough=yes
...
/interface list
add name=DEVICES
/interface list member
add interface=ether2 list=DEVICES
add interface=ether3 list=DEVICES
...
/ip firewall nat
add action=dst-nat chain=dstnat dst-address=192.168.1.200-192.168.1.201 in-interface=ether1 to-addresses=10.1.1.20
add action=masquerade chain=srcnat out-interface-list=DEVICES
...
/ip route
add distance=1 dst-address=10.1.1.0/24 gateway=ether2 routing-mark=via-ether2
add distance=2 dst-address=10.1.1.0/24 routing-mark=via-ether2 type=blackhole
add distance=1 dst-address=10.1.1.0/24 gateway=ether3 routing-mark=via-ether3
add distance=2 dst-address=10.1.1.0/24 routing-mark=via-ether3 type=blackhole
Very good.
The syntax I posted was for Ros 7, sorry 
, but I see you adapted it to your Ros 6.x just fine .
Almost caught up. Just trying to follow the traffic flow starting at the controller. My logic is missing something in these steps. 
How does the controller know to look for a machine at 192.168.200 or 192.168.201.
Assuming it knows for some reason, following the bouncing ball…
Since mangling happens first, we capture the traffic originating in ether1 heading for an IP address in the same subnet.
Is that even possible? Its within the same subnet so my thought was it could not be captured by a router (since its mac address traffic not requiring IP???)
Okay so lets say its possible, and it makes sense, sigh. We ensure that the traffic when routed will go to the correct etherport via the mangling and tables etc…
Then the traffic hits destination NAT, where it changes the the destination IP to the actual IP of the machine.
The traffic goes to the appropriate route that holds now the correct destination and due to mangling the correct port.
Good so far…
RETURN Traffic, what is important here is noting that the source address of the traffic has not changed and is still the IP of the controller.
Therefore upon leaving the port, the traffic has the correct destination IP and due to source nat is given the generic IP of the subnet that is common to ether2,3,4. I am not sure why this latter point is important??? What would happen if source address was the actual machine IP and not sourcenatted?
In any case the traffic can follow normal routing back to the controller.
Thanks for your help. It was indeed quite easy to convert it to Ros 6.
It is tested and working perfectly fine 
As I understand it, the mangle rule tell to route the trafic for either 192.168.1.200 or 201 directly to the interface ether2 or 3.
/ip firewall mangle
add action=mark-routing chain=prerouting dst-address=192.168.1.200 in-interface=ether1 new-routing-mark=via-ether2 passthrough=yes
add action=mark-routing chain=prerouting dst-address=192.168.1.201 in-interface=ether1 new-routing-mark=via-ether3 passthrough=yes
The NAT rule will rewrite the destination IP from 192.168.1.200 or 201 to 10.1.1.20 (which is the same on both interface).
add action=dst-nat chain=dstnat dst-address=192.168.1.200-192.168.1.201 in-interface=ether1 to-addresses=10.1.1.20