Is a Raspberry Pi enough for the office VPN? Define the work

A four-gigabyte Raspberry Pi is a machine description, not an office requirement. It may serve a handful of remote users well, and it may collapse the first afternoon somebody copies a large file over the tunnel. The memory figure cannot tell you which of those happens. Turning the purchase into an acceptance test replaces that uncertainty with a result you can defend.

Turn the question into an acceptance test

An acceptance test names the work, the conditions and the pass mark before any hardware arrives. For a VPN gateway the work is a set of concurrent activities, and the conditions are the paths and services involved. The pass mark is what a user would call usable rather than what a benchmark reports. Without all three, a number has no claim attached to it.

Write the test so somebody else could run it. That constraint alone removes most of the vague criteria that make these decisions drag for weeks. It also makes the result comparable when the next review arrives.

The outcome may justify the Pi, a different appliance, or a managed service. All three are legitimate answers to the same question. The test decides between them, and the specification sheet does not.

Write down the work, not the headcount

Separate the activities rather than counting users. Opening a web application, copying a large file and running an interactive terminal put very different loads on the same gateway. Note which of them overlap during a normal hour, because overlap is what turns three easy jobs into one hard one.

Record the direction as well. Remote users downloading from an office file server consume the office uplink, and a fast client connection cannot compensate for a constrained path at the far end.

If the tunnel also carries ordinary browsing, include that traffic in the test. Private access alone understates what the gateway will see once the office starts using it for everything.

Measure the assembled appliance

Test the version, protocol and authentication you intend to deploy. Record which packet-processing path is active rather than borrowing a benchmark from another build. Capacity depends on that path, so an observation from a different one describes a different system. The point is to measure your configuration rather than the best one available.

Include the services that will share the board. DNS filtering, monitoring or storage all compete for the same processor and memory, and a gateway measured alone is not the gateway you will run.

Watch processor activity, memory pressure, interface errors and completion times during sustained work. Keep encryption and access controls enabled throughout, since a number obtained without them describes a service nobody approved.

Decide the outage budget before the hardware

A single inexpensive gateway is a reasonable choice when its outage is tolerable and recovery is simple. Write down the accepted downtime and who can restore configuration, replace storage and revoke a lost client. Those operations decide how long an outage really lasts. None of them appear on a specification sheet.

If the administrator reaches the gateway only through that same tunnel, plan an independent recovery route. A spare board whose configuration and keys cannot be restored, and which nobody owns, is not a recovery plan.

Name the person rather than the team. Recovery that depends on a group is recovery that waits for the group to be available. The name is also what makes the plan testable.

Choose the smallest system that passes

Pick the smallest maintained system that passes the declared requirements with headroom. More memory helps when memory is the constraint, and it does nothing for a path that is already saturated. Headroom should be a stated margin rather than an adjective. Then the next upgrade has a criterion too.

Record the workload, the result and the date beside the deployment. The next capacity question then starts from evidence rather than from a specification sheet. That record is the difference between a decision and a guess.