Customer can't view the system remotely

Likely causes

• Carrier-grade NAT on the customer's service: inbound forwarding is impossible by design

  most common

  The router's WAN address does not match what an external address-check page reports, or the WAN address sits inside the shared address space reserved for CGNAT (100.64.0.0/10). Forwarding is configured perfectly and nothing ever arrives. No amount of router work fixes this: it needs a publicly routable address from the ISP, or the manufacturer's relay. This is the dead end techs lose the most hours to.

• Manufacturer P2P or cloud relay not enabled, or blocked outbound

  common

  The app reports the device offline while the recorder is perfectly healthy locally. The relay needs outbound access from the recorder; a restrictive firewall, a guest VLAN with client isolation or a blocked outbound port kills it. This is also the correct answer on a CGNAT service.

• Dynamic WAN address with no DDNS

  less common

  Remote access works for days or weeks, stops without anyone touching anything, and works again if you look up the new address. DDNS was never configured, or its credentials expired.

• Mobile app account confused with local device credentials

  They sign into the app and see no devices, or the device is listed and prompts for a password that is not their app password. The app account, the recorder's local users and the cloud device binding are three separate things.

• Port forwarding partial or pointing at the wrong address

  The web page loads remotely and video never plays, because the media port was never forwarded, or the forward points at an address the recorder no longer has, because it was left on DHCP.

• Certificate warning after an HTTPS hardening pass

  Browser or app refuses with a certificate error, usually a self-signed certificate or a name mismatch. Nothing is broken; the trust path was never established.

• Hairpin NAT: they are testing from inside using the external name

  Fails on site Wi-Fi, works on cellular. Many routers will not loop an internal client back through their own public address. Test from cellular before you believe an on-site failure.

What to bring

• Recorder or VMS admin access
• Access to the customer's router, with the customer present and their own credentials
• Phone on cellular data
• The manufacturer's mobile app
• External address-check page
• DDNS account details
• Job file or handover template

Steps

1. 1

   Step 1: Prove it works on the local network first

   Local address in a browser and in the app, on site Wi-Fi. If it fails locally this is not a remote access fault at all and the rest of this sequence is wasted.

   If that doesn’t do it

   Fails locally: work it as a VMS or network fault instead.

2. 2

   Step 2: Test from cellular data, off the site network

   Thirty seconds, free, and it reclassifies the fault. Works on cellular and fails on site Wi-Fi is hairpin NAT, which is a router behaviour and not a system fault.

   If that doesn’t do it

   Fails on cellular too: find out whether the service is even capable of inbound.

3. 3

   Step 3: Check for CGNAT before you configure anything on the router

   Compare the router's own WAN address against what an external address-check page reports. A mismatch, or a WAN address inside the shared CGNAT range, means inbound forwarding will never work no matter how it is configured. Stop configuring and change the conversation: the answer is the manufacturer's relay, or a routable address from the ISP, and that has a cost attached the customer needs to hear about.

   If that doesn’t do it

   Address is publicly routable: decide access method next.

4. 4

   Step 4: Use the manufacturer's relay rather than exposing ports

   Enable it on the recorder, confirm outbound access through the firewall, bind the device to the customer's own account. Then explain plainly why publishing a recorder's web port to the internet is the wrong answer even when they ask for it: these devices are scanned continuously, reused credentials are the routine way they are taken, and a compromised recorder sits inside the customer's network. If inbound access is genuinely required, the right shape is a VPN to the site, not a forwarded port.

   If that doesn’t do it

   Relay unavailable or blocked by policy: do inbound properly.

5. 5

   Step 5: If inbound is required, build it properly and once

   Static internal address on the recorder outside the DHCP scope, forward only the ports the client actually needs including the media port, DDNS where the WAN address is dynamic, unique strong credentials, current firmware. A VPN on the customer's own router is usually free and always better.

   If that doesn’t do it

   Still no connection: reconcile the accounts.

6. 6

   Step 6: Reconcile the three account lists

   App account, cloud device binding, local recorder users. Give the customer a named user with the permissions they need, not the installer's administrator account, which should never leave your hands.

   If that doesn’t do it

   Accounts correct and still failing: look at the certificate.

7. 7

   Step 7: Fix the certificate path, or explain it

   A self-signed certificate means a warning every time. Either install a certificate the client trusts, or document the expected warning so it is not reported as a fault. Do not teach a customer to click through security warnings as a habit.

   If that doesn’t do it

   Certificate clean and still failing: capture the app's error and escalate with the ISP and manufacturer details attached.

8. 8

   Step 8: Write down what you configured and hand it over

   Access method, ports, DDNS host, who owns the account, who holds the admin credential, and the date. This is the document that stops the next call being another afternoon.

More Video Surveillance guides

• Camera drops off stream intermittently
• Camera drops or whites out when IR engages
• Camera cycles power in a boot loop
• Motion recording triggering on nothing
• Water or fog inside the camera
• Faces black against a bright doorway

All 54 guides