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 Make it look like, and this other one plugged into port 3, that also thinks it's - make that one look like" .. 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.

  • +1 Great question! Unfortunately, I have no clue how to answer it.
    – Bigbio2002
    May 15 '12 at 17:45
  • out of curiosity, are these physical or virtual devices?
    – smcg
    May 15 '12 at 17:52
  • @smcg - physical
    – JustJeff
    May 15 '12 at 22:17
  • There is generally a way to change the IP address of the device. Sometimes it involves connecting a serial port to it and issuing the correct commands.
    – psusi
    May 17 '12 at 0:44
  • @psusi - true enough, but sometimes what is possible is simply not allowed
    – JustJeff
    May 18 '12 at 2:49

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

3 Airco units with LAN monitoring that each insisted on being and expect the default gateway to be and the subnet 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 on the LAN side and do port-forwarding for HTTP to the 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.)

  • this would do the trick, just hoping for something more compact
    – JustJeff
    May 15 '12 at 23:07
  • You could accomplish this with a single NAT device using a higher-end router that supported vrf. Configuring that is left as an exercise for the reader.
    – MikeyB
    May 17 '12 at 0:41
  • @MikeyB I know that. (I'm a CCNP myself.) But that sort of stuff is not exactly common and certainly expensive. I have never come across one in the wild, except in Cisco training. I like your statement about configuration. I can do it, but I'm very certain that I would be the only one in the company that understood it and could troubleshoot. My quick and dirty solution is understood by all 3 of my colleagues so I can take a holiday without taking the cell-phone and the laptop along. That's worth a lot to me!
    – Tonny
    May 17 '12 at 20:58
  • @Tonny: Agreed, it's certainly a step up in expertise. Just noting that it can be done. Of course, if you can afford a VRF router and someone that can configure it, you probably can afford decent monitoring devices on which you can change the IP!
    – MikeyB
    May 18 '12 at 14:56

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.

  • static NAT per port - exactly what I want, but is this a rare or common thing? Re the auxiliary linux box - couldn't that become something of a bottleneck?
    – JustJeff
    May 15 '12 at 22:54
  • Depends on what speed you need.. We are running lots of ssh tunnels on one NIC routed through linux and that works fine for ssh etc. They are not using much bandwidth when "idle". Also to put it into perspective we are running a 200+ device network through a single linux FW, the bottleneck is the internet bandwidth.
    – EivinGS
    May 16 '12 at 1:16

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.


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, gateway, mask (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 eth0.20 ip address

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 dev eth0.10
ip addr add dev eth0.20

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

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

# Verify your routes in the tables!
ip -br route show table 1 dev eth0.10 scope link dev eth0.10 proto kernel scope link src
ip -br route show table 2 dev eth0.20 scope link dev eth0.20 proto kernel scope link src

Now comes the real fun, ip tables!

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

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

Command given: telnet

Wireshark output: ARP: Who has Tell

And again: telnet

Wireshark output: ARP: Who has Tell

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.