What's the best way to accomodate multiple devices that all want to use the same fixed IP address into the same LAN?

Question

Suppose I have an ethernet capable device that has a hard coded IP address in it. I have software that works with the device, which could be configured to work with practically any IP address for the device, but as stated, the device always comes the same fixed address.

Now here's the problem: suppose I want to use more than one of these devices in my network. An example of two suffices to illustrate the problem. Obviously there's an immediate IP conflict. I could run two instances of the software, but there's no way to disambiguate which instance of the software should associate to which device.

I think what might work is to use a layer 3 capable device to essentially do network address translation, but I don't need to NAT an entire LAN, like most commodity routers seem designed to do. What I'd really like to do is apply static NAT on a per-port basis. I'd like to tell the router(?), "you see this device plugged into port 2, that thinks it's 10.1.1.1? Make it look like 192.168.1.2, and this other one plugged into port 3, that also thinks it's 10.1.1.1 - make that one look like 192.168.1.3" .. and so on. (assuming of course that the rest of my LAN is 192.168.1/24)

I've worked with a 'switch' that does VLANs and routing domains, but didn't appear to have the capability to translate addresses between the VLANs. Space and cost constraints preclude dedicating an entire NAT-capable router to each device.

So is this kind of thing possible? If so, what kind of device does one need to get it? Heck, maybe the switch I'm working with can do it, I just don't know exactly what to look for and didn't recognize it! But if it's simply not done, I'd alternately like to know why not, to figure out where the flaw in my thinking would be. Doesn't seem impossible, though.

Answer 1

It can be done. Actually I have done it myself last year.

3 Airco units with LAN monitoring that each insisted on being 10.0.0.2 and expect the default gateway to be 10.0.0.1 and the subnet 255.0.0.0. It can be changed, but only by the manufacturer who is no longer in business.

Buying new ones was not an option: Industrial units about $100.000 a piece.

Worst thing: Communication had to be 2-way: Remote access to the web-interface in the device and it needed to be able to send out syslog messages on it's own.

The trick is that you need multiple NAT-ting routers to make this work. A single router simply can't deal with to downstream LAN's having the same ip-subnet. (At least not any equipment I have ever seen...)

What I did was buy 3 cheap of the shelf routers (D-Link DIR-615). Put each of the units behind it's own router. Setup each router to be 10.0.0.1 on the LAN side and do port-forwarding for HTTP to the 10.0.0.2 address. WAN side of each router went on the regular LAN where each got it's own normal ip-address.

To connect to a unit I simply point a web-browser to the WAN-ip of it's router and port-forwarding does the rest. Syslog messages (outgoing) of the devices get NATted and appear to come from the 3 routers.

Only drawback is that to re-configure the D-Links I need to connect a PC to the LAN-side of each so I can get at the web-based management interface of the router. (The D-link can actually run it management interface on the WAN side but as far as I could tell only on port 80 which would have interfered with the port-fowarding.)

Answer 2

Since the devices will all have the same real IP you would need to do some kind of masking or static NAT.

One solution would be to put every device (switchport) on a separate VLAN and route between the networks. The switch would need to be able to do static nat on a per port basis.

Another solution might be to make a linux machine on one port member of all VLANs and utilize virtual IPs and do the routing/nat part in linux. Iptables can do NAT.

Answer 3

If the fixed IP address does not overlap with a valid host on your segment, I would simple plug them in and setup fake addresses for them on the host running the management software. Simply add a static arp entry to the mac address of the particular devices and now you can have them both on the segment "using" different addresses.

I would consider this a hack, but since you hinted to other reasons why you couldn't address the problem directly this might fit.

Answer 4

I believe there is a much simpler solution the the ones proposed here.

Requirements: your devices, 1 switch (capable of VLAN trunk & access, I assume cisco for simplicity), 1 linux PC. I assume that the IP address from where these devices are reached does not matter (if it does, this becomes even more "fun").

I assume the target devices all run on static 10.0.0.2, gateway 10.0.0.1, mask 255.255.255.0 (see another answer here).

On the the switch connect port 1 to the first device:

interface Gi0/1
  switchport mode access
  switchport access vlan 10

On the the switch connect port 2 to the second device:

interface Gi0/2
  switchport mode access
  switchport access vlan 20

On the the switch connect port 3 to the PC which will control:

interface Gi0/2
  switchport mode trunk
  switchport trunk allowed vlan 10,20

Now we have a link layer separation already, sadly enough this doesn't stop here.

On your linux PC, set up 2 virtual interfaces. Exact commands to do this are included further below.

eth0.10 ip address 10.0.10.1 255.255.255.0 eth0.20 ip address 10.0.20.1 255.255.255.0

And now comes the fun, like a lot of fun. Virtual NICs, VRF, iptables, and lots of routes!

# First create 2 vrf for both devices
ip link add device1 type vrf table 1
ip link add device2 type vrf table 2
ip link set dev vrfdevice1 up
ip link set dev vrfdevice2 up

# Second, create vlan device
ip link add link eth0 name eth0.10 type vlan id 10
ip link add link eth0 name eth0.20 type vlan id 20

# Add the vlan to the correct vrf
ip link set eth0.10 master vrfdevice1
ip link set eth0.20 master vrfdevice2

# Assign them proper IP address (unique)
ip addr add 10.0.10.1/24 dev eth0.10
ip addr add 10.0.20.1/24 dev eth0.20

# Add the route in the **normal** route table to these devices (so normal kernel can work with it)
ip route add 10.0.10.0/24 dev eth0.10
ip route add 10.0.20.0/24 dev eth0.20

# Add the route to the targets on both VRF
ip route add 10.0.0.0/24 dev eth0.10 table 1
ip route add 10.0.0.0/24 dev eth0.20 table 2

# Verify your routes in the tables!
ip -br route show table 1
  10.0.0.0/24 dev eth0.10 scope link
  10.0.10.0/24 dev eth0.10 proto kernel scope link src 10.0.10.1
ip -br route show table 2
  10.0.0.0/24 dev eth0.20 scope link
  10.0.20.0/24 dev eth0.20 proto kernel scope link src 10.0.20.1

Now comes the real fun, ip tables!

iptables -t nat -A OUTPUT --destination 10.0.10.2 -j DNAT --to-destination 10.0.0.2 --out-interface vrfdevice1
iptables -t nat -A OUTPUT --destination 10.0.20.2 -j DNAT --to-destination 10.0.0.2 --out-interface vrfdevice2

And that's it! I think. I have verified this with wireshark that it works...

Command given: telnet 10.0.10.2

Wireshark output: ARP: Who has 10.0.0.2? Tell 10.0.10.1

And again: telnet 10.0.20.2

Wireshark output: ARP: Who has 10.0.0.2? Tell 10.0.20.2

This has been a rather massive endeavor, if any of this helped you, please let me know and upvote the answer. We don't actually need many expensive routers, VRF can fix most of this, especially in combination with virtual interfaces! The fun is that this can now all run within Linux, cool stuff