EV Charger Remote Access for MSPs: Reach Charge Points, OCPP, and Modbus Behind CGNAT
Remotely manage EV charge points, their web UIs, OCPP, and Modbus across LTE sites from a browser. One WireGuard tunnel per site, no port forwarding.
An EV charging estate is a fleet of tiny networks scattered across places nobody wants to drive to on a whim: a pair of chargers in a supermarket car park, a bank of units at a hotel, a depot full of fleet charge points, a single kerbside post two hours away. Each site has one or more charge points, often a load balancer or energy meter, and a small router tying it back to a central platform. When a unit drops off OCPP, throws a fault the cloud dashboard cannot clear, or needs a firmware push before a tariff change goes live, someone has to reach the hardware directly. Traditional remote access turns that into a site visit, because charging sites are almost never built to accept inbound connections.
Why EV Charging Sites Are Hard to Reach
Two things work against you. First, connectivity. Most charge points sit on whatever link was cheapest to install: a 4G or LTE router at a remote car park, or a slice of the host site's broadband that you do not control. Cellular links sit behind carrier-grade NAT (CGNAT), so the router has no public IP and no port to forward. Host-site broadband is usually a dynamic address on a network the venue's own IT locks down. There is no static address to point a management tool at.
Second, the hardware. An Alfen Eve, an ABB Terra, a Zaptec Pro, a Wallbox, a Kempower satellite, or a generic OCPP unit runs embedded firmware. You cannot install a remote control agent on it, and the vendor support contract usually forbids third-party software anyway. What you get is a local configuration web UI, an OCPP interface, and in many cases a Modbus TCP register map on port 502 for meter and load-management data. That is all you get, and it is all you should need.
Why Agents and Port Forwarding Both Fail Here
Agent-based remote support reaches a device only if that device can run the agent. On a charging site that covers almost nothing: the charge points are embedded appliances, the meters and load balancers are fixed-function hardware, and the router has no general-purpose software layer. Paying per device for the sliver of the estate an agent can touch, then keeping a second method for everything else, is exactly the overhead an MSP is trying to remove.
Port forwarding fails for a different reason. OCPP already runs outbound from the charger to its backend, so the connection you care about is not the problem. The problem is reaching the local config UI and diagnostics. Exposing a charge point's web interface or an open Modbus port straight to the internet puts grid-connected hardware one weak default password away from a stranger, and Modbus has no authentication of its own. On CGNAT or LTE there is no inbound address to forward to in the first place.
One Tunnel on the Site Router
ProxyLink reaches the whole site from a single outbound tunnel. You install one WireGuard tunnel on the site's router or gateway: a Teltonika RUT on cellular, a MikroTik, an OpenWRT box, or any Linux gateway. The router dials outbound to ProxyLink and holds the tunnel open with a persistent keepalive. Because the connection is initiated from the site, CGNAT, dynamic IPs, and ISP port blocks are all irrelevant. Nothing is installed on the charge points. From that point every IP on the site network is reachable, and the site keeps zero open inbound ports. A scan of the carrier's range finds nothing to connect to.
What You Actually Access
Once the tunnel is up, create a proxy link per device and service:
- Charge point web and config UIs (port 80 or 443): an HTTP or HTTPS proxy link to a unit's local interface for firmware, connector diagnostics, and OCPP endpoint changes.
- Modbus TCP metering and load management (TCP link to port 502): a VPN-secured TCP proxy link so a SCADA tool or a Modbus client on your laptop can poll live register data, session power, and load-balancer state directly from the hardware.
- Energy meters and gateways (TCP or HTTP link): reach a Modbus meter or a monitoring gateway on whatever port it listens on.
- On-site Linux gateway or controller (port 22): a browser SSH terminal for diagnostics and log pulls, with session recording on paid plans.
All of it runs in a browser tab. There is no VPN client to install on the engineer's laptop and no per-site software to maintain.
Multi-Site Fleets
A charge point operator or MSP rarely runs one site. Group each location under its own client group, one tunnel per site, and scope engineers to the sites they cover. Many small sites reuse the same default LAN range, so several will land on 192.168.1.0/24. ProxyLink assigns each gateway tunnel a unique internal range and translates transparently, so two sites with identical addressing stay distinct with no renumbering. Every session is logged with engineer identity, target IP and port, timestamp, and duration, and WireGuard peer isolation is enforced at the kernel level so one site's tunnel can never reach another's.
Deployment
Budget around 15 minutes for the first tunnel. On MikroTik, ProxyLink's auto-configuration deploys the WireGuard config over SSH for you. After that, every charge point, meter, and controller on the site is reachable from a browser with no agent to maintain and no open ports facing the internet. Setup guides for MikroTik, Teltonika, OpenWRT, and pfSense are in the docs.
Try ProxyLink free at app.proxylink.dev, no card required, free during early access. One tunnel per charging site, every charge point reachable from a browser, no static IP and no port forwarding.