An Exit Node is a traffic routing node on your corporate LAN that handles VPN traffic between remote users and the internal resources they are allowed to reach.

This can be a single node for simpler environments, or multiple nodes deployed for load balancing, resilience, and failover.

All plans include one exit node. Additional exit nodes can be added for capacity, redundancy, failover, or to support different sites and network segments.

Routes decide which internal networks a user can reach over the VPN—for example a specific subnet containing file servers, a lab network, or a cloud VPC.

• Per-group access to subnets (e.g. Finance vs Engineering)
• Split tunnelling where appropriate
• Clear separation between internal access and internet egress

Policies define what is allowed. Groups keep management simple by applying those policies to a set of users (and optionally devices).

• Role-based access: "Support", "Developers", "Contractors"
• Time-limited or project-limited access
• Auditable change history (who got access to what, and when)

Instead of "VPN gives you the whole network", we can allow only the specific ports needed. For example: SSH to a bastion, RDP to a jump host, or HTTPS to an internal app.

• Reduce blast radius and lateral movement
• Align access with compliance requirements
• Supports safer third-party/contractor access

Posture checks are rules about the device's security state—used to allow, restrict, or block access. Typical checks include: OS version, disk encryption, endpoint protection, and device enrolment.

This is where zero trust becomes practical: a user can be valid, but access can still be limited if the device doesn't meet your baseline.

A remote user can be granted access to one Windows server only, typically over RDP, without exposing the wider company network.

• Allow access to one hostname or IP only
• Restrict to RDP and supporting management ports
• Suitable for admins, support staff, or contractors

Users can reach an internal web application or intranet through a controlled route or proxy path, rather than being placed broadly onto the LAN.

• Expose a specific internal site securely
• Keep back-end systems hidden from general access
• Useful for HR, portals, dashboards, and line-of-business apps

Remote users can be limited to one or more file resources, such as a single NAS share, departmental storage, or a defined set of internal file servers.

• Scope access to specific servers or subnets
• Works well for SMB/CIFS-based file access
• Ideal for hybrid staff needing controlled document access

Some roles need broader connectivity. Access can be granted to the entire company network or limited to a specific internal subnet such as a finance VLAN, lab, or cloud segment.

• Supports traditional VPN-style network access where needed
• Can still be segmented by user, team, or device posture
• Useful for IT teams, power users, and migration scenarios

Developers, integrations, or support users can be allowed to reach specific internal APIs or microservices only, without access to unrelated hosts or ports.

• Restrict access to named services, ports, or application paths
• Well suited to private dashboards, back-office APIs, and service management tools
• Helps enforce least-privilege access in modern distributed environments

Remote workers can have their internet-bound traffic routed so it originates from a fixed public IP, helping with SaaS allowlists, partner access controls, and consistent outbound identity.

• Useful for staff working remotely who need a known source IP
• Supports third-party systems that rely on IP-based allowlisting
• Can be applied selectively to users, groups, or specific traffic flows