Access a smart camera over VPN: add a remote subnet route

Your smart camera answers every request on the plant LAN, then goes silent the moment you dial in over the VPN. The fault is the tunnel, not the camera: a VPN carries only the subnets and ports the gateway has been told about, and smart cameras use more of both than most devices. This guide gives you the two changes that fix it — a remote subnet route whose destination is the camera's IP and whose next hop is the gateway's own LAN address, plus the session ports forwarded — and a test order that shows which half is missing. It is written for controls and service engineers who reach machines through industrial remote-access routers.

Why it works on the LAN and fails through the tunnel

Discovery dies first, and by design. Smart-camera discovery protocols ask the subnet with a UDP broadcast, sent to 255.255.255.255 or to the subnet broadcast address such as 192.168.10.255. Routers drop broadcasts, so the question never enters the tunnel and the device list stays empty however perfect your routing. That is why GenICam discovery uses subnet broadcast and ping is not enough, and why the remedies for a GigE Vision camera connection without broadcast discovery — connecting by typed IP — apply here unchanged.

Routing is the second failure. Many remote-access gateways translate all client traffic to the gateway's own LAN IP by default. The camera then answers the gateway instead of you, and any flow that needs the client's real address — UDP pairs, or the second TCP channel the client opens for live images — never comes back. Login succeeds; images stall.

Ports are the third. A smart-camera session is several connections at once: a main session, a data channel and UDP side flows. A firewall that forwards only the first port produces the classic half-session: ping works, login works, live image hangs.

What you need

• The camera's static IP, mask and router address, read off the panel drawing or the DHCP reservation; the camera static IP setup for reaching a smart camera on the same subnet fixes a camera that still swims.
• Administrator access to the remote-access gateway's web interface: its static-route table (many interfaces label it remote subnets) and its firewall or port-forwarding table.
• The camera vendor's port list, printed in the client software manual.
• The client PC with the camera software, plus a browser as a second test path, and the camera finder if you are still choosing the hardware.

Any Ethernet camera behaves the same here, from a small Fast Ethernet vision sensor bolted to the machine to a GigE smart camera on the cell network: once the tunnel knows their addresses, both are ordinary routed devices.

Step 1. Fix the camera's address on the plant network

1. Set a static IP on the plant subnet, outside the DHCP pool — 192.168.10.50 with mask 255.255.255.0 in this example — or create a reservation on the plant DHCP server keyed to the camera's MAC address.
2. Record the address, mask and router in the panel drawing. A camera that changes address between visits breaks the route you are about to build.
3. From a PC on the same switch, ping the camera and open one client session. That local session is the baseline: every fault after this point lives in the tunnel.

Step 2. Add the remote subnet route on the gateway

In the gateway's route table, add one entry:

The next hop being the gateway itself looks odd and is the whole trick. It tells the gateway: traffic for 192.168.10.50 is mine, on my LAN side — route it instead of translating it to my own address. On gateways that NAT client traffic by default, this single line switches NAT to routing for that host, which restores the client's real IP as the camera sees it and lets UDP pairs and second channels survive.

Start with the host route. Widen to the whole cell subnet — 192.168.10.0 with 255.255.255.0, same next hop — only when the same tunnel must also reach a PLC or HMI. The identical entry carries controller traffic, as this walkthrough of remote PLC programming over VPN with subnet routing shows. The host-route trick also applies with no VPN at all, when the camera sits on a second subnet in the same cabinet: see accessing GigE cameras from another subnet without direct cabling.

Step 3. Forward the session ports

Leave UDP 68 closed: DHCP is a local exchange between the camera and the plant server and never crosses a routed tunnel. If your vendor's list shows more ports, forward the set above first and add the rest only when a feature asks for them.

Step 4. Connect from the client and verify each layer

1. Connect the VPN and note the address it assigns the laptop: 10.99.0.23 from the pool in the worked example below.
2. Ping the gateway's LAN IP (192.168.10.1), then the camera (192.168.10.50). A camera reply proves the route; a gateway-only reply points at the firewall or at an IP filter on the camera itself.
3. Open the camera's web page by typed IP, then start the client software and add the camera by IP address. Do not wait for discovery: it stays empty through any routed tunnel.
4. Run one real inspection cycle — trigger, image, result — because that single cycle exercises the main session, the data channel and the UDP flows together.
5. Leave the session idle for ten minutes, then trigger again. A session that dies while idle points at the gateway's idle timeout, not at your route.

Worked example: one cell subnet, one client pool

• Cell LAN 192.168.10.0/24, mask 255.255.255.0. Camera static at 192.168.10.50. Remote-access gateway LAN IP 192.168.10.1.
• VPN client pool 10.99.0.0/24; the laptop receives 10.99.0.23.
• Overlap check: 10.99.0.23 lies outside 192.168.10.0/24 because the first octet 10 differs from 192, so the client sends plant-bound packets into the tunnel. Had the pool been 192.168.10.0/24, every client would treat the camera's address as its own on-link subnet and answer locally; nothing would work, and the fault would look like the camera's.
• Route entries on the gateway: 192.168.10.50 / 255.255.255.255 / 192.168.10.1 for the camera, optionally 192.168.10.0 / 255.255.255.0 / 192.168.10.1 for the whole cell.
• Firewall forwards: TCP 44818, UDP 44818, UDP 2222, TCP 1069, UDP 1069 and TCP 50000, plus TCP 80 for browser checks.
• MTU arithmetic: a tunnel wraps every packet in roughly 60-100 bytes of header (WireGuard near the bottom of that range, IPsec with NAT-traversal near the top), so a 1500-byte plant frame can exceed the path limit and large transfers stall while pings pass. Set the tunnel interface MTU to 1380 — 1500 − 120 = 1380, covering the worst case with 20 bytes spare — or clamp TCP MSS to 1340 (1380 − 40 for the TCP and IP headers); if frames still drop, step down to 1300.

With those entries in place the laptop at 10.99.0.23 pings 192.168.10.50, opens the session by IP, triggers a job and reads the result string — the same experience as sitting at the bench switch.

When it still fails, test in this order

1. Address overlap between the VPN pool and the plant subnet — compare first octets and masks on both ends; the subnet mismatches behind most connection failures are catalogued in smart camera not connecting: fix IP and subnet mismatches.
2. A client with several network adapters — a second NIC or Wi-Fi adapter can answer for the plant subnet or send packets out the wrong interface; disable unused adapters. It is the same multiple-address trap that makes UDP broadcast discovery fail with several IPv4 addresses.
3. An IP allow list on the camera — some cameras accept only configured client addresses; add the client pool 10.99.0.0/24 to the list or clear it for the test.
4. An office-side firewall blocking return flows on TCP 50000 or the UDP ports — test from a phone hotspot to split the problem into plant-side and office-side halves.
5. The gateway's idle timeout, for a session that drops after a few quiet minutes — raise it to cover a shift, not just a demo.

Keep the tunnel narrow

The route table above deliberately exposes one host. Keep it that way: scope the firewall rule to the camera's IP and the six forwarded ports, give every remote user an individual account with an expiry, and re-read the rule when the machine moves. A cell that shares a busy plant LAN needs harder separation than one tunnel can provide — the design options are in vision cell network isolation from a busy plant LAN.

Decision: add the host route first, forward the six session ports, connect by typed IP, and widen the route only when a second device genuinely needs the tunnel. If you are still choosing the camera itself, the smart cameras page lists vision sensors that run the inspection on the device, and the systems topic page collects the surrounding network set-ups.