Ability to choose Gateway Agent in RDM Entries

Ability to choose Gateway Agent in RDM Entries

1 vote

avatar

We're an MSP running Devolutions Server with RDM and Devolutions Gateway 2026.3.0, evaluating Agent Tunnel for customer-site access. The feature works well — enrolment and transparent routing via advertised domains are in place. We want to raise a gap that becomes structural at our scale.

Context:
Two properties of that environment break advertisement-based routing:

  1. Overlapping RFC1918 space. Most sites use 10.0.0.0/24, 192.168.1.0/24, etc. Subnet advertisement cannot disambiguate two agents advertising the same prefix, so we don't advertise subnets at all.
  2. Shared DNS suffixes. A significant share of customers use .local, corp.local, ad.local and similar. Domain-suffix advertisement (*.corp.local) collides in the same way. Only customers with a unique AD suffix can be routed reliably today.


Request
The Gateway routing pipeline already evaluates an explicit jet_agent_id claim in the session token before subnet/domain matching (PR #1741). What's missing is a way for Devolutions Server to set it.

Concretely
Add an optional "Route via Agent" selector to Gateway Ruleset (and ideally an override at entry/folder level), listing agents enrolled on the ruleset's Gateway. When set, DVLS emits jet_agent_id in the session token so the Gateway routes through that agent regardless of advertisements.
Ideally a way to choose what agent to connect to at the entry level in RDM:


Secondary, lower priority: a way to map a synthetic per-tenant suffix (e.g. *.tenant42.tun.example) to the customer's real internal name at the agent, so entries can use unambiguous names without touching customer DNS. Optional if (1) exists.
With (1), we can keep IP-based entries per customer folder, bind the folder to a ruleset that pins the agent, and overlapping address space stops being a concern. It also gives a deterministic, auditable path per customer rather than one inferred from advertisements — useful for compliance.

df390872-e13f-49db-a3f7-793a0292772b.png

All Comments (0)