Site-to-Site VPN and On-Premises Connectivity
Connect your office, data centre or a partner network to an environment over an IPsec site-to-site VPN, and what to check when a tunnel is down.
This page explains how to connect your office, data centre, on-premises servers or a partner network to your cloud environments over a site-to-site VPN (IPsec tunnel), what to send us to set up or change a tunnel, and what to check first when a tunnel is down.
When a site-to-site VPN is the right answer
A site-to-site VPN links two networks permanently: every host behind your firewall can reach the private services it is allowed to reach in one environment, and the other way round, without anyone connecting a laptop.
| You want to | Use |
|---|---|
| Let servers, a data centre or an office network talk to services in an environment | Site-to-site VPN (this page) |
| Connect to a partner, bank, payment network or another cloud provider over a private link they require | Site-to-site VPN (this page) |
| Let individual team members reach private services from their own devices | Client VPN |
| Get temporary, audited access to a database, a namespace or the cloud console | Access Requests |
A tunnel belongs to one environment. A tunnel set up for production does not make the remote network reachable from staging or development, and the reverse. If another environment needs the same remote system, either ask for a separate tunnel for it, or let the environment that already holds the tunnel expose a narrow internal API that the other environment calls. For regulated counterparties, such as banks or payment networks, the second option usually keeps your audit boundary cleaner.
Who does what
| Who | |
|---|---|
| Deciding what should connect to what, and agreeing it with any partner | Your team |
| Your firewall or VPN appliance: tunnel configuration, local routes, local firewall rules | Your team or your network provider |
| The cloud side of the tunnel: VPN gateway, routing into the environment, security rules | CTO2B |
| Allowing tunnel traffic to reach the specific managed data services it needs | CTO2B |
| Coordinating the cut-over window and testing together | Both |
Before you ask
Have these ready. Most delays come from a missing detail, and from the two sides picking different crypto settings.
Addressing
- The public IP address of your VPN device (the peer), for example
203.0.113.10. It must be static. - The private address ranges (CIDRs) on your side that need to reach the environment, for example
192.0.2.0/24. - Which services in the environment your side needs to reach, and on which ports — for example a database, or an internal API. Access is opened for these, not for the whole network.
- Whether services in the environment need to open connections towards your side as well (bidirectional), and to which hosts and ports.
Your ranges must not overlap the environment's own address ranges. Raise a request for the environment's CIDRs before you commit to a design. If an overlap cannot be avoided, say so in the request, because it needs address translation (NAT) on one side and that changes the design.
Tunnel parameters
- The make and model of your device, such as a firewall appliance or a cloud VPN gateway at another provider.
- IKE version: IKEv2 is preferred where both sides support it.
- Phase 1 (IKE) and phase 2 (IPsec) proposals: encryption (for example AES-256), integrity (for example SHA-256) and Diffie-Hellman group (for example group 14 or higher).
- Routing: dynamic (BGP) with your private ASN, or static routes. BGP gives automatic failover when a connection has more than one tunnel; static routing is simpler for a single device.
Pre-shared key
Do not paste a pre-shared key into a request, a ticket comment or a chat message. Say in the request that you need to exchange one, and we will agree a secure way to pass it.
Request a new tunnel
- Raise a request in your dedicated Slack channel titled with the environment and the remote side, for example
Site-to-site VPN: production to head office. - Include everything from Before you ask, and whether a deadline is driven by a partner.
- Exchange the pre-shared key through the secure route we agree with you.
- We configure the cloud side and send you back the cloud peer IP addresses and the environment ranges your device should route to. If the connection has more than one tunnel for redundancy, configure every one of them on your device.
- Configure your side with exactly the same proposals and ranges, then tell us it is ready.
Change an existing tunnel
Raise a request for any of these, and name the tunnel and environment it affects:
- New or replacement firewall appliance. Send the new device's details and its public IP address, even if the IP is unchanged. Treat this as a planned change: agree a time window with us, keep the old configuration ready to roll back, and have someone from your network team available during the window.
- New subnets on either side. Send the new CIDRs and the services they need to reach. Both sides must add them — with static routing, and with policy-based tunnels, a subnet that is added on only one side does not pass traffic.
- New peer or new partner. This is a new tunnel, not a change; follow Request a new tunnel.
- Moving from static routing to BGP, or the reverse. Include your ASN, and say whether address translation is involved.
A change that briefly takes a tunnel down should be scheduled. Say in the request if the tunnel carries production or partner traffic, so we can agree the window with that in mind.
Test the tunnel
- Start traffic from your side first — for example a connection from a host in your range to the service and port you asked for. Some cloud VPN gateways wait for the remote side to start the negotiation, so a tunnel can show as down until your side sends traffic.
- Check that your device shows phase 1 and phase 2 as established for every configured subnet pair.
- Test at the application level, not only with
ping: ICMP may be blocked even when the service port is open.
# from a host on your side, test the port you asked us to open
nc -vz <service-address> <port>- Tell us the result. We confirm traffic arrives on the cloud side.
If the tunnel is down
Check these on your side first — they are the most common causes:
- Your device's public IP changed, for example after a firewall or internet line replacement.
- Proposals no longer match after a firmware upgrade or a new appliance: compare IKE version, encryption, integrity and DH group on both phases.
- Only one of several tunnels is configured, and the cloud side switched to another one during its own maintenance.
- Subnets differ between the two sides, so phase 2 fails for some ranges while others work.
- Your local firewall rules or routes do not send the traffic into the tunnel, or drop the return traffic — for example a firewall that allows the tunnel but blocks a specific application port.
- Dead peer detection or an idle timeout closed the tunnel and nothing is sending traffic to bring it back.
If the tunnel is up but one application cannot connect, the cause is usually a firewall rule on one side or a service that was never included in the request — send us the source host, destination and port.
Still having issues?
Raise a request with the environment, the tunnel name, your device's public IP, the time the problem started, what your device reports for phase 1 and phase 2, and any recent change on your side. If production or partner traffic is down, follow How to Raise a Sev-1 Incident.
Related articles
- Client VPN — VPN access for individual team members' devices
- Network Policies — which workloads can talk to each other inside an environment
- Access Requests — temporary, audited access to databases and namespaces
- Connect to a Database
Updated 26 days ago