I have an interesting problem and need some assistance to first find out if it is possible with the hardware I have and secondly to be pointed in the right direction for a solution.
I have 5 devices with the following IPs (4 devices with the same IP and one controller device) see the attached image. They are all connected to a RB750r2 (Hex Lite):
192.168.0.201 - connected to ether1
192.168.10.170 - connected to ether2
192.168.10.170 - connected to ether3
192.168.10.170 - connected to ether4
192.168.10.170 - connected to ether5
I want the device connected to ether1 (192.168.0.201) to be able to communicate with the device on ether2 (192.168.10.170). However, the kicker is that the ether1 device should see the packets coming from 192.168.0.170 and the device on ether2 from 192.168.10.201, respectively.
This should repeat for ether3,4 and 5 with the device on ether1 seeing it as devices 192.168.0.171,172,173 respectively and each device on ether3,4 and 5 seeing the communication from 192.168.10.201.
Devices on ether2,3,4, and 5 should not be able to communicate with each other (Don’t think they can as that will result in IP address conflicts).
I have tried a setup with dst-Nat and source nat, however, this did not work at all as there was no communication between the devices.
Is dst-nat, or src-nat the way to go to allow this type of setup? Is it even possible with my hardware? is there other stuff I should try?
Since you have not written anywhere the reason why the peripherals have that ridiculous configuration,
and since it is obvious that they must not have the same address, otherwise they create problems…
The solution is simple: use different IPs on each device, as is right and logical that it should be…
Maybe one could start with the assumption that a request for help/assistance from a new member might (even if it is a remote possibility) be not completely crazy and I am pretty sure that it is perfectly possible to ask for the context/reasons/etc. without implying that the new member is crazy, ignorant or both.
Have a look at the topics linked above, they might represent (it depends if you are running Ros6 or 7) a possible solution, or at least give you some ideas to experiment with..
We need a more granular understanding of the relationship between the controller and devices.
A. Who initiates traffic.
→ does the controller reach out first and state any devices here
—> do the devices reach out first, is there any controller out there.
B. How does the controller know which device its talking to since all hardware devices are given the same IP address?
Is there a specific port or perhaps mac address assigned to each device the controller is aware of, or discovers in the broadcast and answer kind off process??
I do agree that the setup is crazy and something that is not the norm at all.
The reason for the 4 devices connected to ether2,3,4 and 5 is that one set of firmware is loaded on the devices, hence one hardcoded IP address. Unfortunately, the conditions where these devices are used, make it extremely difficult to keep track of which device is where in the system physically and you could end up having multiple of the same IP devices connected by accident not to mention the fact that the reprogramming of the devices is not an easy task for the type of installation.
It is therefore decided to at least try this solution (hence my asking if it is possible) where you do not have to worry about the IP programmed on the device and that some other device ( hopefully the RB750r2) can handle the separation.
The “controller” will communicate primarily via UDP to the devices and they will reply. However, there will be occasional TCP connections as well from the controller or other devices connected to the ether1 port (via other unmanaged switches).
The controller expects devices on IP 170, 171, 172 and 173, that is the reason why those IPs are assigned. The idea is that the operator will plug the first field device into ether2 port as that is dedicated to the first device which translates (eventually) to 192.168.0.170. Device 2 will connect to its dedicated port ether3 which will eventually translate to 192.168.0.171 as seen by the controller.
I hope this gives a bit clearer context of why these assignments are made. And I do appreciate your comments and help thus far.
@jaclaz, thank you I will view those topics and see if I can find something. Thanks @abbio90, will look into 4VRF.
I have tried the following (with only two devices) and it does not work. The controller that tries to talk to 192.168.0.170 reaches the interface (on the router) through ping, but the udp packets from the software running on it do not reach the device on ether2. and there is no reply from the device back to the controller.
Without considering the various problems of ARP and IPs being the same on different ports, where they not only have to pass through, but also do NAT,
the simplest solution is to buy 4 least expensive router ever and do all local NAT.
When you use NAT or Routing, you are already at Leve 3,
but at Level 2 192.168.10.170 cause confusion on ARP table, and the position of expected 192.168.10.170 change continuosly…
Thank you @rextended. If I am able to somehow set them up as dynamic IPs and get their IP from the router, will that make things easier?
I will still have to have device 1 on ether 2 which ultimately translates to the static IP 192.168.0.170 at the controller side, and 171, 172,173 for devices on ether3,4,5 respectively.
Unfortunately, I get the same results as with dst-nat. As with dst-nat, I can see the connection coming from the controller, it just doesn’t get routed through and out by ether2/3.
I would define “rare” the case that something Sob suggests is not working.
Post your full configuration, maybe there is something else that needs to be corrected or some “wrong” other setting that some of forum members may be able to spot..
Netmap (from what I understand) should be “protocol agnostic” (i.e. TCP or UDP should be treated the same).
Well, it did do something by inverting the chain and action. I now at least get a packet on the ether2 interface. Unfortunately, there is no other communication.
I don’t know, as said I believe (but I may well be wrong) that netmap maps “everything”, but maybe there is the need to specify protocols and/or ports.
But then it could be that for some reasons your tool/program/whatever does not expect this kind of netmapping from/to IP addresses.
I am not sure how exactly it will work, if this is the case, using (in v7) the vrf approach, essentially the approach is the same, from what I understand, using vrf should be only the v7 version of routing-marks, but maybe there is some slight difference that makes it work, cannot say.
Ok, I did a few tests in GNS3, and the vrf approach seems to be working (at least I can ping both with ICMP and UDP from PC to the two targets).
Setup:
VPCS named PC-source set with ip 192.168.0.254/24 connected to ether1 of a Mikrotik CHR (runnning 7.15.3)
VPCS named target1 set with ip 192.168.10.2/24 connected to ether2 of the CHR
VPCS named target2 set with ip 192.168.10.2/24 connected to ether3 of the CHR
To ping target1, ping 192.168.0.170
To ping target2, ping 192.168.0.171
chain is dstnat action is netmap.
