Networks, members, exit node, ACL, peer mesh, and subnet routes

A network in Qarvix describes a secure WireGuard mesh: which members are connected, what VPN addresses they've been issued, which LAN subnets are reachable through routers, and which traffic directions are allowed.

A good network is understandable without guesswork: who's a member, where the gateway is, which subnets are announced, whether peer mesh is on, who can reach a site, and whether there's an exit through an exit node.

In short

• A network ties together the hub, managed devices, and static clients.
• The VPN IP is issued from the network's CIDR range.
• A subnet route opens access to the LAN behind a router.
• An exit node lets you route traffic through a chosen node.
• ACL restricts access between device groups, networks, routes, and the internet.
• Peer mesh allows direct links between managed routers when that's permitted; static clients never take part in mesh.
• It's better to keep default access closed and only open the directions you need.

Network members

A network member is a peer in a Qarvix WireGuard mesh.

Typical members:

A single managed router can be a regular peer, a gateway for a LAN subnet, or an exit node. The role depends on the scenario and the network's configuration.

For ACL, members are grouped into device groups. An access rule is set not for a specific router, but for a group: this lets you add and remove devices without rebuilding the rules.

Network CIDR

A network's CIDR sets the VPN address range for its members.

Example:

Name: retail-east
CIDR: 10.110.0.0/24
Hub: 10.110.0.1
Site router: 10.110.0.4
Engineer: 10.110.0.8

Before creating a production network, check that:

• the range doesn't overlap with sites' LANs;
• the range doesn't overlap with a corporate VPN;
• the range is large enough for future devices;
• addresses can be explained clearly in documentation and support.

If several branches use the same local subnet, that needs to be accounted for in routing. Sometimes it's better to split these sites across separate networks or agree on a NAT/addressing plan in advance.

Subnet routes

A subnet route is a route to a local subnet behind a router.

Example:

Site router in Qarvix: 10.110.0.4
Site LAN: 192.168.10.0/24
Camera: 192.168.10.20
PLC: 192.168.10.30

Once the route is turned on, users and services can reach devices on the LAN through Qarvix, provided ACL allows it.

A subnet route is needed when:

• you need to open cameras behind a router;
• you need data from PLCs or sensors;
• you need to reach a local device's web interface;
• a monitoring server needs to reach an API at the site;
• you'd rather not configure a VPN on every device on the LAN.

Don't open an entire LAN subnet to every user. The route provides technical reachability, but access rules should determine who's actually allowed to use it.

Exit node

An exit node is a network member through which outbound traffic can be routed.

Scenarios:

• the service team needs to reach an external resource from the site's address;
• you need to diagnose how a site sees the internet;
• you need to temporarily route traffic through a remote router;
• you need access to resources that only accept connections from the site's network.

Turn on an exit node carefully. It changes the traffic path and can affect security, speed, and reachability.

Before turning it on, check:

• who's allowed to use the exit node;
• which traffic directions are allowed;
• whether this violates any client requirements;
• whether the site's link has enough bandwidth;
• whether enabling it is visible in the log.

ACL

ACL is the set of access rules between a device group (or a whole network) and a destination: another group, a subnet route, the internet, or the entire network.

ACL answers questions like:

• which device group can connect to the router;
• which group can reach a LAN subnet;
• is access to device APIs allowed;
• can network members talk to each other directly;
• what's denied by default.

ACL doesn't decide which sites a specific user sees in the dashboard - that's determined by the organization, the role, and which networks it's bound to. If you need to limit which networks an engineer or contractor can see, that's a role's job, not ACL's: see Users, roles, and SSO for more.

A practical approach:

A good access policy starts with deny by default. Then only the necessary directions are opened.

Default access

Default access determines what happens when there's no explicit rule.

For production networks, this model is safer:

deny by default
only explicitly described directions are allowed

This approach takes a bit more configuration, but reduces the risk of accidentally opening an extra subnet or site.

For a pilot, a looser model is sometimes acceptable, but it should be revisited before going into production.

Peer mesh

Peer mesh allows direct links between network members when it's technically possible and permitted by policy.

Peer mesh only works between managed routers. A static client never takes part in mesh: it has no management channel through which a direct WireGuard link could be assigned, updated, or torn down once its configuration has already been issued. This is a limitation at the implementation level, not a setting you can flip in the interface - mesh pairs are always assigned between two routers.

Without peer mesh, traffic more often flows through the hub. With peer mesh, a pair of routers can establish a direct WireGuard link with each other, which can reduce latency and load on the central node.

Peer mesh is useful when:

• two routers need to exchange traffic directly and often;
• there are several managed routers on the same network;
• lower latency between sites matters;
• the links allow for a direct connection.

Don't enable peer mesh automatically for every pair of routers. First check that it won't break access boundaries between sites.

LAN subnets in one click

One of Qarvix's strong scenarios is turning on a route to a LAN subnet without manually configuring WireGuard on every workstation.

For a manager, it looks like this:

The site is connected through a router
The administrator turns on a route to the LAN subnet
The service team gets access to the devices it needs
No ports are opened outbound
No public IP is needed at the site

For an engineer, this means fewer manual configurations and fewer mistakes in AllowedIPs, routes, and keys.

Typical scenarios

Access to the router only

Use this when you need to administer the router itself but not open up the LAN.

Engineer -> the router's VPN IP
The site's LAN isn't announced

Access to cameras or PLCs

Use a subnet route.

Engineer -> Qarvix Hub -> site router -> 192.168.10.0/24
ACL allows only the users who need it

Multiple sites in one mesh

Use separate routes and ACL.

Service team -> Site A
Service team -> Site B
Contractor -> Site C only

Device APIs for monitoring

Open only the address and port you need.

Monitoring -> 192.168.10.50:8080
The rest of the LAN stays closed

Checking routing

If connectivity isn't working, check layer by layer:

1. The member is online.
2. The VPN IP was issued correctly.
3. The WireGuard handshake is fresh.
4. The subnet route has been added.
5. The router knows the local LAN.
6. The firewall at the site allows the traffic through.
7. ACL allows the direction.
8. The local device responds.
9. There's no subnet overlap.

Don't start diagnostics by reinstalling the agent if the device is online. The problem is more often in the route, ACL, firewall, or address plan.

Checklist

• The network has a clear name.
• The CIDR doesn't conflict with LANs or corporate VPNs.
• Members are on the right network.
• Gateway devices are clearly marked.
• Subnet routes were added only for the subnets that need them.
• The exit node is enabled only where it's actually needed.
• ACL denies extra directions.
• Peer mesh is enabled deliberately.
• LAN/API access is restricted by user or role.
• Logs show route and access-rule changes.

Related sections

• Devices and VPN addresses - which members belong to a network.
• Device API over the tunnel - how to open a local API through a route.
• Users, roles, and SSO - who gets access to a network and its subnets.
• Diagnostics and common issues - how to work through routing problems.