Remote support VPN networks (L3 overlay) in Telmetra

If you need a remote support VPN that spans multiple client sites (and multiple computers per client), an L3 overlay can be the simplest way to make “private IP access” predictable again—without reshaping the client’s LAN.

Telmetra’s VPN networks are designed for technicians: you define a network, add computers, and endpoints apply config automatically. Traffic prefers peer-to-peer connectivity when possible, with a secure fallback when direct paths aren’t available.

Answer first

• Definition (1–2 sentences): A remote support VPN is an L3 overlay network that assigns each enrolled computer an “overlay IP” so technicians (and other enrolled computers) can reach services privately using stable IPs, even across NAT and different client LANs.

Quick steps

1. Create a VPN network (pick a non-overlapping CIDR for the overlay).
2. Add the target computers to the VPN (a computer can be in multiple VPN networks).
3. Confirm the cross-client warning only if you’re mixing clients in one VPN.
4. Wait briefly for endpoints to apply the update.
5. Test reachability using the assigned overlay IPs (start with a simple connectivity check, then the real service).
6. If direct connectivity isn’t possible in your environment, the secure fallback path should still keep traffic flowing.

Key takeaways

• Technician-managed: VPN networks are managed from the Web Console by technicians/admins.
• Hybrid connectivity: Peer-to-peer preferred, with a secure fallback when needed.
• Scoped + auditable: creation/activation actions require a reason and are audit-logged.

Table of contents

• What problem a remote support VPN solves
• How Telmetra VPN networks work (control plane vs data plane)
• Security & governance (what’s enforced)
• Prerequisites
• Step-by-step
• Verification (how to confirm it worked)
• Common pitfalls
• When NOT to use Telmetra VPN networks
• FAQ
• Next step

What problem a remote support VPN solves

Remote support gets messy when you need to access “internal-only” services:

• Machines are behind NAT, carrier-grade NAT, or client firewalls
• IP ranges overlap across clients (10.0.0.0/8 everywhere)
• You need stable addressing for automation, scripts, or monitoring checks
• You need tech-to-host and host-to-host connectivity without building site-to-site tunnels for every client

An overlay VPN sidesteps most of that by giving each enrolled computer a stable overlay address inside a VPN-defined CIDR (e.g. 100.96.10.0/24).

How Telmetra VPN networks work (control plane vs data plane)

Telmetra splits VPN into:

• Control plane: authentication, authorization, membership, configuration distribution
• Data plane: encrypted packet transport and routing (peer-to-peer when possible, secure fallback otherwise)

At a high level:

1. A technician creates a VPN network and adds computers.
2. Telmetra distributes an updated configuration to each enrolled endpoint.
3. Each endpoint assigns an overlay IP to participate in the VPN network.
4. When traffic is sent to another overlay IP, the endpoint encrypts packets and attempts a direct peer-to-peer path.
5. If a direct path isn’t available (common in locked-down networks), traffic can use a secure fallback path.

Security & governance (what’s enforced)

Telmetra’s VPN networks are built to be technician-operable but controlled:

• Technician-only access to VPN management in the Web Console.
• Org-scoped authorization: VPN objects and memberships are tied to an organization.
• Reason-required actions: creation/activation actions require an explicit reason.
• Audit logging: VPN create/update/delete and membership changes are recorded.

What this post does not promise:

• No claims about compliance outcomes (GDPR/ISO/SOC2) just from using VPN.
• No claims about “unbreakable” security; treat VPN keys and admin access as high value.

Prerequisites

Before you expect traffic to flow:

• Endpoints enrolled and online in Telmetra.
• Firewall policy allows required connectivity (peer-to-peer when available; otherwise the secure fallback path).
• Non-overlapping CIDR: choose an overlay range that won’t collide with client LAN ranges you need to reach.

Step-by-step

1. In the Web Console, open VPNs.
2. Create a new VPN network:
   • Name: pick something descriptive (e.g. “Client access overlay”)
   • CIDR: pick an overlay range that doesn’t overlap common client ranges
   • Provide a reason when prompted
3. Add member computers:
   • If you add computers from multiple clients, you’ll get a warning confirmation (only when it actually occurs).
4. Wait briefly for endpoints to apply the update.
5. Verify reachability using overlay IPs (start simple, then test the real service).

Verification (how to confirm it worked)

From an enrolled endpoint (or your technician workstation, depending on your workflow):

• Confirm each member has an assigned overlay IP in the VPN network view.
• Confirm you can reach a peer by its overlay IP.
• Then verify the real objective: access the target service over the overlay IP (RDP/SSH/HTTP/etc.).

Common pitfalls

• CIDR overlaps a client LAN: routing becomes ambiguous; pick a different overlay range.
• Locked-down firewall rules: direct peer-to-peer paths may not work in some environments; ensure your policy allows Telmetra’s VPN connectivity.
• Endpoints offline: configuration can’t be applied until the endpoint is online.

When NOT to use Telmetra VPN networks

Skip (or delay) this approach if:

• You need a full site-to-site replacement with complex routing policies and multiple subnets per site.
• Your environment requires strict network segmentation that must be enforced by dedicated network appliances.
• Your org cannot allow UDP egress to the Relay (or you can’t open the required port).

FAQ

What is a remote support VPN?

A remote support VPN is an L3 overlay that assigns stable overlay IPs to enrolled computers so you can reach internal services reliably across NAT and multiple client networks.

Can one computer be in multiple VPN networks?

Yes. A single computer can participate in multiple VPN networks (each network has its own overlay addressing).

Do I need to open ports on the client firewall?

In many environments, it’s enough to allow the required outbound connectivity to Telmetra. Direct peer-to-peer paths can improve performance when permitted, but aren’t always possible in locked-down networks.

Why didn’t a new network adapter appear after I added a computer?

If the endpoint can’t apply networking changes (policy restrictions, missing privileges, or local constraints), it may receive the update but not fully activate VPN networking. Check endpoint status and your local security policy; if needed, collect diagnostic logs for support.

Is Telmetra’s VPN traffic encrypted?

Yes—VPN packets are encrypted on the Host before transport (P2P or relay-forward).

Next step

• If you’re rolling this out org-wide, start with a single VPN and 2–3 hosts to validate CIDR choice and UDP reachability.
• Then expand membership gradually and standardize naming and reasons so audit trails stay useful.