You have just opened a second office and someone has asked how to connect it to the first one. In most Australian SMEs in 2026 the correct answer is that you do not connect them at all. Both sites get their own internet service, both reach the same cloud services independently, and there is no tunnel between them.
A site-to-site link is not a default. It is a specific answer to a specific dependency, and if you cannot name the dependency in one sentence, you do not have one.
The ladder, in order of cost and complexity
There are four honest options and they are not equally likely to be right.
Option one: nothing. Two independent sites, each with its own internet connection, firewall and wireless. Identity, email, files, phones and line-of-business applications are all cloud services that both sites reach over the public internet. Nothing at site B depends on anything at site A.
Option two: a site-to-site VPN. An encrypted tunnel between the two firewalls so that devices at one site can reach devices at the other by IP address. Cheap, well understood, and the source of most of the problems in this article.
Option three: SD-WAN. Software-defined WAN, which in practice means a managed overlay that builds and monitors tunnels automatically across whatever underlying links you have, steers traffic by application, and fails over between links when one degrades. Both major SME platforms include it: Ubiquiti’s Site Magic in UniFi Site Manager automates tunnels between UniFi gateways, and Cisco Meraki’s Auto VPN does the same across the Meraki dashboard, with the application-aware path selection and cellular failover behaviour sitting under the Secure SD-WAN Plus licence edition.
Option four: a carrier-provided private link. A Layer 2 or Layer 3 service bought from a carrier that joins the two sites as if they were one network, with a contractual service level attached. In Australia this generally sits on dedicated fibre, of which nbn Enterprise Ethernet is the wholesale product, delivered over point-to-point fibre with symmetrical speeds. The carrier owns the path and the fault.
When each one is actually justified
Take option one, nothing, unless you can name the dependency. This is right for the large majority of professional services, retail, health and trades businesses opening a second location in 2026, because their entire working set is already in Microsoft 365 or Google Workspace. Two independent sites is not a compromise. It is a more resilient design than a hub and spoke, because a failure at head office does not take the branch offline.
Take option two, site-to-site VPN, when a small number of specific systems live at one site and are needed at the other. A practice management server, a CAD or drawing store, a line-of-business database, a legacy application that has to be on a LAN. The tunnel is justified by named systems and it is sized around those systems, not around everything.
Take option three, SD-WAN, when you have three or more sites, or when the link genuinely matters. The value is not the tunnel, it is not having to build and maintain each tunnel by hand, and having a console that tells you which link is degraded before staff do. If you already run UniFi or Meraki across both sites, you effectively have this available already, so the question is only whether to turn it on. Where SD-WAN earns its keep is failover: two internet services at each site with automatic path selection turns a carrier outage into a slow morning rather than a closed office.
Take option four, a carrier private link, only when you have a real-time dependency with a contractual consequence. Voice or video that must not degrade, a clinical or manufacturing system with a latency requirement, a data replication obligation with a recovery time objective you have committed to in writing. Note that the relevant part of the purchase is the service level rather than the bandwidth. nbn Co lets providers add enhanced service levels to business services, defined across an operational period (the hours during which faults can be worked), a response time, and a rectification time for faults within nbn’s control. That is what you are buying. Bandwidth you can buy anywhere.
Before you price any of this, check what nbn technology serves each address, because the two sites may be on completely different technologies with completely different upload capability, and that alone can settle the design. In the outer east and the Dandenong Ranges in particular, the address determines the option set more than the budget does, which we cover in business internet in the outer east.
The real problem is identity and file access, not the tunnel
Businesses ask how to connect two offices when the question they actually have is how someone at site B logs in and opens a file that someone at site A created. Those are different problems and only one of them is solved by a network.
Identity has to be single, and it does not care where the person is sitting. One directory, one account per person, one set of multi-factor authentication and conditional access rules, applied consistently at both sites. If site B was set up in a hurry with its own local accounts, or its own tenancy, you have created two of everything: two joiner processes, two leaver processes, and one account you will forget to disable. In a Microsoft environment this means Microsoft Entra ID as the single authoritative directory with Conditional Access doing the policy work, and in a Google environment it means single sign-on configured at the Workspace level. Whichever you use, the answer is one directory, not one per building.
File access is where the tunnel gets built for the wrong reason. If both sites work out of SharePoint, OneDrive or Google Drive, there is nothing to connect: both sites reach the same service over the internet and the local cache on each laptop does the rest. If there is a file server at head office, a VPN will make it reachable from the second site and it will be miserable to use, because opening a large file over a WAN link is not the same experience as opening it over a LAN. The correct fix is almost always to move the files to cloud storage, not to buy a bigger tunnel. Do it before you open the second site if you can.
Whichever way the files go, they need to be backed up independently of either site, and you should know where your data actually lives before an audit or a client security questionnaire asks you.
Printing and phones: two small problems with different answers
Printing is not a WAN problem and should never be one. Nobody at site B should print to a printer at site A. Each site has its own printers, and the only thing that needs to be central is the print management and driver deployment, which modern cloud print services and endpoint management handle without any site-to-site connectivity. If your current design routes print jobs across a tunnel, that is a leftover from a print server that should have been retired.
Phones are genuinely easier across sites than within one site. A cloud or hosted phone platform treats both offices as extensions of the same system, with internal extension dialling, shared call queues, a shared receptionist and one set of numbers, and none of it depends on a link between the buildings, because both sites register to the platform independently. This is the single strongest argument for getting off any phone system with physical dependency on a building before you open the second site, and the options are compared in choosing a business phone system.
What phones do require at each site is a decent upload path and quality of service configured locally. Voice quality problems at a branch are nearly always a local internet or local network issue, not a distance issue.
“The second site feels slow” is almost never the second site
This complaint arrives within a month of opening and it is worth knowing what it usually turns out to be, because the reflex fix (buy more bandwidth) almost never works.
- All internet traffic is being hairpinned through head office. Someone built the tunnel as a default route so the branch would inherit head office’s firewall and filtering. Now every Teams call, every web page and every cloud file request at site B travels to site A and back out, adding latency to everything and limiting the branch to head office’s upload speed. This is the single most common cause.
- DNS is pointing at a server at the other site. Every lookup crosses the tunnel. If the tunnel wobbles, the branch appears to lose the internet entirely even though its own connection is fine.
- A file server at head office is being used as if it were local. See above. Bandwidth does not fix latency and file protocols are latency sensitive.
- Head office’s upload speed is the ceiling. If site A is on an asymmetric service, every branch user is sharing that upload. This is why the head office link, not the branch link, is usually the one that needs upgrading.
- It is not the WAN at all, it is the wireless. Access points placed by eye in a new fit-out, or a single access point covering a floor plate it cannot cover. Test with a laptop on a cable before you blame the link.
Diagnose in that order. The number of times the answer has genuinely been “the branch needs a faster internet service” is much lower than the number of times it was assumed.
Do not build something that needs a network engineer to change
This is the constraint that should shape the whole design, and it is the one that gets ignored because the person building it is comfortable with complexity.
A two-site network in a 40-person business will be modified by whoever is available on the day: a new VLAN for a camera system, a firewall rule for a new application, a subnet change because someone bought a new appliance. If those changes require reading a routing table, the business is now dependent on one person or one provider, and every change becomes a ticket with a lead time.
Three rules keep it maintainable:
- Use non-overlapping, obvious IP addressing from the start. Site A on one clearly numbered range, site B on another, with room to add site C. Two sites that both use 192.168.1.0/24 cannot be joined without renumbering one of them, and renumbering a live site is a weekend nobody enjoys.
- Keep both sites on the same platform and the same management console. Whatever you pick, pick one, so that a change looks the same at both sites. This is a real argument in the platform you choose for each site, and it is why the automated overlay options are worth more than their feature lists suggest: they generate the tunnel configuration rather than asking a human to.
- Write it down. The addressing plan, the tunnel endpoints, the firewall rules and why each one exists, the circuit IDs and carrier account numbers for both sites. If it is not written down where the next person can find it, the design is only as durable as one person’s memory.
The direction this is all heading, and why it argues for doing less
The reason “connect nothing” is a defensible answer in 2026 and would not have been ten years ago is that the security model has moved. Access decisions are increasingly made on identity, device compliance and context rather than on which network a device is plugged into, which is the premise behind SASE and zero trust network access as a replacement for the VPN. In that model, a tunnel between two buildings buys you very little, because being on the network is no longer what grants access to anything.
Practically, that means the money is better spent on identity and endpoint security than on the link. A second site with strong conditional access, managed devices and cloud file storage is more secure and easier to run than two sites joined by a flat tunnel, where a compromise at the branch reaches head office because the firewall between them was configured to allow everything.
A short decision path
Ask these in order. Stop at the first yes.
- Is there a system at one site that people at the other site must reach directly by IP? If no, connect nothing. Give each site its own internet service and its own firewall, and finish.
- Is it one or two named systems? Build a site-to-site VPN scoped to those systems only, not a default route, and plan to retire it when the systems move to cloud.
- Do you have three or more sites, or does an outage at either site cost real money? Use the SD-WAN capability you already own in your network platform, with a second internet service at each site for failover.
- Do you have a real-time dependency with a written recovery obligation? Buy a carrier private link with enhanced service levels, and buy it for the service level.
Most businesses stop at one. Some stop at two. Very few genuinely need four, and the ones that do usually know why.
If you are opening a second site in the next few months, the connectivity order and the identity design are the two things worth getting right before anything is installed, and both have longer lead times than people expect. Call TechAssist on 1300 028 324 or get in touch at https://techassist.au/contact/ and we will map the honest option for your two addresses. If the second site is also a relocation, work through the office move runbook alongside it.