Cloud connectivity
A private, routed link between the client’s offices and their Azure, AWS or Google Cloud network, built so names resolve from both ends, failover happens on its own, and only the traffic that should cross does.
Where links like this usually break
The tunnel shows connected before the link is any use
Every cloud portal will report the tunnel as connected well before the link is any use. The status page is green, yet the office can’t open the file share, the line-of-business app times out on big reports, and the new server in the cloud can’t find a domain controller.
Most of the work is around the tunnel rather than in it: addressing, routing, name resolution, packet size and policy. Those are the places the link usually breaks, and each has a section below.
What the cloud portal says
Connected
What the office says
“The S: drive won’t open and the finance app keeps freezing.”
Both ends, before anything is built
Address ranges that don’t overlap
Routing can’t choose between two networks that use the same addresses, and overlaps are easy to create by accident. The Azure portal offers 10.0.0.0/16 for a new virtual network, every AWS region has a default VPC on 172.31.0.0/16, Google’s default network spreads its subnets across 10.128.0.0/9, and plenty of offices were set up on 10.0.0.0/8 years ago. Fixing an overlap later means renumbering servers, rules and DNS records.
So the plan covers the whole estate, not just today’s link: each office, each cloud network and its subnets, room for the next site and the next region, and blocks that summarise cleanly so one route covers a whole environment. We also steer clear of the 192.168.0.x and 192.168.1.x ranges home routers hand out, because they collide the first time someone works from home.
Built on defaults
Same range at both ends. Traffic for the cloud never leaves the office.
Planned
- Offices: 10.10.0.0/16
- 10.10.0.0/20
- Head office
- 10.10.16.0/20
- Branch
- 10.10.32.0/19
- Held for future sites
- Cloud: 10.40.0.0/16
- 10.40.0.0/24
- Gateway and shared services
- 10.40.1.0/24
- App servers
- 10.40.2.0/24
- Databases and private endpoints
- 10.40.128.0/17
- Held for a second region
Between the two ends
Two tunnels, both built, both tested
Each provider gives you a second path for a reason. An AWS Site-to-Site VPN connection comes with two tunnels, Azure VPN gateways can run active-active, and Google’s HA VPN has two interfaces. Sooner or later the provider will take one endpoint down for maintenance. If only one tunnel was ever configured, that’s an outage nobody planned for.
Where the office firewall supports it, we build route-based tunnels with BGP, so traffic moves to the surviving tunnel by itself and new cloud subnets are advertised without anyone editing static routes at both ends. Where it doesn’t, static routes are set up with failover that has been tried, not assumed.
The other common failure is a tunnel that passes every test on the day and drops hours later. IKE and IPsec settings have to agree at both ends, and some mismatches, perfect forward secrecy being a common one, only show up at the first rekey. We choose those settings deliberately from what both ends support, rather than accepting whatever the setup wizard offered.
Inside the tunnel
Packets that fit
The usual symptom is that ping works and small web pages load, but file copies stall, remote desktop sessions freeze and one screen of an application hangs every time. It looks like a flaky link, but it’s packet size.
IPsec wraps every packet in extra headers, so a full-size packet from the office no longer fits through the tunnel. Normally the sender is told to use smaller packets, but those ICMP messages are often blocked somewhere along the path, and the large packets are dropped.
We set the tunnel’s MTU and clamp the TCP maximum segment size on the office firewall to suit the cloud provider’s gateway, and on the cloud side where the platform allows it, then test with traffic large enough to prove it rather than with a ping.
A full-size packet on the office network
The same packet wrapped in IPsec
With the segment size clamped
Both ends, in both directions
Names that resolve from both ends
Plenty of cloud connectivity faults that look like network problems turn out to be DNS. Servers in the cloud need to find the client’s domain controllers to join the domain and sign users in. Office PCs need to resolve the private names of cloud resources.
Private endpoints add a trap of their own. A storage account or database with a private endpoint still resolves to its public address from the office unless the office DNS knows to ask the cloud for that zone. The traffic then goes out to the internet instead of through the tunnel, or is refused outright.
We set up forwarding in both directions with each platform’s own tools, such as Azure DNS Private Resolver, Route 53 Resolver endpoints or Cloud DNS forwarding zones and inbound server policies, with conditional forwarders on the client’s DNS servers to match. Then we check the names that matter from both ends, not just the one we happen to be sitting at.
Both ends
Only the traffic that’s needed
A site-to-site tunnel joins two networks; it shouldn’t merge them. With an any-to-any rule across the tunnel, a compromised server in the cloud can reach every PC in the office, and a compromised PC can reach every server in the cloud.
We allow what the client uses, and nothing else, at both ends: in the office firewall policy, and in the cloud’s own controls, whether that’s network security groups in Azure, security groups in AWS or VPC firewall rules in Google Cloud. Each rule carries a reason, so whoever reviews it next year knows why it’s there.
| From | To | Allowed | Because |
|---|---|---|---|
| Office PCs | App servers | HTTPS | Staff use the app in a browser |
| Cloud servers | Office DCs | DNS, Kerberos, LDAP and related directory ports | Domain join and sign-in |
| IT admin PCs | Cloud servers | RDP | Administration from known machines only |
| Anything else | Anywhere | Nothing | Denied and logged |
What we prove before handing it back
A link isn’t finished the first time it passes traffic. Before handover it goes through the things that break links like this in real use.
- Each tunnel taken down in turnTraffic carries on over the other, and comes back when it returns.
- The tunnels left up through a rekeyCatches the settings that only fail the second time the tunnel negotiates.
- A large file copy and a long remote desktop sessionShows packet size is right, which a ping never will.
- Names looked up from both endsOffice names from the cloud, cloud names from the office, private endpoints included.
- Traffic that shouldn’t cross, triedSeen to be blocked and logged, not just assumed to be.
What the client ends up with
A working connection
Between the offices and the cloud, with names resolving, the rules in place, and both tunnels in use wherever the firewall and platform allow it.
A routing and addressing plan
Every range in use and every range held back, so the next office, region or subscription slots in without a clash.
As-built documentation
Tunnel settings at both ends, routes, DNS forwarding and firewall rules, written so your team can support the link without us.
Delivered as part of your service
We deliver remotely as a white-label project, under your brand or as your named specialist partner. We quote and invoice you at a fixed price for the agreed scope, and the client and the ongoing service stay with you.
Office-end firewalls we work with: Fortinet, Palo Alto Networks, Cisco, Meraki, SonicWall, WatchGuard, Sophos, Check Point, Juniper and Huawei.
Tell us which offices, which cloud and what needs to cross, and we’ll come back with a fixed price.
Request a quote