A Leased Line for the VPN? Translate the Requirement First

The proposal names a specific leased line for the office VPN, and the number arrives without an explanation. Before you sign it, split the sentence into the four requirements it is actually hiding: the physical handoff, the IP delivery arrangement, the capacity in both directions, and the support commitment behind the circuit. Run them as gates in that order, because a circuit that fails the handoff cannot be rescued by a bigger bandwidth figure. Then verify what was delivered against what you wrote down.

Translate the requirement, not the product name

IPsec protects traffic at the IP layer and leaves the carriage to whatever circuit you buy. The IPsec architecture describes how traffic is protected between peers; it says nothing about handoff type, commit rates or repair windows. Those are properties of a service contract.

That distinction is the whole reason a circuit requirement can be legitimate and still not be a VPN requirement. A gateway with only a serial interface genuinely needs a serial handoff, and that is a hardware constraint rather than a protocol one. Replace the appliance and the constraint disappears. Write each requirement in the form "the gateway needs X because Y", and reject any line that cannot be completed.

Name the handoff before you name the speed

The handoff is the physical and link-layer connection at the demarcation point: copper Ethernet, fibre with a specific transceiver, a serial interface, or something older that only exists because the current appliance has it. Getting this wrong is expensive in a way that bandwidth never is, because it usually means new hardware at both ends. A missing optic is not a capacity problem and no upgrade fixes it.

Confirm the connector, the speed negotiation and who supplies the media converter or router. Then confirm where your responsibility ends, because the demarcation point decides who is allowed to touch what when the link goes down at 03:00. Write that boundary into the record next to the circuit identifier. It is the single line that turns a support call into a five-minute conversation instead of an hour of transfer.

ip -br link show
ethtool eth0 | head -20
sudo lshw -class network -short

Confirm the IP delivery, not just the address

Ask what address or prefix the service actually delivers, and whether it is static. A circuit that hands out a dynamic address is a poor fit for a site-to-site gateway, because the peer configuration has to survive a change you did not schedule. Confirm the prefix length as well, since one address and a routed /29 are different products.

Then ask whether anything translates the address before it reaches you. A provider-side NAT or a carrier-grade NAT in front of the service breaks inbound sessions, so a gateway that expects to accept IPsec from remote sites cannot be reached. Speed does not compensate: a fast link behind a translator you do not control still cannot accept an inbound connection on a port nobody forwards.

Record who owns the router and the DNS. If the provider supplies the router, you inherit its firmware, its NAT behaviour and its idea of a default route, and every later change goes through a ticket. Have someone outside your network attempt an inbound connection to the port you expect to be reachable, because that is the only test that proves the translation story.

ip -br addr
ip route get 198.51.100.10
traceroute -n 198.51.100.10

Size capacity from the workload, in both directions

Capacity has to be described in terms of work, not in terms of a number per user. Bulk file access, interactive administration and an overnight backup each produce a different traffic pattern, and only one of them cares about sustained upstream throughput. A per-seat bandwidth figure is a sales convenience, not a model.

Estimate both directions, add the encapsulation overhead, and note whether the traffic is bursty or sustained. Then check the contract's commit rate rather than its headline rate, because a burst allowance that expires after a few seconds does not help a nightly backup. Keep the gateway's own limits in the same budget, since encryption processing and concurrent session count can bind long before the circuit does. A faster line will not fix a saturated gateway.

Pin down the operational commitments

Availability, repair response, escalation path and maintenance notification belong in writing, with the measurement method named. A headline internet rate establishes none of those properties, and neither does a marketing page that promises reliability without defining an outage. Ask how the clock starts, because a response time measured from the provider's own acknowledgement is not the same number as one measured from your monitoring alert. Those two definitions can differ by hours without anyone lying.

Record the support boundary too. If the provider's responsibility ends at a handoff that your own router terminates, the first hour of every incident goes to deciding who owns the fault, and no SLA clock covers it.

Verify the circuit against the written terms

Once the service is live, measure the properties you actually contracted for rather than the ones the installer demonstrated. Throughput, latency and loss on the real path are the evidence, and they should be captured at a time and from a location you can name. Repeat the measurement at a busy hour, not only at handover. An acceptance test run at 10:00 on a quiet day tells you very little about the link at 15:00.

iperf3 -c speed.example.net -t 30 -P 4
mtr -n --report -c 50 198.51.100.10
curl -sS -o /dev/null -w '%{time_connect} %{time_starttransfer}\n' https://speed.example.net/

Keep the results with the contract, because a performance discussion without a baseline is an argument about impressions. If a measurement misses the commitment, raise it while the evidence is fresh and while the service is still inside whatever acceptance window the contract provides. A named host in the request also keeps the TLS handshake valid, so a certificate warning is not mistaken for a failed circuit.

Finally, re-read the four gates against what was delivered. The handoff, the IP delivery, the capacity and the support terms each have a line in the record, and each line has a name beside it.