PFSense On 4G To Remotely Access PLC (Programmable Logic Controller)



  • So I've toyed around with the idea of adding a PFSense appliance to my home network but it looks like my first experience with PFSense is going to be work related. I'm hoping someone can confirm what I'm thinking is possible and not a bad idea before buying hardware, then I can hopefully get it figured out myself for the most part, I've got a few networking classes under my belt but networking/IT is not my specialty.

    I work for an engineering company that mainly does factory automation with Allen Bradley PLCs. For some of our smaller projects/clients we run into scenarios where they do not have onsite support to solve a problem themselves but they also don't have the budget to have us fly someone out to solve a minor issue. Currently the solution that we are working with this morning is to have the client plug in a laptop, install team viewer, then we remotely install all of our PLC programming software and then correct the problem. The biggest issue is that installing this software can take 12+ hours depending on connection speed and the specs of the laptop they provide. Not to mention that we have to tie up software licenses that can be several thousand dollars, and in general doesn't have a professional feel.

    The solution that we have discussed, and that I've said sounds feasible, is to create a "black box" that we can overnight to the client and they can plug into their PLC hardware and allow us to connect remotely with software installed on our local machines. WAN will primarily be via cellular hotspot so that we have no need to connect to their internal network. Should cellular reception be low we may revert to wireless assuming they have a guest network with a internet access, which adds another problem with programming Wifi settings and hoping they work when the box gets on site.

    Upfront this sounds as simple as an SG-1100 and one of the 3G/4G modems off of the docs list. Configure USB WAN, Dynamic DNS, OpenVPN server, configure authentication, limit access to office IP, possibly bridge VPN to LAN?, use the Client Export Package to transfer settings to windows referencing the DynDNS redirect.

    When the hardware gets plugged in on site I would need to connect to VPN and change the LAN interface to match the IP of the PLC (No DHCP). Then I should be able to connect as if the device is on my LAN correct? There was a blurb in the docs about client bridging but it looks like it's a dead end. I can connect to a PLC through a router but would prefer if it was just on the same subnet.

    I thought about implementing this with just a raspberry pi and openVPN but I wanted the firewall abilities of PFSense and a bit more horsepower should we decide to include a NUC or something in the blackbox and need to remote in.

    Is this as simple as it sounds? Is there something I am missing or a better way to do this?

    Thanks,
    -Nick



  • So a little confused --

    Why would you not just overnight a NUC with all the tools you need on it and let it establish an openVpn link back to your offices (pfSense) server / service proxy.. For something with more capability maybe a short depth 1RU server or one of the new class on Micro desktops with Compact Flash and more NICs in case you need more than just a connection to the PLC.



  • Both scenarios have advantages/disadvantages.

    NUC onsite connected via remote desktop would require substantially higher bandwidth, Window license, PLC software license, windows updates would be a nuisance or worse, and higher loss if the hardware disappears. About it's only advantage would be if we needed to flash firmware to the remote PLC which would be a gamble when connected through the web.

    The VPN bridge (if feasible) would allow us to connect with any of our dedicated work laptops that are already setup and functionally proven, and if something is missing (not uncommon) it can be installed without transmitting large install files to the site. The PLC network traffic is minimal. Hardware should be cheaper. The intention was to keep the deployed hardware as simple as reasonably possible in form and function. This is in effect mirroring the VPN setup that some of our larger clients have implemented, just in a way that is dead simple and nearly disposable.

    Thanks,
    -Nick



  • Your idea is sound. I've done this with masquerade/NAT instead of bridging though.

    I use a Ubiquiti EdgerouterX (cheap) and run masquerade/NAT on the local interface (typically I get an address from DHCP - you could just as easily set this up/change it over the tunnel). For a similar setup using pfSense, you would need to setup an outbound NAT rule on the LAN interface with the VPN network as the source and the LAN address as the NAT address.

    I use OpenVPN for the tunnel. You will need to setup a static route on your local router once you know the remote LAN IP address range.

    If the PLC network has internet access, you just connect the "black box" to the LAN, power it up and you are done - easy for customers to do.

    When LTE access is needed I use a Netgear LB1120. Since the black box is a client, there is no special public IP/VPN cell plan needed either. I would watch the bandwidth limits closely if you decide to use bridging. The LB1120 can keep track of traffic and reset on whatever day of the month you set.

    If you need to deal with broadcast traffic, then your bridging method would probably be needed - the PLC equipment I've dealt with only needs broadcast for the initial IP address configuration so it wasn't important to me.


Log in to reply