Choose your view
Technical detail, implementation notes, and deployment considerations.
Technical details for remote access
Architecture, controls, and implementation details.
This page is for IT teams, consultants, and technical buyers who want the deeper picture before they sign off on a deployment.
At a glance
Core model
Private networking with policy-driven access controls.
Control plane
Identity, groups, device posture, and routing rules.
Ops model
Managed by Access 403 with ongoing support and monitoring.
Why this is different
Traditional VPNs are a poor fit for many modern branches.
Traditional VPNs were designed to give users access to an entire network. That becomes awkward when a site has no fixed IP address, or when the business no longer has a public IP to work with because IPv4 space is scarce and expensive.
Access 403 CONNECT works without a fixed IP, which simplifies deployment and avoids unnecessary cost. For branches where internet access is controlled by a third party, setting up a traditional VPN server is often almost impossible. CONNECT avoids that problem because the branch does not need to expose a public VPN endpoint.
The practical outcome is the same as the business version: authorised people reach only the systems they need, while the rest stays private.
Security properties
PFS
Session keys rotate regularly for perfect forward secrecy.
MFA
Authentication can be tied to the identity provider.
Least privilege
Policy rules limit access to approved systems only.
Private by default
No broad public exposure is required for branches.
Supported environments
The access model works across mixed user devices and Branch Gateway Appliances.
Access 403 CONNECT can be deployed across common endpoint platforms, server-side peers, and Branch Gateway Appliances so remote access and LAN reachability can use the same private-network policy model.
Windows
Suitable for office users, technical staff, and remote workers.
macOS
Useful for executives, sales teams, and mobile laptops.
Linux
Works well for admin workstations, engineering laptops, and servers.
Browser access
Keeps web-based internal portals reachable through the same access controls.
Servers
Can sit behind private rules instead of being exposed directly to the public Internet.
Branch Gateway Appliances
Bridge office networks and remote users with tightly scoped routes.
Gateway access to LAN
A Branch Gateway Appliance can publish only the approved LAN ranges needed by the business. That keeps internal file shares, printers, scanners, NAS devices, and local business applications private while still reachable to authorised users and services.
Network architecture
What talks to what, and where the traffic actually goes.
A clear architecture separates the control plane from the traffic plane. This makes it easy to see which components handle identity, policy, and coordination, and which components carry encrypted business traffic.
Control plane
Handles identity, policy, and coordination. It is not the business data path.
Data plane
Carries encrypted traffic between approved peers and private resources.
Relay fallback
Used when direct peer-to-peer connectivity cannot be established.
Posture checks
Access can be conditioned on the device and connection context.
Posture checks let access control rules look beyond user identity. The decision can also include client version, operating system, geographic origin, peer network range, and running process state.
Client version
Restrict access to approved client versions.
Country and region
Allow or block access by geographic origin.
Peer network range
Match approved or blocked IP ranges on desktop and server peers.
Operating system
Apply rules based on the device operating system or kernel version.
Process
Use running-process checks to require or block specific software.
Policy timing
Checks run when a peer connects or logs in, not continuously throughout the session.
On mobile platforms, local network range checks are limited because the client cannot enumerate local NIC addresses in the same way as desktop systems. Public IP-based rules remain usable on every platform.
Spec at a glance
Technical validation points.
Deployment
Self-hosted, managed by Access 403
Identity
SSO, MFA, groups, device-aware access
Policy
Least-privilege rules per user and device
Connectivity
Private access without exposing public endpoints
Operations
Monitoring, support, and ongoing maintenance
Discussion points
Encryption, resilience, and future security roadmap
Crypto deep dive
The exact primitives the docs call out.
WireGuard data plane
- Symmetric encryption: ChaCha20.
- Authentication: Poly1305, using the RFC 7539 AEAD construction.
- Key exchange: Curve25519.
- Hashing: BLAKE2s.
- Key derivation: HKDF.
- Handshake: Noise_IKpsk2_25519_ChaChaPoly_BLAKE2s.
- Transport: UDP.
What matters operationally
- WireGuard rotates session keys regularly, which gives perfect forward secrecy.
- The peer keeps private keys locally; the private key never leaves the machine.
- Relay traffic is used only when a direct peer-to-peer path cannot be established.
- Signal messages are point-to-point encrypted, so the relay/signalling path cannot read payloads.
Deployment checklist
A practical rollout usually starts here.
Confirm the sites, users, and systems that should be reachable on day one.
Connect the identity provider and define MFA, groups, and access policies.
Install the client or connector on endpoints, branches, and servers as required.
Validate routing, service reachability, logging, and policy enforcement before rollout.
Decide whether the customer wants a managed rollout, a handover, or an ongoing support arrangement.