A friend recently asked for help with setting up a microtic. The request was not quite simple. The idea is that you had to simultaneously manage four devices with an unmanaged TCP / IP stack from one host. All these devices had the same IP settings, and just the IP address and mask, neither the gateway nor the DNS are listed. Strange, but as it turned out, a very real situation. We will not go into details of the reasons for the impossibility of reconfiguring addressing on these devices, but simply take this fact as an axiom. The task is set as it is, and it needs to be solved.
So, the source data:
1. Four devices with the same IP settings - 192.168.1.1/24; GW and DNS are not listed; It is not possible to change these settings.
2. A PC from which you need to simultaneously have access to all four devices, let's say on the WEB interface.
3. Simple MikroTik RB750GL on 5 ports.
MikroTik RB750GL with default settings uses 1 port for connecting to the Internet (NAT, FW), and the remaining ports for connecting to a local network with DHCP configured - like a normal home router or a Small Business router of a series. We need to use all 5 ports, so first we completely clean the config and get rid of NAT, FW and DHCP.
So, the cofig was cleared, we assemble the scheme:

')
Now to the point ...
The first and main problem that confronts us is the use of identical IP addresses or IP addresses from the same subnet on different interfaces of the router to ensure the network availability of target devices. How to interpret the basics of networking with a single routing table is impossible. So you need to make several routing tables, and Virtual Routing and Forwarding (VRF) will help us in this. We will not dive into VRF much - we just need to put different interfaces in different routing tables:
/ ip route vrf
add interfaces = ether1 routing-mark = DEV1
add interfaces = ether2 routing-mark = DEV2
add interfaces = ether3 routing-mark = DEV3
add interfaces = ether4 routing-mark = DEV4
Fine. Now we will configure IP addressing according to the scheme:

The IP address 192.168.2.1 will be used to access the management of MikroTik himself:
/ ip address
add address = 192.168.2.1 / 24 interface = ether5 network = 192.168.2.0
add address = 192.168.1.2 / 24 interface = ether1 network = 192.168.1.0
add address = 192.168.1.2 / 24 interface = ether2 network = 192.168.1.0
add address = 192.168.1.2 / 24 interface = ether3 network = 192.168.1.0
add address = 192.168.1.2 / 24 interface = ether4 network = 192.168.1.0
Recall that the devices themselves, which need to be managed, also lack the ability to configure the default gateway. We also need to somehow share these devices for access with the MGMT PC. Naturally NAT. For each device, select the IP from the 192.168.2.0/24 subnet and configure it on the ether5 interface:
/ ip address
add address = 192.168.2.11 / 24 interface = ether5 network = 192.168.2.0
add address = 192.168.2.12 / 24 interface = ether5 network = 192.168.2.0
add address = 192.168.2.13 / 24 interface = ether5 network = 192.168.2.0
add address = 192.168.2.14 / 24 interface = ether5 network = 192.168.2.0
We don’t touch the NAT itself and remember that our packages should run between different routing tables. To do this, you need to set route labels according to new IP addresses, which we will later NAT'irovat. According to the NetFilter documentation, the Mangle table, which is responsible for marking traffic, works before the NAT table. Based on this fact we do the following:
/ ip firewall mangle
add action = mark-routing chain = prerouting dst-address = 192.168.2.11 new-routing-mark = DEV1
add action = mark-routing chain = prerouting dst-address = 192.168.2.12 new-routing-mark = DEV2
add action = mark-routing chain = prerouting dst-address = 192.168.2.13 new-routing-mark = DEV3
add action = mark-routing chain = prerouting dst-address = 192.168.2.14 new-routing-mark = DEV4
Based on these rules, packets arriving at the ether5 interface from the management host, according to the destination IP address, will be transferred to the desired routing table, to the correct port to the target device.
Return packets from devices must be returned to the main routing table on the ether5 interface where our management host is connected. To do this, add another rule to Mangle:
/ ip firewall mangle
add action = mark-routing chain = prerouting dst-address = 192.168.2.2 new-routing-mark = main
Based on this rule, all packets with the destination address 192.168.2.2 will be transferred to the main routing table "main", in which the management host interface is located.
It remains to think about NAT. For each device, we will have two rules:
/ ip firewall nat
add action = dst-nat chain = dstnat dst-address = 192.168.2.11 in-interface = ether5 to-addresses = 192.168.1.1
add action = src-nat chain = srcnat out-interface = ether1 to-addresses = 192.168.1.2
add action = dst-nat chain = dstnat dst-address = 192.168.2.12 in-interface = ether5 to-addresses = 192.168.1.1
add action = src-nat chain = srcnat out-interface = ether2 to-addresses = 192.168.1.2
add action = dst-nat chain = dstnat dst-address = 192.168.2.13 in-interface = ether5 to-addresses = 192.168.1.1
add action = src-nat chain = srcnat out-interface = ether3 to-addresses = 192.168.1.2
add action = dst-nat chain = dstnat dst-address = 192.168.2.14 in-interface = ether5 to-addresses = 192.168.1.1
add action = src-nat chain = srcnat out-interface = ether4 to-addresses = 192.168.1.2
Thus, using NAT and VRF, we presented devices with identical IP addresses for the controlling host as devices with different IP addresses, and using NAT on interfaces that look towards these devices, they allowed them to work without a gateway. default.
As a result, to control target devices (for example, via a web interface) on the controlling host, type in the browser:
DEV1 - 192.168.2.11
DEV2 - 192.168.2.12
DEV3 - 192.168.2.13
DEV4 - 192.168.2.14