NVR cameras vanish over VPN? Check the PoE subnet overlap

Open the NVR from the remote site and the live view may fail while the LAN page still loads. The tunnel is up, the recorder answers, and the reply takes a path nobody drew: the recorder's internal camera port. On a PoE model, that second connected network is part of the address plan, whether or not it appears on the main LAN settings page.

Walk the failure from the client to the recorder and back. The return leg is where the hidden interface shows up.

Reproduce from the remote client, not the LAN

Test from a client that actually crosses the VPN. A browser on the same LAN can reach the recorder directly, so it never exercises the path that fails. Record the client address, the recorder's LAN address and the exact service that fails.

Try more than one service. A web management page, a live stream and a playback request can use different ports and different proxies, and one may work while another fails. That comparison tells you whether the fault is service-specific. It also keeps a single failed port from being mistaken for a dead recorder.

Note whether the request reaches the recorder at all. A connection that never arrives points at routing or firewall on the way in; a request that arrives and then stalls points at the reply path or the service. Use the recorder's connection log or a counter if it offers one. A packet capture at the site boundary is the fallback.

Follow the reply out of the recorder

Consider an illustrative layout with two sites. The remote client is 10.60.0.25/24, the recorder's site LAN is 10.70.0.0/24, the recorder's LAN address is 10.70.0.50, and its internal PoE network is 10.60.0.0/24.

Site A client:        10.60.0.25/24
Site B LAN:           10.70.0.0/24
NVR LAN address:      10.70.0.50
NVR internal PoE net: 10.60.0.0/24

Traffic from Site A reaches 10.70.0.50 over the tunnel. The recorder then looks up the return address in its own table and finds a connected prefix covering 10.60.0.25. That prefix is more specific than its default route, so the reply heads toward the camera ports rather than the tunnel.

Neither the tunnel's negotiated state nor a correct return route on the Site B router can override that local choice. Nor does a successful request to another server at Site B prove anything about this device's second interface.

Inventory the hidden PoE network

Read the recorder's network settings for an internal NIC, a PoE section or a separate camera subnet. Some models expose it as a second interface with its own address; others hide it behind a camera configuration page.

Check the model and firmware documentation rather than assuming a factory prefix. A common default on one product line is not a fact about every recorder, and a copied number can hide the real overlap instead of revealing it.

Compare the discovered range with both site LANs, the VPN client pools and any other connected network on the recorder. Overlap with the remote client pool is the case that redirects replies; overlap with an unrelated local range can break local camera access without touching the VPN. Draw the overlaps on one sheet before choosing new numbers. Two overlapping ranges look obvious there and invisible in two separate settings pages.

Record the range, the interface name and the camera addresses on it. That inventory is what the renumbering plan has to preserve. Include the camera models and firmware versions while you are there.

Renumber with the cameras, not just the NVR

Choose a camera range that overlaps neither site, the VPN pools nor another connected network. Then list everything that depends on the old one: dynamic leases, statically configured camera addresses, saved channels, recording schedules and any automatic configuration the model performs. That list is the migration checklist, not an afterthought.

Move the internal network during an authorized window and keep the recorder's backup and recovery access available. Changing only the recorder's internal address can strand cameras that still hold the old range, and the recorder may report them as offline rather than misconfigured. Keep the old configuration export until the new streams have run for a full day.

Verify local camera streams and recording before testing the remote client. A remote fix built on a recorder that has lost its cameras is not a fix.

Verify streams, recording and remote access

From the remote client, test live view, playback and the management page separately. Watch the request and response at the controlled LAN and VPN boundaries so the return path is visible, not inferred from a working page.

If a camera-access proxy or virtual-host feature is part of the design, treat its port mapping and permissions as another explicit path with its own review. Do not open every camera port or widen the VPN selectors to compensate for the overlap.

When renumbering is impossible, any translation alternative needs a supported address view and its own policy review. The general lesson reaches beyond recorders: an appliance may keep a camera, service or management network that a remote site already numbers.

Record the final ranges and the tested services in the site plan. The next recorder, camera expansion or VPN pool change will reuse those numbers, and an overlap that was fixed once is easy to reintroduce.