The access network: nodes, groups and routing rules
Applies to: SimpleTwo 1.0.13 and later, directory 1.3.10, agent 1.0.5 · Checked: 29.10.2026
Besides messaging and calls, SimpleTwo hands clients an access network: a tunnel into corporate resources and egress in a chosen location. It is managed by three things — nodes, gateway groups and rulesets — and by one property: the ruleset is signed, and the client verifies it.
1. What it is made of
| Thing | What it defines |
|---|---|
| GEO (location) | the country or site of egress; the code is created first, then the node is installed |
gateway node | the machine accepting tunnels. Keys are generated on the node, only the public one leaves it |
| Gateway group | what those nodes give access to, and on which transports they listen |
| Ruleset | what to do with which traffic |
| Profile | which ruleset a directory group receives |
All of these are directory objects, as Exchange keeps its settings in Active Directory: a GEO and a gateway group are sites, a node and an external gateway are services, a ruleset, a list and a profile are policies. The console edits them on the same screens as before; the coordinator keeps only what describes the fleet's work rather than its configuration — the nodes' liveness, load, deployment and updates. Each entity's identifier is its directory object's.
2. Gateway groups
A group answers "where can one get through these nodes":
- A corporate group may carry a destination allowlist (
served_cidrs,served_domains): its gateways forward traffic only there and drop the rest. Such a group is a controlled entrance into the corporate network rather than an open tunnel. An empty list means an ordinary corporate egress, bounded only by membership. - A host map (internal name → address) travels to the client as DNS records: internal addresses work without editing corporate DNS on the device.
- An external gateway is a VPN gateway of your own (a FortiGate, or any IKEv2 dial-up) that the client reaches over IPsec beside the tunnels to SimpleTwo's gateways. It lives in a corporate group of its own and leads into that group's networks — see External VPN gateways.
- Transports are the protocols every node in the group listens on simultaneously. The client receives one descriptor per enabled transport and fails over between them. An empty list means the single default transport, Reality-TCP on 443.
If no authorised group serves an address, the client does not know where to send it. That is what a call that connects and stays silent looks like: the media node's address is private and not in the allowlist — see Calls.
3. Rulesets and lists
A ruleset is ordered and versioned; the first matching rule wins and unmatched traffic gets
the default action. Actions: tunnel → GEO, prefer → GEO, direct, block.
Match lists are what a rule recognises traffic by:
| Kind | Contents |
|---|---|
domain | domain suffixes |
ip | CIDR ranges |
asn | autonomous system numbers |
A list is either your own (maintained by hand) or refreshed from a URL, in which case a button updates it. Built-in lists ship with the product and are refreshed on upgrade; as soon as you edit a built-in list, its auto-refresh stops — your version wins.
Small and large lists. A list of up to 64 KiB of entries is kept in its directory object itself. A larger one — a registry export of tens of megabytes, say — is kept as a file beside the object, as a Group Policy's template lies in SYSVOL beside its container; a file is up to 64 MiB. A list that shrinks leaves no file behind. For the administrator nothing differs: the same screen, the same refresh button.
Preview, history and rollback. Before saving, a ruleset can be viewed exactly as the client will receive it; it has a version history and a rollback — every write of a directory object keeps the version it replaced. This is the first thing to reach for after "the internal portal stopped opening after lunch".
4. The signature
A ruleset is signed with Ed25519. The signature covers the rules, the defaults and the content hashes of every list they reference — so a list cannot be swapped without breaking it.
The signing key is derived from the coordinator's secret, so there is no separate private key to keep and the client needs only the public one. A practical consequence: changing the coordinator's secret changes the signature. Clients whose verification fails keep working, show the user "routing not verified", and report it to the administrator.
5. Profiles: who gets which ruleset
Which ruleset and which gateway groups a person gets is decided by a routing policy in the directory — the way an AD Group Policy is: it is linked to everyone or to a directory group, and each link has an order. A person in several groups gets the link with the smaller order; a group's link overrides the one for everyone. Edited in the console under Secure Access → Groups → profile — a row per link: to whom, the order, the ruleset, the allowed gateway groups.
Employees, partners and guests are the directory's built-in groups Simple Users, Simple Partners and Simple Guests: link a profile to them to route them differently.
Somebody with no matching link has no profile: the tunnel refuses them with "no access policy". No default ruleset is created — on a new installation, link a profile yourself. This is visible immediately and is fixed by a link, not by debugging the client.
The profile a client receives is the effective ruleset plus the list of gateways available to it.
The tunnel profile (uTLS fingerprint, QUIC blocking, DNS, MTU, mux and the client's other
knobs) works the same way: a policy for everyone, group policies, the person's own layer and their
device's; the nearer overrides the farther, key by key. Edited under Secure Access → Clients →
Client tunnel profile (for a device, username/device); the personal layer on the person's card.
6. Nodes in the directory
A node is like a computer joined to an AD domain. The coordinator installs and updates the agent, while the host is known to the directory: when a node is enrolled, the coordinator makes a server object named after the machine and puts the host's public key on it; the private key never leaves the machine. A gateway has its own service account with its own key, linked to the server it runs on, its gateway group and its GEO.
The gateway, under its own service account, reads its object, group and GEO in the directory and assembles its xray configuration itself — as a computer applies the Group Policies it receives. There it also reads its admitted set — the credentials of its clients' live sessions. The directory keeps the tunnel sessions; if it is briefly unavailable, the gateway keeps working with the last set. Liveness, load and the transports' state the gateway still reports to the coordinator through the agent.
A node enrolled before per-node keys keeps getting its configuration from the coordinator as before; re-enrolling it moves it to the directory.
7. Through the tunnel, or directly
In Features each service has not only a switch but a mode:
| Service | Modes | Default |
|---|---|---|
| Messaging | direct / vpn | direct |
| Conferencing | direct / vpn | vpn |
| Access network | — | always on |
| Skills and recognition — Messaging Plus only | on/off | off |
| Federation | on/off | off |
vpn means the service is reachable only through the tunnel. That is a decision about the
perimeter rather than about convenience: in that mode a person without a tunnel cannot read their
messages.
8. Diagnostics
- Probe a gateway from the console.
- Node metrics and reports — traffic and state.
- "An internal resource does not open" is diagnosed in this order: does the person have a profile → which rule matched (ruleset preview) → does the group serve that address → does the node answer.
Next
- Connecting to the corporate network — what the user sees
- External VPN gateways — a FortiGate or another IKEv2 gateway beside SimpleTwo's
- Calls and conferences — why media depends on the allowlists