Staged onboarding
Start in the Lobby.
Grant access deliberately.
Lobby can be a useful label for newly enrolled devices awaiting review. With no matching allow policies, they have no permitted VPN peer connections. The label itself is not a deny rule.
Enroll, review, then assign access.
Enrolled peer, no matching peer-access allowances.
Administrator checks the device, owner, enrollment method and intended purpose.
Add the approved destination or source group. Specific policies permit only needed connections.
Every enrolled peer belongs to the mandatory All group. “No group” therefore means no custom group, not literally ungrouped. A device can belong to several groups at once.
Disable the default All → All policy before using this pattern. Review every other enabled policy too. Allowances combine: Lobby does not override permissions from All, another group, an individual resource rule or automatically assigned membership.
Set up the pattern safely.
- Create a Lobby group. Do not create a Lobby → All or All → Lobby allow policy. Review existing policies and routes that could already grant access.
- Choose the enrollment path. A setup key can auto-assign Lobby. For normal user/SSO enrollment, the pinned server applies that user’s configured auto-groups. Configure the intended user before enrollment and check any identity-provider/JWT group synchronization. This is not proof of a universal account-wide “all future SSO devices go to Lobby” switch.
- Review the new peer. Confirm device identity, owner and purpose against trusted inventory. A hostname or email alone is not sufficient proof that a device is company approved. This guide does not claim that a Community device-approval toggle enforces that review.
- Add the appropriate service groups. For example, place an approved server in Web Services and authorize Server Engineers → Web Services on TCP 22 only where SSH is needed. Keep application and OS authentication. Remove Lobby for clarity, and review all remaining memberships.
- Test both allowed and forbidden paths. Verify the intended management connection works and unrelated peers and ports remain unavailable. Check existing LAN/public paths separately; VPN policy cannot quarantine those automatically.
If every newly arriving SSO identity must enter Lobby automatically, a separately reviewed identity/group provisioning workflow may be needed. Do not assume that workflow exists in the current VPNnet Alpha.
What about DNS and controller access?
Enrollment still needs outbound connectivity to the controller, signaling and required relay infrastructure. Denying peer access is not a promise of a controller-only network sandbox, and does not block the device’s ordinary internet or LAN connections.
Private DNS records are distributed with the applicable network map. A Lobby peer is not guaranteed to receive every peer name just because DNS is enabled. DNS management, client platform integration and record visibility must be tested for the intended policy and groups.
If a device needs an existing company resolver, explicitly permit only the required resolver and DNS protocol/ports, normally UDP and TCP 53, and configure split DNS as appropriate. That is a deliberate narrow allowance, not “no communication.” DNS resolution does not grant access to the resolved service.
How VPNnet Private DNS works → · Service groups and server engineer access →
Capability checked against pinned server/client 0.81.4 and dashboard 2.95.0 source. No live group, policy, enrollment, DNS or infrastructure configuration was changed to create this guide.