Route traffic to two terminals with overlapping IPs

RouterOS Beginner Basics
1

Hello World,
thanks in advance for your support Mikrotik forum...you're my only hope.

I'm a hardware engineer working for a test engineering company. I designed a test solution for an important defense customer where a MikroTik hEX refresh router was identified as a possible solution for the following problem: connecting two identical devices that have the same fixed IP addresses.

My current setup is:
ether1: PC
ether 2 (or 3, or 5): Terminal 1 - 192.168.1.11...14 and 192.168.2.21...24
ether 4: Terminal 2 - 192.168.1.11...14

For some tests, I need to access a web page (TCP port 80) or ping either device using the same IP address. The IP addresses of the terminals cannot be changed. The idea we came up with was to NAT Terminal 2 to a different IP range, so that a request from the PC to, for example, 192.168.3.11 would be translated to Terminal 2's actual IP 192.168.1.11.

I'm really not into network administration (I have a degree in EE), so my first attempt was to make extensive use of Gemini, ChatGPT, and Claude. They were all in broad agreement and led me to essentially the same configuration, which ultimately resulted in three days of wasted time experimenting with VRF + mangle + NAT.

The closest setup I reached was the following, configured through WinBox:

  • Factory preset (keeping configuration)

  • Changing in Quick-set IP address range from ...1.1 and DHCP range ...100-254 (this way I can use a PC without a static IP). [Now the Terminal 1 register to the bridge]

  • Removing ether4 from the bridge (I use it for Terminal 2), Removing ether1 from DHCP client and adding it to the bridge (I use it for the PC) [now I can use PC with the Terminal 1]

  • IP/VRF adding "vrf-REF" with interface "ether4", then setting IP/Addresses 192.168.1.1/24 to ether4 [now the two overlapping network exists but are isolated]

    1. IP/Firewall/Mangle:
      prerouting
      in-interface=bridge
      dst-address=192.168.3.11
      action=mark-routing
      new-routing-mark=vrf-REF
    2. IP/Firewall/NAT:
      DST-NAT:
      dst-address=192.168.3.11
      in-interface=bridge
      action=dst-nat
      to-addresses=192.168.1.11

    SRC-NAT:
    dst-address=192.168.1.11
    out-interface=ether4
    action=src-nat
    to-addresses=192.168.1.1
    [now the things got weird: I can ping Terminal 1 using both 1.11 3.11 but not Terminal 2!]

Can someone pinpoint maybe the obvious error and get the things work and get the customer spare my life?

Thanks in advance,
Spaghetto

2

Without judgement, but I'm always amazed at the use of passive voice in these narratives: "the hEX Refresh was identified..." - surely whoever identified it will provide the necessary configuration, no?

Anyway, actually whoever it was is right, and Mikrotik devices in general are well suited for these sorts of setups, and the hEX Refresh is an ideal choice (limited only by the number of ports.)

The relevant literature:
1:1 NAT / DNAT configuration help (discussion)
Quick Guide: Bidirectional 1:1 NAT (SNAT, DNAT) Setup w/ working example (worked solution)

If you have more questions after processing these, go ahead.

3

Hi,

for a long time we have been asking for removing that part of ROS from the standard package as it only implies troubles. It's one time wizzard that should be removed/hidden after the initial setup.

You should clear the configuration, start from "tabula rasa" and apply what @lurker888 suggested. Do not "add" to your current setup, start from "tabula rasa".

4

Hi @lurker888 and @Bartosz ,
first of all thanks for your answers.

Passive voices are not to address to the fact that I'm not an english native speaker neither to the ChatGPT message reviewing (which always try to depict me as a Lord, which I am not) but rather to the fact that I was trying to hide my complete ignorance toward routers when picking out the hEX refresh straight from a ChatGPT (again, sigh) chat. To answer the question, no, the AI gave me only unnecessary malfunctioning configurations.

Thanks to your post, starting from scratch (!), I managed to have some successful tests, in the following configuration:
ether1: (Reserved for future use)
ether2: PC (static 192.168.1.100/255.255.252.0)
ether3: UUT (LAN where static endpoints exist as 192.168.1.11...1.12...1.13...1.14...2.21...2.22...2.23...2.24)
ether4: (Reserved for future use)
ether5: REF (LAN where static endpoints exist as 192.168.1.11...1.12...1.13...1.14)

Following the Quick Guide I correctly managed the NATting from PC to REF ...1.11, the REF see the PC as 1.200 and the PC see the REF as 1.111, this work flawlessly. Thanks.

Based on my (crappy) experience gained from the ChatGPT journey of failure , I created a bridge on "LAN" interface members ether1:4 and expanded on the address list on the bridge itself to ...1.1/22. I can access to these address with no problem. I also made some modifications to NAT\MANGLEing rules to expand from the PC etherX to the whole LAN (Even if unnecessary).

The very last problem is that I can't expand the NATting from the PC to the remaining IPs on the REF side (ether5: ...1.12...,1.13,...1.14). I can correctly ping from REF (1.12) the PC (1.200) but not the contrary. I tried duplicating the dst-nat and mark-routing mangle rules provided for the first REF working on 1.11 but I think a PEBCAK issue does esist here.

Can you dive me an hint on what I am doing wrong?

Thanks in advance for any help, follow the hEX /export.

[admin@STTE-Router] > /export

2026-01-29 11:25:55 by RouterOS 7.20.8
software id = CH22-S31L
model = E50UG
serial number = <NDA here!>

/interface bridge
add name="PC+UUT Bridge"
/interface list
add name=REF-PORT
add name=LAN
/routing table
add disabled=no fib name=to-ref
/interface bridge port
add bridge="PC+UUT Bridge" interface=LAN
/ip firewall connection tracking
set enabled=yes
/ip neighbor discovery-settings
set discover-interface-list=!dynamic
/interface list member
add interface=ether2 list=LAN
add interface=ether5 list=REF-PORT
add interface=ether1 list=LAN
add interface=ether3 list=LAN
add interface=ether4 list=LAN
/ip address
add address=192.168.1.1/24 comment="Edge Network Primary IP" interface="PC+UUT Bridge" network=192.168.1.0
add address=192.168.1.200/24 comment="REF Network" interface=ether5 network=192.168.1.0
add address=192.168.1.112/24 comment="REF External IP (12)" interface="PC+UUT Bridge" network=192.168.1.0
add address=192.168.1.111/24 comment="REF External IP (11)" interface="PC+UUT Bridge" network=192.168.1.0
/ip firewall mangle
add action=mark-routing chain=prerouting comment="Mark route to REF (11)" dst-address=192.168.1.111 in-interface="PC+UUT Bridge" new-routing-mark=
to-ref
add action=mark-routing chain=prerouting comment="Mark route to REF (12)" dst-address=192.168.1.112 in-interface="PC+UUT Bridge" new-routing-mark=
to-ref
add action=mark-connection chain=prerouting comment="Mark connection from PC side" connection-mark=no-mark in-interface="PC+UUT Bridge" 
new-connection-mark=from-mgmt
add action=mark-connection chain=prerouting comment="Mark connection from REF" connection-mark=no-mark in-interface=ether5 new-connection-mark=
from-ref
add action=mark-routing chain=output comment="Route to REF" connection-mark=from-ref new-routing-mark=to-ref
/ip firewall nat
add action=src-nat chain=srcnat comment="Source NAT to REF" out-interface-list=REF-PORT to-addresses=192.168.1.200
add action=dst-nat chain=dstnat comment="REF Inbound (11)" dst-address=192.168.1.111 in-interface="PC+UUT Bridge" to-addresses=192.168.1.11
add action=dst-nat chain=dstnat comment="REF Inbound (12)" dst-address=192.168.1.112 in-interface="PC+UUT Bridge" to-addresses=192.168.1.12
/ip route
add comment="Route to REF" disabled=no dst-address=192.168.1.0/24 gateway=ether5 routing-table=to-ref suppress-hw-offload=no
/routing rule
add action=lookup-only-in-table comment="REF Routing Rule" disabled=no routing-mark=to-ref table=to-ref
/system identity
set name=STTE-Router
5

The passive voice thing really wasn't meant as an insult.

The good news is that you seem to have somewhat mastered the handling of your Mikrotik device. This is actually the point where many people get stuck, because Mikrotik has a sort of peculiar way of doing things. This is actually the larger hurdle that you faced.

The bad news is that so far you have only managed to bridge together your devices, which is not what you want to do.

Just as an initial step, I would suggest two things to make your future life easier.

First, I'd suggest for you to upgrade the device to the current long-term support version, 7.21.5. Bugs are fixed all the time, and there's no point in potentially hunting down things that are already fixed. If the router doesn't have an internet connection, you can absolutely upload the files for upgrading manually, It's described here: Upgrade | RouterOS Manual

Also, it's nice to enable partitions on your device. This creates two 64 MB partitions in place of the single 128 MB one, and enables you to have two separate OS versions and configurations on the device. This is really helpful for any sort of debugging/testing/upgrade scenario.

Now on to your actual problem. I'd just like to verify that I understand everything, and also please provide the details that are missing.

So... you have devices (let's say 8 of them) on ether3, that have the addresses 192.168.1.11 .. 14 and 192.168.2.21 .. 24? What is the subnet mask (or prefix length) that these devices (themselves) are configured for? What is their default gateway? Do these devices communicate between themselves (here I mean the 192.168.1.x and the 192.168.2.x devices)? What are these devices (in broad terms, like PLC, data logger, etc.)?

Is the setup/devices the same, or roughly the same, on ether5? What are the differences?

Lastly, do you want the PC that you use to connect to this setup to have a network connection outside of this while arrangement? Possibly you want to connect one of it's interfaces (e.g. an ethernet adapter) to the Mikotik router, but remain connected to the company network over another (e.g. WiFi)? In case this is so, it would be useful to know what the subnet of your company network is, so that conflicts with it can be avoided.

My first instinct would be to use comletely separate address ranges for all purposes. By this I mean that e.g. the PC would get an address in the 192.168.80.x range, and would see the 192.168.1.0-192.168.2.255 network on ether3 as 192.168.81.0-192.168.82.255 and the 192.168.1.x network on ether5 as 192.168.83.x. This would have the benefit that by NAT-ing all networks, the "mode of connection" would be symmetrix between them, which (assuming UUT implies testing) would be beneficial.

The other way, of course, is allowing a direct (un-NAT-ed) connection to ether3, and only NAT-ing to ether5.

EDIT: The question which I think I have not articulated clearly is: are there actually three sets of devices? So are the 192.168.1.11 .. 14 devices of the same arrangement as the 192.168.2.11 .. 14, just the latter have renumbered IPs, while the ones connected to ether5 have not had this renumbering?

6

#1
Reset everything to default settings that give you BRIDGE for LAN + ETH1 for WAN.
BRIDGE would have assigned 192.168.88.1/24 address and all eth ports except eth1 + DHCP server etc.

#2
You want to use IPs from 192.168.1.0/24 pool and 192.168.2.0/24 pool, so the "higher level" one that covers these ranges is 92.168.0.0/22 (that gives you almost 1024 addresses. More than you need but you have to learn how to calculate network addresses and masks yourself.
Try to change appropriately, it would be a first step in your learning journey, all references the already assigned 192.168.88.1/24 or any other combination of 192.168.88.x/y to the new one 192.168.0.1/22 or 192.168.0.0/22.

Remeber that after IP change you will lose access to the router so do it using MAC connection.

#3
After that change reboot router and you will have configuration that covers all needed adresses as you specified.

The more simple way is to assign additional two adresses to the bridge configured with default settings.
just assign 192.168.1.1/24 to it and 192.168.2.1/24 to it and all devices should see each other and get the Internet access.
Why? It's your nxt homework.

7

Hi guys,
thanks again for the answers.

@lurker888 I'm finding difficulties in answer to your question since the moment the UUT is a classified object and I'm not receiving answers from the people I'm working for, the only chance I will have is a week of lab tests that I'm negotiating with them.

Moreover, I've to say that both the test equipment and the UUT (afaik) architectures are kinda complex, they are modular equipments but aside of their structure, to keep it simple, we can consider them, each of both, as a number of modules connected with unmanaged switches.

Let's start from the Mikrotik router, it see the network this way:
ether1: WAN - The port where we connect the site network for internet/remote management (Since we're dealing with COMSEC actually it's very illegal to to that so it's just "Reserved for future use" atm so please don't care about it)
ether2: LAN - The port where we connect the test equipment network where the main controller AND the testing instruments are connected (above with unmanaged switches) with the complete freedom of IP/mask/gateway choice.
ether3: UUT - The port where the unit under test reside. We can see the UUT as a number of modules are connected with an unknown way in the UUT itself, the test requirements list the following IPs: 192.168.1.11...1.12...1.13...1.14...2.21...2.22...2.23...2.24, but I have no information about masks and gateways.
ether4: Unused
ether5: REF - The port where we connect a golden reference unit (we need that for certain tests) which is identical to the UUT but is been accessed only to the following IPs: 192.168.1.11...1.12...1.13...1.14.

As I said above, Using a laptop as UUT\REF I've managed successfully the connection between PC<-->UUT with a bridge between ether1-4 and a 192.168.1.1/24 and 192.168.2.1/24 into /ip addresses (this last one is the very only change I've made so far in the configuration of my last post). (@BartoszP !)

Actually I'm stuck at the PC<-->REF communication where, following the quick guide above, I can NAT only the first 192.168.1.11 ip no matter if I duplicate the mangle\NAT rules for the other IPs (1.12...14). To be honest the very first idea that come up to my mind was, as you said, "to separate address ranges for all purposes", I was wondering (before your post that confirm the possibility) if it's possible to NAT the whole subnet so that PC see UUT 192.168.1.x as 192.168.3.x and UUT 192.168.2.x as 192.168.3.x then see REF 192.168.1.x as 192.168.5.x . This way giving me also more flexibility to manage eventual conflicts during validation. May I ask you for more info about this?

TU again for your precious support

8

Well, sooner or later you'll have to know more about the setup, but for now, this is what I'd suggest.

Let's assign a 192.168.0.0/24 address to the the PC on ether2, and route, with source NAT the 192.168.1.0/24 and 192.168.2.0/24 ranges on ether3. Further, let's map the 192.168.1.0/24 region on ether5 to 192.168.3.0/24 for the PC to access.

This is roughly how this goes: (the code is not tested)

# Assign addresses
/ip address add interface=ether2 address=192.168.0.1/24
/ip address add interface=ether3 address=192.168.1.1/24
/ip address add interface=ether3 address=192.168.2.1/24
/ip address add interface=ether5 address=192.168.1.1/24

# Set up DHCP for ether2
# This will set the PC's default route to point to the router, so this should be the only active network connection for it.
/ip pool add name=pc-dhcp-pool ranges=192.168.0.100-192.168.0.200
/ip dhcp-server add name=pc-dhcp interface=ether2 address-pool=pc-dhcp-pool
/ip dhcp-server network add address=192.168.0.0/24 gateway=192.168.0.1 dns-none=yes

# Set up routing
/routing table add fib name=terminal1
/routing table add fib name=terminal2

/routing rule add action=lookup-only-in-table routing-mark=terminal1 table=terminal1
/routing rule add action=lookup-only-in-table routing-mark=terminal2 table=terminal2

/ip route add dst-address=192.168.1.0/24 gateway=ether3 routing-table=terminal1
/ip route add dst-address=192.168.2.0/24 gateway=ether3 routing-table=terminal1
/ip route add dst-address=192.168.1.0/24 gateway=ether5 routing-table=terminal2

# Add a dummy default (and use a large metric)
/interface bridge add name=dummy protocol-mode=none
/ip route add dst-address=0.0.0.0/0 gateway=dummy distance=100

# Direct traffic in prerouting
/ip firewall mangle add chain=prerouting in-interface=ether2 dst-address=192.168.1.0/24 action=mark-routing new-routing-mark=terminal1
/ip firewall mangle add chain=prerouting in-interface=ether2 dst-address=192.168.2.0/24 action=mark-routing new-routing-mark=terminal1
/ip firewall mangle add chain=prerouting in-interface=ether2 dst-address=192.168.3.0/24 action=mark-routing new-routing-mark=terminal2

# dst-nat for terminal2
/ip firewall nat add chain=dstnat in-interface=ether2 dst-address=192.168.3.0/24 action=netmap to-addresses=192.168.1.0/24

# src-nat for both terminals
/ip firewall nat add chain=srcnat out-interface=ether3 dst-address=192.168.1.0/24 action=src-nat to-addresses=192.168.1.1
/ip firewall nat add chain=srcnat out-interface=ether3 dst-address=192.168.2.0/24 action=src-nat to-addresses=192.168.2.1
/ip firewall nat add chain=srcnat out-interface=ether5 dst-address=192.168.1.0/24 action=src-nat to-addresses=192.168.1.1

EDIT: Corrections.
"address.pool" -> "address-pool"
"routing-mark=terminal1" -> "routing-mark=terminal2" in the routing rule for table=terminal2

9

Thanks @lurker888 for your patience, I'm doing my best but, as I've already mentioned, that's not exactly my field. I've quite understood the settings with the only exception of the meaning of the dummy bridge and why the DHCP always gives the pc a ...0.200 IP (no matter if the range is 100-200 or 2-255), but that's not really important...

I've tried your settings, I've only had an issue in dhcp-server cmd with "address.pool=" line (maybe "address-pool="?) but I used the WinBox GUI to work around the problem. Below this post the actual configuration.

Things are starting to work but I'm strangely going back in time to issues that I was already experiencing in my first post where:

  1. I can ping terminal2:ether5 from PC:ether2 but I can't ping PC from terminal2 (I have no issues when using terminal1:ether3)
  2. When only terminal1 is connected it seems PC can ping also a terminal2 (ghost), e.g. I got responses from both pinging 192.168.1.11 and 192.168.3.11 .

I'm wondering if simulating Terminals with a Win11 PC, as I am currently doing, may introduce some additional chaos into these tests.

Thanks in advance

/interface bridge
add name=dummy protocol-mode=none
/ip pool
add name=pc-dhcp-pool ranges=192.168.0.100-192.168.0.200
/ip dhcp-server
add address-pool=pc-dhcp-pool interface=ether2 name=pc-dhcp
/routing table
add fib name=terminal1
add fib name=terminal2
/ip neighbor discovery-settings
set discover-interface-list=!dynamic
/ip address
add address=192.168.0.1/24 interface=ether2 network=192.168.0.0
add address=192.168.1.1/24 interface=ether3 network=192.168.1.0
add address=192.168.2.1/24 interface=ether3 network=192.168.2.0
add address=192.168.1.1/24 interface=ether5 network=192.168.1.0
/ip dhcp-server network
add address=192.168.0.0/24 comment="LAN Network" dns-none=yes gateway=192.168.0.1
/ip firewall mangle
add action=mark-routing chain=prerouting dst-address=192.168.1.0/24 in-interface=ether2 new-routing-mark=terminal1
add action=mark-routing chain=prerouting dst-address=192.168.2.0/24 in-interface=ether2 new-routing-mark=terminal1
add action=mark-routing chain=prerouting dst-address=192.168.3.0/24 in-interface=ether2 new-routing-mark=terminal2
/ip firewall nat
add action=netmap chain=dstnat dst-address=192.168.3.0/24 in-interface=ether2 to-addresses=192.168.1.0/24
add action=src-nat chain=srcnat dst-address=192.168.1.0/24 out-interface=ether3 to-addresses=192.168.1.1
add action=src-nat chain=srcnat dst-address=192.168.2.0/24 out-interface=ether3 to-addresses=192.168.2.1
add action=src-nat chain=srcnat dst-address=192.168.1.0/24 out-interface=ether5 to-addresses=192.168.1.1
/ip route
add dst-address=192.168.1.0/24 gateway=ether3 routing-table=terminal1
add dst-address=192.168.2.0/24 gateway=ether3 routing-table=terminal1
add dst-address=192.168.1.0/24 gateway=ether5 routing-table=terminal2
add distance=100 dst-address=0.0.0.0/0 gateway=dummy
/routing rule
add action=lookup-only-in-table routing-mark=terminal1 table=terminal1
add action=lookup-only-in-table routing-mark=terminal1 table=terminal2
10

Never mind...spotted the bug here!

Obviously a typo "routing-mark=terminal2" and now I got no "ghost" responses pinging 3.11 when terminal 1 is connected.

I'm working on the very last flaw of the perfection: the missing answer of the PC when the REF is pinging. I'll keep you updated, thanks again.

11

Only for the record, the Windows (10/11) Firewall is known to block in some cases PING, so it should be checked.

12

For some reason, Mikrotik's DHCP implementation start from the top (which it's free to do.) The router keeps track of which address was assigned to which MAC, so receiving the same address is not unexpected. Also, the PC (depending on operating system) remembers which address it got last, and requests it, which routers tend to honor (contingent on it not being assigned to someone else.) None of these mechanisms are in any way guaranteed.

Yep. I've corrected both in post, should someone come upon this thread later.

Yes. The address translation, as specified, is one-way, i.e. only for connection initiated in the PC->terminal2 direction. The reverse is simply not implemented. (Tis doesn't affect teminal1, because we don't translate addresses in that scenario.) In these sorts of arrangements, this is not usually requested.

In fact, the usual request is for a firewall to be added, that specifically forbids connections initiated by the terminal1/2 networks to the PC or to each other.

Again, the appropriate rules for this can be added, but if it's not needed, it's better to simply document this characteristic.

As @jaclaz mentioned, by default Windows blocks pings from outside its own subnet. The PC you're testing with probably has its firewall disabled/modified to allow this. Just keep this in mind.

In case you want terminal2->PC pings, this is the additional rule to add:

# Because of the in-interface matcher, this only works on more recent RouterOS versions.
/ip firewall nat add action=src-nat chain=netmap dst-address=192.168.1.0/24 in-interface=ether5 to-addresses=192.168.3.0/24