Documentation
Watch your IP cameras remotely — never exposed to the internet
An IP camera at home, in the workshop or at a second home — you want to see it from your phone or your PC, wherever you are. The usual answers — the manufacturer’s cloud, proprietary P2P, opening a port on the router — all come down to handing the stream to a third party or exposing the camera to the internet. VIGIL-MESH takes the other road: the camera (or the machine that aggregates it) joins an encrypted private network, and you watch its RTSP stream across that network, as if you were on site. Zero open ports, zero mandatory cloud account, zero router configuration.
The three classic access modes, and what they cost you
To watch a camera remotely, the video stream has to leave the local network one way or another. The market has three standard answers, and each one solves the problem by creating another: a dependency, an exposure, or both.
The manufacturer's cloud
The camera pushes its stream to the vendor’s servers, and the mobile app fetches it from there. It is simple, but your footage travels through infrastructure you do not control: confidentiality depends on the vendor’s practices, and access itself depends on the survival of its service — the cloud shuts down, and the camera goes silent remotely.
Proprietary P2P
Many cameras embed a home-grown “P2P” mechanism: the camera and the app find each other through a vendor rendezvous server, with nothing to configure. Convenient, but these protocols are neither published nor auditable: you place your trust in a black box, often hosted abroad, whose encryption and access you cannot verify.
Port forwarding (and DDNS)
Forwarding a router port to the camera or the NVR, often paired with a DDNS name, makes the stream reachable from the internet — by you, and by everyone else. An exposed service is scanned around the clock; every firmware flaw becomes exploitable from anywhere. Some cameras even open that port on their own via UPnP, without asking you.
| Vendor cloud | Proprietary P2P | Port forwarding | |
|---|---|---|---|
| Camera exposed to the internet | No, but stream held by a third party | No, but opaque protocol | Yes, reachable by anyone |
| Dependency on a third-party service | Total | Total (vendor rendezvous) | None |
| Stream confidentiality | Depends on the vendor | Unverifiable | Often cleartext, exposed |
| If the service shuts down | No more remote access | No more remote access | Not applicable |
| Router configuration | None | None | Forwarding rule to create and maintain |
The private-network approach: the camera joins you, not the internet
With VIGIL-MESH, the question “how do I get the stream out?” disappears. Your machines — the site where the cameras live, your PC, your phone — join a single encrypted private network. Inside that network, each one keeps a stable address (in 100.64.0.0/10) and a name (MagicDNS): you open the camera’s RTSP stream exactly as if you were on the site’s local network.
In practice, the VIGIL client does not install on the camera itself but on a machine at the site that can see it: the PC or mini-PC running the recording software (software NVR), a Jetson, any Linux or Windows box. A single connected node on the site side is enough to make the whole camera fleet reachable in the private network.
- Zero inbound ports, zero router configuration — each machine only makes outbound connections, a single flow on 443 UDP, the same port as the modern web. Nothing to forward, nothing to expose, and it also works behind a 4G/5G connection on CGNAT.
- RTSP carried as-is, encrypted end to end — RTSP is the standard streaming protocol of IP cameras, and it mostly travels without encryption of its own. Across the mesh, it rides inside end-to-end QUIC/TLS 1.3 sessions: the infrastructure only sees packets go by that it cannot read.
- Stable addresses and machine names — the site machine keeps the same address and the same MagicDNS name, wherever it is and whatever path the traffic takes. Your video players and VMS tools find the cameras without reconfiguring anything.
- Access closed by default (ACL) — access policies are deny by default: you explicitly decide which machines may reach the camera site. Your phone gets in; the rest of the network does not, unless you say so.
Real time: end-to-end UDP, over the shortest path
Live video is real-time traffic: the RTSP stream negotiates RTP packets, usually carried over UDP, and dropping a frame beats delaying everything. A transport that stacks TCP on top of TCP degrades exactly that behavior. VIGIL-MESH carries UDP datagrams as datagrams through the encrypted tunnel: the stream keeps its real-time nature end to end.
Path-wise, the connection is immediate through a relay (the vigie), then migrates without interruption to the direct path between your two machines as soon as NAT traversal establishes it. The video then takes the shortest route, peer to peer, with no detour through a third-party server. And while the traffic is relayed, the vigie is structurally blind: it holds no keys and never sees the footage.
- Driving a PTZ camera — commands travel as end-to-end datagrams, with no head-of-line blocking: the movement follows the command.
- Viewing in the browser — the media console can play an RTSP/RTP stream (H264/H265) right in the tab, without a plugin.
- Keeping your usual player — any video player or VMS that opens an RTSP URL works across the mesh as it does locally, pointed at the name or stable address of the site machine.
Several places, one network: home, workshop, second home
The real-world case is rarely a single camera: it is the house, plus the workshop, plus the second home — each behind its own router, sometimes behind a 4G connection. With a private network, each site enrolls one machine, and every location ends up in the same space: one inventory, one name per machine, and your cameras viewable from anywhere without juggling three apps.
- One central multi-site VMS — the supervision software installed at home sees the other sites’ cameras through their stable addresses, as if everything sat on the same LAN.
- Tailored access — ACLs, closed by default, let you give each person exactly what they should see: a relative gets the house cameras, not the workshop’s.
- All your devices — Windows, Linux, Android and NVIDIA Jetson clients: the phone that watches and the mini-PC that aggregates speak the same network.
- Immediate revocation — phone lost or stolen? Revoke it from the console: it instantly loses access to the network, and therefore to the streams.
Recording, meanwhile, stays where it belongs: on site, in the NVR or on the camera’s card. The private network does not replace your recorder; it gives you safe access to what is recorded, and to the live view, without routing your archives through a cloud.
ONVIF discovery: your tools find the cameras across the mesh
ONVIF is the interoperability standard of IP cameras, and its discovery relies on WS-Discovery: multicast announcements, designed never to leave the local network. That is why a remote VMS connected over a classic VPN does not “see” the cameras: multicast dies at the first router.
VIGIL-MESH treats each network as a broadcast domain: IP multicast is replicated encrypted between members, with the TTL carried intact — announcements arrive as if they were local. Multicast subscriptions are detected automatically (IGMP/MLD): nothing to declare, your IP stack does the work. An ONVIF tool launched from home therefore discovers the remote site’s cameras as on a LAN, and the mDNS of devices that announce themselves that way crosses just the same.
Setting up access to your cameras, step by step
Setup is a short sequence: connect the site machine that sees the cameras, connect the devices that will watch, and open the stream as you would locally. No step touches the router.
- 1Create an account and a workspaceThis is the space that will hold your private network — free for personal use.
- 2Install the client on the machines involvedOn the site machine that sees the cameras (the NVR PC, a mini-PC, a Jetson) and on the devices that will watch: your PC, your Android phone.
- 3Enroll each machineIn the console, Networks page → Machines → “Add a machine”: one single-use key per machine, passed to the client. The machine generates its identity and opens no inbound port.
- 4Verify connectivityEach machine receives its stable address and its MagicDNS name; a ping between the phone and the site machine confirms the network is up.
- 5Open the stream as if localIn your player or your VMS, point at the camera through the site machine’s address or name, with the camera’s usual RTSP URL — exactly as if you were on site.
Troubleshooting: the classic blockers and their cause
When “it doesn’t work”, the cause is almost always one of the following — and one golden rule: validate the stream locally first, on the site LAN, before looking at the private network.
- The stream does not open at all — the RTSP URL (path, credentials, port — 554 by default) is vendor-specific. Test it from a machine on site: if it fails locally, the problem is the camera, not the network.
- “Connection refused” across the mesh while local works — access policies are closed by default. Check in the console that a rule allows your device to reach the site machine.
- The picture stutters on the go — the site’s upload bandwidth is the scarce resource. Switch to the secondary stream (substream) for remote viewing, and keep the main stream for local recording.
- ONVIF discovery finds nothing — check that the scanning tool and the site machine are members of the same VIGIL network: broadcast is replicated between members of a network, not across networks. Failing that, add the camera by its address: discovery is a convenience, not a prerequisite.
- Site connected over 4G/5G — since no port is required, the carrier’s CGNAT blocks nothing: the site machine connects outbound. If both ends sit behind symmetric NATs, traffic stays relayed through the blind vigie — the stream flows, over a longer path.
- The name does not resolve — try the machine’s stable address (100.64.x.x): if it answers, the network works and the issue is name resolution on the viewing device.