FireSight OT · duplicate IP addresses
Remote access with duplicate IP addresses, using 1:1 NAT
When every production line uses 192.168.1.x, a normal VPN can't tell one line from another. FireSight OT gives remote access with duplicate and overlapping IP addresses by mapping each site's network 1:1 to its own range on the Cloud Hub. The machines keep their addresses, and nobody renumbers anything.
The problem
Why overlapping IP addresses break remote access
Machine builders ship identical lines, with the same default addresses in every one. Plant after plant ends up with 192.168.1.0/24 on the machine network.
- A router can only have one way to 192.168.1.20. With two sites on the same subnet, a site-to-site VPN can't reach both.
- Renumbering is rarely an option. Addresses are in PLC projects, HMI configurations and the machine builder's documentation. Changing them means downtime and risk.
- Per-site workarounds don't scale. A separate VPN profile per line, or a remote-desktop PC at each site, gets harder to manage and to secure with every line you add.
1:1 NAT
How 1:1 mapping gives each duplicate network its own address
You choose a pool of addresses on the Hub. Each Cloud Connector's machine network gets its own range from that pool, the same size as the real network. The last part of each address stays the same, so the mapping is easy to read.
| Machine | Real address at the site | Address on the Hub |
|---|---|---|
| Press PLC, site A | 192.168.1.20 | 10.200.3.20 |
| Press PLC, site B | 192.168.1.20 | 10.200.4.20 |
| Line HMI, site A | 192.168.1.50 | 10.200.3.50 |
| Line HMI, site B | 192.168.1.50 | 10.200.4.50 |
Use either address
People and published machines can use the real address or the Hub address. The Cloud Connector a resource belongs to decides which site it reaches.
Tools see a local port
With the FireSight OT client, engineering tools connect to a local port on the laptop, so they never need to know which site's 192.168.1.20 they are talking to.
The VPN uses the same mapping
The optional full-network VPN reaches each site by its Hub range, still limited to the networks granted to that person.
Masquerade
No routes or gateways to change on the machines
By default the Cloud Connector masquerades: the PLC or HMI sees every remote connection coming from the Cloud Connector's own address on the machine network. It answers that address, which is on its own subnet, so it needs no route back to the Hub or to the engineer.
- No default gateway to set on PLCs that never had one.
- No static routes on HMIs or drives.
- No changes to the machine builder's configuration, so their documentation and support stay valid.
- The Cloud Connector just needs one free address on the machine network.
Site control
The site still decides what can be reached
Mapping a whole subnet doesn't open a whole subnet. Access is still granted per machine, and the site has its own cap.
- A site-side allowlist. Each Cloud Connector can carry its own list, set at the site, of the most the Hub may ever reach. The Hub can't widen it.
- Grants per machine. Nobody sees a machine until it's granted to them, their division or their vendor account.
- Outbound only. The Cloud Connector dials out to the Hub, so the site needs no inbound firewall rule.
- Audited by name. Each session records the person, the machine and the site, so two identical PLCs are never confused in the log.
One line or many
Duplicate IP addresses at one site
The same problem can happen inside one plant, when several identical lines sit side by side.
One Cloud Connector per machine network
Give each identical line its own Cloud Connector. Each gets its own range on the Hub, exactly as if the lines were in different plants. Licensing is per Cloud Connector.
Many VLANs on one Cloud Connector
VLAN support on the machine port is planned: one Cloud Connector serving several machine VLANs through a trunk port, each with its own 1:1 mapping.
Shipping identical machines? This is what makes remote support for machine builders work across an installed base with the same addresses everywhere. To reach the PLCs themselves, see secure PLC remote access.
Comparing products? Question 2 in our eleven questions for OT remote access is about exactly this. Talk to us about your lines.
FAQ
Questions people ask
Does FireSight OT work with duplicate IP addresses at different sites?
Yes. Each site's machine network is mapped 1:1 to its own range on the Cloud Hub, so 192.168.1.20 at site A and 192.168.1.20 at site B become two different addresses, such as 10.200.3.20 and 10.200.4.20.
Do I need to change the IP addresses or routes on my PLCs?
No. The machines keep their addresses, and by default the Cloud Connector masquerades so machines see connections from its own address and need no route back.
What is 1:1 NAT?
1:1 NAT translates each address in one network to a matching address in another, keeping the last part the same. FireSight OT uses it to give every duplicate machine network a unique range on the Hub.
Can one Cloud Connector serve several identical lines at the same site?
Today each machine network has its own Cloud Connector. VLAN support, with one Cloud Connector serving several machine VLANs each with its own 1:1 mapping, is planned for 0.4.0.
See it on a test line
Tell us about your sites and who needs to reach them. We'll show you FireSight OT in a live demo Hub, with real machines behind a Cloud Connector.
