AllTech
Two offices. One network.
No excuses.
When you open a second location, the shared drive stops working, the phones develop a delay, and the ERP client at the new site times out at 4 p.m. every day. That's not bad luck — it's two separate networks pretending to be one. AllTech builds the tunnel between them, adds a second circuit so it survives an outage, and monitors both so you hear about a drop from us instead of from your staff.
"It works, until it doesn't."
Most multi-site networks we inherit were built one site at a time. Someone stood up a VPN between two firewalls once, it worked, and nobody touched it again. Then a third site opened, a fiber install got delayed, an ISP swapped the modem, and the whole thing turned into a shape nobody can draw on a whiteboard. What we usually find:
A single IPsec tunnel with no failover
WHY IT HURTS One ISP outage takes the remote site fully offline — no files, no ERP, no phones.
Overlapping subnets (both sites on 192.168.1.0/24)
WHY IT HURTS The tunnel comes up but nothing routes; classic "connected but can't reach anything".
Mismatched hardware at each site
WHY IT HURTS A consumer router at the small office, an enterprise firewall at HQ, no shared policy.
Nobody monitoring tunnel state
WHY IT HURTS The tunnel dropped Tuesday night. You found out Wednesday morning from an employee.
All traffic hairpinned through HQ
WHY IT HURTS Cloud apps and Microsoft 365 take a detour they don't need.
No documentation
WHY IT HURTS Every change is archaeology before it is engineering.
"A site-to-site connection between two offices that dropped again" — this is on our list of what a normal week looks like. We fix a lot of them.
Two ideas people use interchangeably. They aren't the same thing.
Site-to-site VPN
The tunnel. An encrypted link between two networks that lets a workstation in Brigham City reach a server in Logan as if they were in the same building. Usually IPsec or WireGuard, terminated on the gateway at each end. It's a pipe. It either works or it doesn't.
SD-WAN
The intelligence on top of the pipes. When a site has two circuits — say a fiber primary and a cable or LTE backup — SD-WAN decides which traffic goes where, watches both paths for loss, latency, and jitter, and moves sessions off a degrading circuit before users notice. It also lets cloud traffic go straight out the local internet instead of hairpinning through headquarters.
Simple version: the VPN connects your sites. SD-WAN keeps the connection good.
Six things we deliver. Nothing here is subcontracted.
Site-to-site tunnels
IPsec or WireGuard between every location, terminated on business-grade gateways. Consistent addressing plan, no overlapping subnets, documented routing.
UniFi Site Magic
For clients standardized on UniFi, Site Magic builds a full mesh between sites from the controller — every site reaching every other site directly, without manually maintaining a tunnel matrix that grows quadratically.
Cloudflare Magic WAN & tunnels
As a Cloudflare Partner we can route site traffic through Cloudflare's network instead of point-to-point, so security policy, filtering, and access control apply identically at every location. Works well when sites are far apart or when remote users need the same policy as in-office staff.
Multi-WAN and failover
A second circuit at each critical site, with automatic failover on the gateway. We test failover during the install — pull the primary, confirm the tunnel and the phone calls survive it, and document the actual recovery time.
Application-aware routing
Voice and ERP traffic prioritized. Microsoft 365 and other SaaS sent out the local circuit rather than hairpinned through HQ. Backup replication rate-limited so it can't saturate the link during business hours.
Monitoring and management
Tunnel state, circuit health, and latency monitored continuously. We open the ticket when a path degrades — you don't have to notice first.
When there's no circuit to rent.
Not every site needs an ISP. If two buildings are within line of sight — a shop across the yard, a second warehouse, a leased suite across the street — a licensed or unlicensed wireless bridge often delivers more bandwidth than the fiber quote, at a one-time hardware cost instead of a second monthly bill.
We survey the path first: line of sight, Fresnel clearance, distance, interference, and mounting options at both ends. If it won't hold up in weather or through the next tree growth season, we say so before you buy the radios.
Real shapes we support.
Manufacturer, two plants + office
Production data replicating between sites overnight, ERP served from one location, tunnel failover onto a backup circuit so a shift never stops for an ISP outage.
Clinic group, four locations
One patient-records system, one identity source, identical security policy at every front desk regardless of which building it's in.
Title company, main office + satellite
Two-person satellite office with the same file access and phone extensions as headquarters, no local server to secure.
Municipality, city hall + public works + shop
Wireless bridge to the shop where there was no circuit, VPN to public works, cameras and door access reporting back to one controller.
Growing business opening site number two
Built right the first time, so site three is a repeat of a documented standard instead of a new project.
We'd rather tell you now than in month three.
A tunnel cannot beat physics. If the remote site has 10 Mbps upload, moving 200 GB of CAD files across it will be slow no matter how we configure the gateway. Sometimes the answer is a better circuit, not a better tunnel.
Failover is not seamless for everything. Active voice calls and long-running database sessions can drop during a WAN cutover. Most other traffic recovers transparently. We tell you which of your applications sit in which category.
SD-WAN doesn't fix an application that was never built for WAN. Some legacy line-of-business software assumes it's on the same LAN as its database. The right fix there is usually to relocate or publish the application, not to route harder.
Satellite and LTE backup have real trade-offs. Latency and data caps make them a viable emergency path, not a full-time primary.
Four phases, and the next site is a template.
Assess
We document what exists at every site: circuits, gateways, addressing, current tunnels, and what actually has to reach what. Usually one on-site visit per location plus remote review.
Design
An addressing plan, a hardware list, a routing and failover design, and a written cutover plan with a rollback. You see the design before anything is ordered.
Deploy
Staged and configured in our shop where possible, installed on-site after hours or on a weekend. Failover tested live before we leave.
Operate
Monitoring, firmware, config backups, and quarterly review. When you open the next site, it's a template — not a project.
Common questions
Do we need SD-WAN, or is a plain VPN enough?
If you have one circuit per site and downtime is survivable, a well-built VPN with monitoring is often the right answer. SD-WAN earns its cost when a site has two circuits, when voice runs over the WAN, or when an outage stops revenue.
Can you connect sites that use different internet providers?
Yes. Different ISPs, different circuit types, even a wireless bridge as one leg — the tunnel doesn't care as long as each site has a usable public path.
Do all our sites need the same hardware?
Not strictly, but standardizing makes support faster and cheaper. We generally recommend one gateway family across all locations, sized per site.
Does this replace our remote-access VPN for employees?
No — that's a different problem, and usually a better-solved one. Site-to-site connects networks; Zero Trust Access connects people. Most of our multi-site clients run both.
What happens when a tunnel drops at 2 a.m.?
We get the alert, not you. Depending on the fault we either fail traffic to the backup path automatically or work the ISP ticket before your staff arrives.
How long does a two-site deployment take?
Typically two to four weeks from signed design to cutover, most of it hardware lead time. Rushed timelines are possible; we'll tell you what gets compromised.
On the remote-access question, see Zero Trust Access (ZTNA).
The rest of the stack it plugs into
Firewall & Routing
The edge device and multi-WAN failover each site depends on.
Learn moreSwitching & Gateways
The wired fabric underneath, and the addressing plan that keeps sites from colliding.
Learn moreWi-Fi Design
Coverage and SSID architecture at each location.
Learn morePrivate Cloud Routing
Reach internal resources without opening inbound ports at any site.
Learn moreZero Trust Access (ZTNA)
Site-to-site connects networks; this connects people. Most multi-site clients run both.
Learn moreNetwork & Infrastructure
Structured cabling, racks, and the physical layer at every location.
Learn moreDraw us your network. We'll tell you what's wrong with it.
If you run more than one location — or you're about to — a 30-minute conversation is usually enough for us to spot the failure point. Local engineers, no sales engineer flown in from out of state.
