PLC Discovery Fails Over a VPN? Keep Ethernet at the Machine

Your discovery button spins forever, finds nothing, and the ticket says the machine is offline. The machine is fine. Whatever the tool uses to locate devices on that segment does not survive the path it was given, and the reflex is to stretch the customer's Ethernet across the site link so the button starts working again. Work out the dependency first. Most maintenance tools need a route; when one genuinely needs the wire, the durable answer is a managed host sitting beside the machine rather than a bridged network between two buildings.

Why discovery dies at the edge of a routed tunnel

A routed tunnel carries unicast packets between subnets. Broadcast and multicast frames stay inside one broadcast domain, and the VPN endpoint is exactly where that domain ends. A tool that finds devices by shouting into the segment gets silence, because the shout was never forwarded.

The same applies to protocols that are not IP at all, and to vendor frames that ride directly on Ethernet. Those cannot be routed by any configuration, which is why adding routes and firewall rules to a discovery problem often produces no change at all.

Notice what still works in that state. A ping to a known address and a unicast connection to a known port usually succeed, because those are the parts the tunnel was built for. That combination, reachable by address but invisible to discovery, is the signature of a missing broadcast domain rather than a broken network.

Name the dependency before choosing a transport

Read the tool's documentation for how it finds and talks to devices, then match it against this table.

If every requirement in your case sits in the first row, stop here and fix routing. That is a cheaper and far more reviewable change than any topology work, and it keeps the maintenance session inside the access path the customer already approved.

Multicast discovery sits in an awkward middle. A reflector or repeater can forward some of it across subnets, which makes the button work and quietly widens what the remote side can reach. Treat that as a deliberate design with an owner, not as a helpful checkbox.

Put a managed host on the segment and remote into it

The pattern that survives audit is unglamorous. A customer-approved engineering workstation is attached to the machine's maintenance segment, and the technician connects to that workstation through the approved remote-access channel. The tool runs where the wire is; the person runs from wherever they are.

Nothing about the technician's home network then becomes part of the machine's Ethernet, and no bridge is created between two sites that never agreed to share a failure domain.

Keep the local domain as small as the job allows. One maintenance VLAN with one managed host has a bounded broadcast scope, a bounded loop domain, and a failure that stays inside the plant instead of propagating over a WAN link at three in the morning.

Give that host one job, an owner and an audit trail

Name the owner, list the permitted software, define how it is patched, and record which users may reach it. Keep job files and credentials tied to the correct customer, because a shared engineering laptop that has visited six sites is a data boundary problem waiting to be discovered.

Then look at the channels people forget. Clipboard sync, file transfer, mapped drives, and adapter sharing all move data across the boundary, and a remote display session does none of that for free. Decide each one explicitly for this job rather than inheriting whatever the client defaults to. The customer's change window belongs in that decision too, since reachability is not the same as permission to act.

For the policy framing, NIST's SP 800-82r3 treats remote maintenance as controlled access to the operational system, where connectivity and equipment consequences are reviewed together.

Review an L2 extension as its own design

If someone still wants the Ethernet stretched, review it as a separate project with its own risks. Ask what the combined broadcast and spanning-tree domain looks like, how addressing is managed across two organisations, what happens when one side loops, and who approves changes on each end. A successful lab test answers none of those questions, and it certainly does not validate device compatibility, throughput, or recovery after a link failure.

Accept the local-host pattern by proving three things: the tool performs the operation it exists for, the remote user is authorised for this job, and denied systems remain unreachable from that host. Then revoke the temporary access at the agreed end of the job, and confirm it is gone.

That leaves the customer with a controlled place to perform local maintenance, which is a smaller promise than a merged network and a far easier one to keep.