Connecting Company Branches Into One Network: VPN, SD-WAN or a Leased Line?

You have five branches. Each one runs its own POS system, and at the end of the day somebody sends a file over to head office — or a manager picks up the phone to ask how much of an item is left at another branch. It works, but it works late: the decision to move stock between branches is made on yesterday's numbers, and the stock count only closes once somebody has compiled it by hand.

Linking the branches into a single network is what puts an end to this. Getting there means choosing between three technical options that differ in cost and in complexity — and one decision about addressing that, if you get it wrong, throws away the whole of the first few weeks.

Start with what will cross the link, not with the type of link

Plenty of projects open with “how many megs should the line be?” before anyone has written down what is actually going to travel over it. That is back to front. Write down the load first:

• Point of sale. Very small transactions by volume, but sensitive to latency and stability rather than to bandwidth. A line on a receipt does not need a megabyte.
• Stock and price synchronisation. Batches that run at known times, and can be scheduled outside the selling peak.
• The accounting system or the ERP. How heavy it is depends on how it works — a point we come back to shortly.
• CCTV cameras. By some distance the heaviest item on the list. Streaming every camera from every branch to head office all day long is the quickest way to swamp the link and slow the till down with it. The right approach is to keep recording local, on the branch's own recorder, and pull over the link only what is asked for, when it is asked for.
• The PBX and access control. The first is sensitive to jitter; the second carries a negligible load.

The three options and what each one costs

Site-to-site VPN over the internet lines

An encrypted tunnel between the firewall at the branch and the firewall at head office, running over the internet line each site already has. Appliances in this class — FortiGate 100F or Sophos XGS 2100 — do this themselves, with no extra box.

This is the cheapest option month to month: no connectivity subscription beyond the internet lines you are already paying for. Its real cost sits in the design and configuration time, and in the monitoring afterwards.

Two practical conditions: head office needs a static public address at the very least, and the ISP has to allow IPsec traffic through. The branches, on the other hand, may have addresses that change, or sit behind NAT at the provider; in that case the branches are configured to initiate the connection towards head office, and head office receives it. That is a common situation on branch lines and does not stop the work.

Its obvious limit: no guarantee on latency. The ISP does not treat the tunnel as a separate service running over its line, so what you get is ordinary internet quality, encrypted.

The usual shape is hub and spoke: every branch points at head office, and branch-to-branch traffic passes through head office. FortiGate appliances have a capability that lets two branches bring up a direct tunnel between themselves when they need one, instead of going via the hub, and it earns its place once the branches are many and the traffic between them is heavy.

SD-WAN

SD-WAN is not a third kind of line; it is a decision layer sitting on top of more than one line. You put two links into the branch — fibre and a 4G line, say — and the appliance measures loss, latency and jitter on each of them continuously, steers each type of traffic to the link that suits it, and moves that traffic across when one of them degrades.

On licensing: on FortiGate appliances this function is part of the appliance's own operating system and is not bought as a separate licence, but steering by application type relies on the recognition signatures that come with the security subscription, and managing dozens of branches centrally from one place is a separate product. On Sophos, the same work is done through routes that pick the link based on loss, latency and jitter, along with WAN link management and failover when a link drops.

What it costs: a second line at every branch, and a longer design-and-test period. It is worth it when an hour of downtime at a branch costs more than the second line does per month — a sum you work out with that branch's own figures: what it sells in an hour against the subscription for one more line.

The leased line

Guaranteed symmetrical bandwidth from the ISP, under a service-level agreement with a known latency figure. It is the most expensive and the slowest to deliver: priced monthly according to bandwidth, route and contract term, and it needs a site survey and a cable run before it goes live.

Its clearest logic is at head office or the data centre, where the load from all the branches converges, or at a single critical branch that cannot tolerate an outage. Leasing a line for every small branch is rarely an economic decision. And in every case it does not do away with the firewall: a leased line gives you guaranteed bandwidth, not protection.

Whichever option you take, the final figure is driven by four things: the number of branches; the bandwidth you need and whether it is guaranteed or best-effort; whether there is a second line or not; and the contract term.

What the POS and stock system actually need

Before you sign off any design, put four specific questions to your POS vendor and get the answers in writing:

• Is the database central, at head office, with the branch connecting straight to it — or is there a local copy at each branch that syncs with the centre?
• If the link goes down, does the till keep selling? For how long? And what happens to those transactions when the link comes back?
• Which ports and protocols does it need? They will be opened on the firewall precisely, for that destination alone, not thrown wide open.
• Does the system run over a remote desktop session? If the answer is yes, then be aware that a link outage means selling at that branch stops, not that it is delayed.

The practical upshot: POS traffic is light in volume. Bandwidth is rarely the constraint — stability and latency are what decide whether the till feels smooth or stutters.

When a branch link goes down

Do not find out the answer on the day it happens. With a local-database design, selling carries on and only the sync falls behind; with a central design, or with remote desktop sessions, the branch stops issuing receipts altogether. The difference between the two is the difference between a technical problem and a lost day of trading.

The only test worth anything: pull the link at the pilot branch during a real selling hour, and record exactly what stopped and what the cashier did. Branches that cannot take that are fitted with a backup line on the firewall that comes up when the primary drops.

Addressing: the mistake that shows up late and is hard to undo

Every branch was installed on its own, and every router came out of its box with the same setting: 192.168.1.0/24. You reach the point of bringing the tunnels up and discover that all the branches carry the same network. The tunnel simply does not work, because the appliance cannot decide whether 192.168.1.50 is here or at the other end.

The right fix is a single addressing plan, written down and signed off before the first tunnel: a separate range for each branch out of the large private space (10.0.0.0/8), with the branch number readable inside the address itself, and a reserved range at every site for the fixed devices — the server, the POS terminals, the camera recorder, the printers — kept outside the automatic address pool.

There is an alternative some people fall back on: address translation over the tunnel, to hide the overlap. It works, but it masks the real addresses and so makes diagnosing any later fault twice as hard, and it trips up systems and protocols that carry the device's address inside their own data. Renumbering a branch today is cheaper than living with that alternative for years.

Small details that sink the rollout

• Packet size. Encryption adds a header, so the packet grows past the limit allowed along the path and is dropped if it is marked do-not-fragment. The telltale symptom: “everything works, except one report that will not open”, or a file transfer that stops at the same percentage every time. The remedy is to set the maximum segment size for TCP sessions on the firewall, a small setting that cuts short a long hunt in the wrong place.
• Name resolution and time. Decide who answers name queries at the branch, and set one common time source — a till whose clock is out throws the ordering of transactions off when they are posted.
• Rules between branches. A tunnel being up does not mean the network is open. Spell out who reaches what: the branch needs the application server, not the whole head-office network. That spelling out is what limits the spread of an infection from one branch to the rest, and it is a natural extension of locking down remote access, which we have written about before.
• Documentation. An address register, a diagram of the tunnels, and labelling on the patch panel at every branch. Whatever is not documented gets rediscovered at every fault.

Rollout order for branches that cannot stop selling

The order itself is part of the solution:

• Head office first. The line, the static address, the firewall and the server ready and tested before a single branch is touched.
• The addressing plan written down and signed off before the first branch.
• One pilot branch. Preferably the nearest and the quietest, running both the old way and the new one side by side for a full week.
• Then one branch a night, outside trading hours, with configurations prepared in advance rather than typed out on site.
• No branch is handed over until it has been tested from the till itself: a complete receipt, a sync, and a print.

We know this work from both ends. At Al Raya Market we built the branch and head-office network — the racks, terminating the cabling onto the patch panels and labelling it at both ends, connecting the switches and configuring them — alongside the software side; and the labelling there is not decoration, it is what lets any technician know which line serves which point without tracing the cable by hand. At Awlad Ragab we supplied, installed and configured FortiGate and Sophos appliances on the internet gateway, with documented traffic and filtering rules. Those two ends — labelled cabling below and a properly configured firewall above — are what any link between branches rests on.

What the decision comes down to

If the branches can take the odd outage, and the POS sells locally and syncs afterwards, then a VPN over the internet lines you already have does the job at the lowest monthly cost. If a branch going down means the till closes, then a second line with intelligent steering between the two is cheaper than the loss. The leased line belongs where the loads converge, or where an outage cannot be tolerated at all.

And before any of that: the addressing plan. It is the one item on the list that is hard to fix later.

If you would like a review of how your branches stand today and what it would take to link them, have a look at our network infrastructure services or get in touch with the details of your branches and the systems you run.