Concurrent session count and encrypted throughput - and for remote access the session count is usually the binding constraint.

Every connected client consumes a session with its own keys and state, whether it is transferring data or idle. A platform rated for two thousand sessions supports two thousand connected users regardless of activity.

Throughput becomes the limit where users move real volumes of data - full tunnelling, video conferencing, or large file transfers - because all of it is encrypted by the concentrator.

Licensing is a third and separate limit. Many platforms license remote access clients by count, and the licensed number is frequently lower than the hardware capacity, which is discovered at the worst moment.

Size against peak concurrency rather than headcount - though the events that drive peak concurrency, such as everyone working from home at once, have proven more common than planners once assumed. Building in substantial headroom has a demonstrated payoff.

Split for capacity and user experience, full for visibility and control - and the decision should follow from where the organisation's other controls sit.

With split tunnelling, only traffic destined for corporate resources goes through the tunnel. Everything else - streaming, general web, personal use - goes direct from the device. The concentrator carries far less, and the user's experience of cloud services is better because traffic is not routed via the office.

With full tunnelling, everything traverses the concentrator, so all of it can be inspected and filtered by the organisation's controls. The costs are bandwidth, latency, and a concentrator sized for total traffic rather than corporate traffic.

The modern middle path is split tunnelling combined with endpoint protection and a cloud-delivered security service that inspects direct traffic. That gives the capacity advantage without abandoning inspection, and is now the common design for large remote populations.

Multi-factor, always - a password alone on a remote access service is not defensible.

Remote access is reachable from anywhere, so credential theft translates directly into access. Multi-factor authentication removes the great majority of that risk, and its absence is a recurring finding in incident reports.

Certificate-based device authentication adds a second dimension: the user proves who they are, and the device proves it belongs to the organisation. That prevents a stolen credential being used from an unmanaged machine.

Posture checking extends it further - confirming the endpoint has current patches, an active security agent and disk encryption before granting access, and placing non-compliant devices into a remediation network instead.

Integrate with the directory so that access follows employment status. The account of somebody who left should stop working the same day, and a concentrator with its own separate user database is where that fails.

IPsec for site-to-site, and for remote access whatever the platform supports well - increasingly TLS-based clients or WireGuard-derived protocols.

IPsec is the long-established standard for site-to-site tunnels: efficient, widely interoperable between vendors, and hardware-accelerated on most platforms. For connecting two networks it remains the default.

For remote access, IPsec clients have largely given way to TLS-based clients that traverse restrictive networks more reliably - they use the same port as ordinary web traffic, so they work from hotel and public networks where IPsec is blocked.

Newer protocols in the WireGuard family offer better performance and a much smaller implementation, and are increasingly available in commercial products.

The practical criteria are: does it traverse the networks users are actually on, is it hardware-accelerated on the concentrator, is the client supported on every operating system in use, and is the cipher suite current. Interop matters only where tunnels terminate on another vendor's equipment.

A pair or a cluster, with clients able to fail over - and the failover behaviour tested with real clients rather than assumed.

Active-passive is the simplest: two units, state synchronised where supported, one standing by. Sessions may or may not survive failover depending on the platform, and it is worth knowing which - a failover that drops every session at nine in the morning is disruptive even if the service returns immediately.

Clustering across several units gives capacity as well as redundancy, often with a load balancer or DNS-based distribution in front.

For remote access, the client's own behaviour matters as much as the hardware. Clients configured with multiple concentrator addresses reconnect automatically to a surviving unit; clients configured with one address do not, regardless of how redundant the back end is.

Geographic distribution is worth considering for large populations, both for resilience and to reduce latency.

Not for most organisations - but separating it becomes attractive at scale or where the load profiles conflict.

Most firewalls terminate VPN tunnels perfectly well, and for a site with a few hundred remote users that is the sensible arrangement: one device, one policy, one place where remote traffic is inspected on arrival.

Separation becomes attractive when the encryption load is large enough to compete with inspection for the same processor, when the remote access population is much larger than the site population, or when the architecture places remote access in its own zone for policy reasons.

A common design keeps site-to-site tunnels on the firewall - there are few of them and they carry inspected traffic - while remote access users terminate on a dedicated platform sized for concurrency.

Whichever is chosen, ensure remote traffic is subject to policy after decryption. A tunnel that lands inside the network with no inspection extends the perimeter to every home office.

Concurrent sessions against capacity, authentication failures, tunnel state for site-to-site links, and throughput - with alerting before limits are reached.

Session count trended over weeks shows the approach to capacity and licence limits before users are refused. It also shows the pattern, which is useful for sizing.

Authentication failures matter for security: a rise in failed attempts against many accounts is a credential-stuffing attempt, and it is visible here first.

Site-to-site tunnel state should be monitored per peer. Tunnels that re-establish several times a day indicate a circuit or rekeying problem that will eventually cause a visible outage.

Throughput against the platform's encrypted capacity shows whether the concentrator is the bottleneck when users report slowness - a question that otherwise gets answered by blaming the internet connection.

Forward logs centrally, and retain them. Remote access logs are among the most frequently requested records during any investigation.