Access to device APIs over the tunnel

Qarvix can give access not just to the router itself, but to the devices behind it: cameras, PLCs, meters, sensors, POS terminals, local web interfaces, and internal APIs.

The main benefit: the device stays on the site's local network, no inbound ports are opened outward, no public IP is required, and access runs through Qarvix's managed VPN mesh.

In short

• A device can stay on the LAN behind the router.
• The router connects to Qarvix as a managed device.
• The administrator turns on a route to the LAN subnet or a specific service.
• A user or server reaches the API over the tunnel.
• Access is restricted by roles, ACL, and routes.
• Access events and configuration changes can be checked in the logs.

When you need this

This scenario fits when a site has local devices that need to be reached remotely.

Examples:

If you previously used port forwarding, a public IP, TeamViewer on a workstation, or separate VPN files for this, Qarvix lets you put together a more manageable scheme.

Basic scheme

Service team or monitoring server
        |
        | WireGuard through Qarvix
        |
Qarvix Hub
        |
        | WireGuard to the site router
        |
Site router
        |
        | LAN 192.168.10.0/24
        |
Cameras, PLCs, sensors, device APIs

No public inbound port is needed at the site. The router or agent initiates the secure connection, and LAN access runs through a configured route.

What needs to be set up

Access to an API over the tunnel usually requires:

1. A managed router at the site.
2. A Qarvix network with a correct VPN range.
3. A route to the LAN subnet behind the router.
4. An ACL or access rule for the users and services that need it.
5. Knowing which address and port the request should reach.

Example:

Site LAN: 192.168.10.0/24
Meter API: 192.168.10.50:8080
User: service team
Access: only TCP 8080 to 192.168.10.50

If you need to open one service rather than the whole subnet, access rules should be as precise as possible.

Cameras and video surveillance

For cameras, you usually need access to a web interface, an RTSP stream, an NVR, or a management API.

Qarvix helps you:

• avoid exposing cameras to the internet;
• avoid configuring port forwarding at the site;
• avoid buying a public IP for a SIM card;
• give access only to the service team;
• quickly disable a contractor once the work is done;
• see in the logs who changed access.

Example:

Site router: 10.120.0.4
Camera LAN: 192.168.20.0/24
Camera 1: 192.168.20.11
Camera 2: 192.168.20.12
NVR: 192.168.20.100

For a manager, the result is simple: cameras stay inside the site, but the service team gets managed access without a visit and without open ports.

PLCs and industrial equipment

PLCs and industrial equipment often sit in closed LAN segments. Access to them needs to be opened especially carefully.

Recommendations:

• don't open an entire subnet unless you have to;
• restrict access to specific users and roles;
• agree on addresses, protocols, and ports;
• keep a log of access changes;
• use a separate network for the industrial mesh;
• check that the VPN range doesn't conflict with the ICS/SCADA addressing.

If the equipment is critical, access should be temporary or strictly regulated.

Meters and sensors

For meters and sensors, what's usually needed isn't manual engineer access, but regular data collection.

A typical setup:

Metering server -> Qarvix VPN -> site router -> meter API

Benefit: the metering server gets data directly over an encrypted tunnel, without exposing the meter to the internet and without needing a manual VPN at every site.

This scenario fits well into reports: you can show which sites are connected, which devices are reachable, and where connectivity issues occurred.

Access for an external system

If an external system needs to reach devices through Qarvix, don't use a personal account.

It's better to use:

• a separate static client for the server;
• a separate API token for the integration;
• a separate role or access group;
• restrictions by address and port;
• logging of changes and requests, where available.

This makes it easier to revoke access, rotate a token, or move an integration without affecting users.

Security

Access over the tunnel is safer than exposing devices outward, but that doesn't mean everything can be opened to everyone.

Check:

• who's getting access;
• to which subnet or address;
• whether access is needed on an ongoing basis;
• which protocols are allowed;
• whether there are role-based restrictions;
• whether you can open just one API instead of the whole LAN;
• whether access changes are visible in the log.

Be especially careful when opening access to devices with weak passwords, old firmware, or no support for modern authentication.

What to hand off to the service team

So the team can work without extra back-and-forth, record:

• organization name;
• network name;
• site or router name;
• LAN subnet;
• device address;
• port and protocol;
• who has access;
• expiry, if access is temporary;
• contact for the person responsible for the site.

Example:

Organization: Client A
Network: warehouse-cameras
Router: router-warehouse-01
LAN: 192.168.20.0/24
NVR: 192.168.20.100:443
Access: video surveillance service team

Common issues

API doesn't open even though the router is online

Check the subnet route, ACL, the router's firewall, the device's local IP, and whether the API is reachable from the site's LAN.

The router pings, but the device behind it doesn't

The route to the LAN is most likely not configured, forwarding/firewall isn't allowed, or the local device doesn't know the return route.

The device is accessible to every user on the network

Check ACL and default access. A route to the LAN shouldn't automatically mean access for everyone.

The monitoring server stopped receiving data

Check the freshness of the static client's WireGuard handshake, whether the router is reachable, the device log, and any changes to access rules.

Checklist

• The site router is online.
• The LAN subnet has been added as a route.
• The API address is known and verified.
• ACL allows only the necessary directions.
• Access isn't open to every user.
• The API isn't exposed directly to the internet.
• The integration uses a separate client or token.
• The audit log shows access changes.
• There's someone responsible for the site and the service.

Related sections

• Networks, routes, and ACL - routes to the LAN and access rules.
• Devices and VPN addresses - network members and gateway devices.
• Users, roles, and SSO - who gets access to the API.
• Logs and reports - how to oversee changes and prepare operational material.
• Diagnostics and common issues - what to check when an API is unreachable.