I have two devices with the same ip address (192.168.125.1) which cannot be changed because the maunfacturer wont permit it. The are both connected directly to the OpenWRT router (eth0.1 and eth0.2).
I would like to have both robot connected to the same network.
The switch has been setup with 2 vlans and I've setup two interfaces LAN & LAN2. Connecting to the WIFI I can communicate with the robot 1. I'd like to effectively change the IP address of robot 2 to 192.168.125.2 and map it into LAN with the other robot. DNAT & SNAT? Any advice or suggestions would be appreciated.
Look at getting the firewall/nat to rewrite the IP address based on source. You'll have to use NAT to make sure that the packets go back to the right machine. Anyway aim on the openwrt that after prerouting each machine has its own unique address.
You'll need to use snat, basically do a match on the interface name, and any packet from that interface, rewrite the source address to something you can use using snat.
If you need to connect to the robots (as well as the robots connect to the wan) then you'll also need dnat.
So lets give some more (generic) directions (generic as I use nftables these days, but have done what you want in the past using iptables).
In prerouting, if input interface equals ETH0.1/2 then SNAT that ip to something unique.
On openwrt route those unique ip address to ETH0.1/2 respectivly.
In post routing, if the output interface is ETH0.1/2 then DNAT the destination address to 192.168.125.1
ok so i can achieve my objective, just got to work out how. Given the choice i'd do it via LuCI but it look like I'm going to have to do it by editing the config files.
I know when I did something like this in iptables - I just wrote the iptable commands in a file. I looked at doing it in luci - but that actually made it more complex, mainly beacuase I needed a totally closed down system, and coudn't veryify that in luci ...
I simplified the network diagram above, openWRT actually uses the wifi as a wan connection for internet access and I'm connecting to it and the first robot using a openvpn. So I need to be careful making changes or I'll have a 70 mile round trip to fix the broken connection! Hence asking for some guidance before I commit and changes.
Think the only problems you would have is that snat is usually done in postrouting, and dnat in prerouting. But in your case openwrt needs to know how to route. I wonder if you are alowed to swap roles? Not sure if iptables allows this.
Doing snat in postrouting I guess would still work, as you stall have access to the input interface. Routing would be hard, on getting a reply address gets changed back to 192.168.125.1, and that can't be routed - so that is the problem.
So yes some potential problems if done remotely ...
Problem with those rules is that they don't specify interface. The only method you gave of distrinquishing which machine 192.168.125.1 comes from is the interface, so the snat will need to be done on interface. I know how to do this with nftables, so probably can do the same with iptables - but been so long since I last used iptables, I don't recall how ....
Problem is when the robot sends a packet, now assuming the snat rewrites the address correctly, the packet will still be delivered to the right IP.
problem though is any reply, that is received by openwrt and the snat will rewrite the address to 192.168.125.1. problem this is how to route that packet.
What we need is that the NAT also specifies the routing interface. Now this isn't what NAT does - it just rewrites the IP address, its not a routing activity - so I don't think can specify the forwarding interface.
So not sure this will work. Really need to rewrite the packet after the outgoing interface is specified ...
Forgetting about the vpn thing (they shut the machine down now, I'll be on site on monday so I'll try locally) . I think this will effectively change the ip address of traffic comming from robot 2 to 192.168.125.2
Well its a bit more complex. dnat is when the laptop tries to contact the robot. But there is already the problem with snat, that already fails on any reply.
Think always need to think of routing as well as NAT, and that will be the difficulty here, how to route packets. Think the fundamental problem is we can only route packets on IP address, and so this says that the IP of the robots needs to be different on the openwrt device, when any routing is done.
I've done something like this in the past with multiple machines with the ip address of 192.168.1.2 mapping the into a factory network. That was done by giving each machine its own router to connect to the factory network. I guess this cant be done with a single router.
Thanks for your help summers, it been useful to disuss this stuff with you and if nothing else I've learn a few things
Yes - buts whats a pity is conceptually its easy to solve, any incoming packet from ETH0.1/2 rewrite its from address as 192.168.1.(1/2); any outgoing packet on ETH0.1/2 rewrite its to address as 192.168.125.1. The difficulty is this isn't really a NAT process, or I can't see how to get NAT to do it without making both snat and dnat run on the ETH0.1/2 side of routing.
Maybe look at mangling to do this - it may have the felxability needed...
They have an option that allow you to set your own ip addresses for connecting to a factory network which they charge an unreasonable amount for the software key.
I'm doing this for the fun of it and so i can program the 'bots from home/desk rather than the factory floor.
The problem is that two devices have the same IP number, it isn't a subnet problem as you can set the domain of the subnet very small, e.g. on my arm network on my NAS:
ip route
default via 192.168.2.1 dev eth0 proto dhcp src 192.168.2.111 metric 1024
192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.111
192.168.2.1 dev eth0 proto dhcp scope link src 192.168.2.111 metric 1024
192.168.7.0/30 dev usb0 proto kernel scope link src 192.168.7.1
192.168.7.16/30 dev usb1 proto kernel scope link src 192.168.7.17
Notice all the /30 - at most 4 machines on that, but actually just two - due to broadcast address etc.
But with two machines on the same address, you can't separate them ...
@Robotics, The problem here is suppose a packet comes in from the WAN and the openwrt figures out that it is part of a conversation that initially came from 192.168.125.1, where does it send the packet? It can't because there are two destinations that are only distinguishable by their MAC address which the NAT tables don't know anything about as they operate at layer 3.
Solution: buy some cheap gl-inet devices and insert them between your existing router and each robot... have the gl-inet device do NAT for each robot, so that packets coming from robot 1 hit our cheap nat device and then get rewritten to come from 192.168.125.5 (or whatever) and from robot 2 to come from 192.168.125.6 (or whatever). Now the openwrt router sees packets from two separate destinations and can route them back to the right place.
Also I spit on your rent seeking mfg. Tired of that kind of crap in technology industries.
Edit2: If you are really keen to keep this on one device, you can recompile OpenWrt with network namespace support, and then throw each VLAN interface into its own namespace and do NAT from there... basically virtual gl-inet devices ;-)... The main router namespace will see packets coming from two different sources, sending return packets to veth devices that lead (at the other end) into each namespace one per robot, where NAT will occur.
Apparently I didn't read the post above... Something about great minds think alike
I got it!
Put another Openwrt device in front of the robots with an IP Address of your choice (And that matches your internal subnet addresses. Then use IPTables and nat to forward whatever ports you need to send to and from the robot.
Each robot could have it's own edgerouter X or something to do the NAT which could be given a static address or use DHCP from the factory LAN.
All the robots would think they were on the 125.1 IP address while the Edgerouter would be handling the internal networking.
