We have a private cellular network in our factory and i am needing to be able to NAT out multiple LAN devices to the private network. Right now, I can only do one as the NAT function only allows me to use the interface IP of the cellular connection. Is there a way to add functionality to the Cellular Connection (like the WAN) to add multiple additional IPs to the connection?
1 Like
There is no way yet, but as a platinum peplink partner I’d like to work with you on this project and get it in front of the right engineers at peplink.
Please send me an e-mail to [email protected] and we can work together on this.
1 Like
Hi,
Would it be good for you if you can add a second APN?
That might be something for this application to have different IP adresses for you to send via the Outbound policies traffic over different IP addresses.
No, we’re not able to add a second APN
Adding a little more detail on why this feature is needed. The solution setup is this:
application#1 on a private IP network (net#1) → (cellular) br1 pro 5g (lan) → switch → various PLCs
application#1 must communicate with the various PLCs on a set TCP port 44818. This limitation can’t be changed. With single PLCs this problem can be handled with either IP Passthrough or port forwarding. However with a more than a single PLC and the limitation of TCP port 44818 unchangable neither of the above will work.
- have you got a full network diagram you can share?
- What does application #1 run on - another PLC or a PC?
- what’s the security realm of the LAN of the BR1 compared to the private IP network? Are they owned by the same customer? Do you need firewalls between them?
I would liekly recommend getting rid of the cellular NAT if you can and if not then consider a VPN from the private IP network to the cellular WAN interface. Assuming LANs are in different ranges of course.
Application #1 is a PLC or an HMI or an IO Block that runs using ethernet/ip. The devices on application #1 talk to each other on a local network on an AGV. If i wanted to route out multiple devices on the AGV to the private cellular network, I am unable to do so through the cellular WAN as the NAT feature only allows me to use the interfaceIP.
The cellular network is internal to our factory only and doesn’t reach out to the internet. We can’t use a VPN on the local network
Ok I think I understand.
My first suggestion then is to remove NAT from the peplink cellular WAN on the AGV. Then add a default route to it on the Plant network perimeter for the onboard network (192.168.1.0/24) with the cellular IP as the destination.
But. If you have one AGV, then you likey have many. And I suspect all of your AGVs have the same LAN subnet set (ie 192.168.1.0).
If that’s the case, then my 2nd approach would be to use a Peplink on the plant network and build PepVPN tunnels to each AGV over the private cellular link. Then you can use virtual network mapping to give each AGV their own unique IP range that you can target from the plant network.
The added benefit is that your AGVs can then use Private Cellular / Public Cellular / Wifi and even Starlink and bond all of those connections together if you wanted for reliability. (assuming your Plant network has a public internet connection you could use).
We’re not able to use the Peplink to build PepVPN tunnels due to IT restrictions. Cellular network traffic has to stay on site and can’t be exposed to outside internet traffic.
You don’t have to use public internet.
Pepvpn traffic woukd stay on site if just using local cellular. and would enable the use of virtual networks which solves your NAT issues.
Unfortunately, that’s not a solution we’d be able to try due to IT restrictions.
OK. Then you are left with local LAN Virtual Network mapping.
- Set a virtual network on the LAN of each AGV Router (eg 172.16.x.0/24) map it to the PLC / IO LAN.
- Use IP forwarding on the AGV Routers
- Then either use static routes or preferably a routing protocol like OSPF on the Plant Network so devices there learn the virtual Networks.
Then your PLC (and other devices) on the Plant network can access each PLC & IO device using unique IPs, but the actual assigned IPs on those devices on the AGVs are all in the same subnet.
It would look like this:
- Both AG’s have a PLC and IO device that are set with replica IP addressing - this makes maintenance of and code on the AGV easier to standardise.
- To make all AGV PLCs and IO accessible from the Plant network we need unique IP addressing for each device so we use virtual network mapping on the BR1 to map new unique subnets for each AGV.
- Those unique subnets are accessible over the private cellular connection as the BR1 has its cellular WAN set to IP forwarding rather than NAT. The Peplink Firewall is then configured to only allow traffic destined for specific ports in.
- The PLC / devices in the Plant network then need to know where to send traffic for the new virtual networks. We can use OSPF from the Peplinks to advertise the virtual networks to the Plant network, or we set static routes up on the Plant network core router/firewall.
- The Plant network PLC can then access the PLC on AGV 1 using 172.16.1.10, and the PLC on AGV 2 using 172.16.2.1.10.
Can you share how this would look in the Peplink? I don’t understand how the Virtual Mapping completely works.
This:
Maps a virtual network of 172.16.1.0 to the local LAN of 192.168.1.0
So any local IP is then accessible on the new virtual network. eg:
192.168.1.10 < - > 172.16.1.10
192.168.1.20 < - > 172.16.1.20
192.168.1.111 < - > 172.16.1.111
1 Like
Okay, I have the virtual mapping set up. How would the OSPF work from your step below?
• The PLC / devices in the Plant network then need to know where to send traffic for the new virtual networks. We can use OSPF from the Peplinks to advertise the virtual networks to the Plant network,
Good work.
So now devices in the plant network need to know how to get to the virtual network(s) using the Cellular WAN IP of the Peplink as the next hop.
You can either add static routes to each device that needs access (if you had 100 AGVs you’d need 100 static routes which is a bad idea), or if you have a router on the plant network that supports it, you can use OSPF on each peplink to advertise which virtual networks each Peplink device is responsible for to the plant network router. Then any device on the plant network that has that router as their default gateway will be able to route to each virtual network.