Site-to-Site VPN
Connect your office to the cloud over an encrypted path, as one network
Your office network, or one in another data centre, joins your network on the Nesnet cloud through a permanent IPsec tunnel. Nothing is installed on the cloud side, and Nesnet hands you a ready list of values for your office device.
Why now
- The application servers have moved to the cloud, but the ERP database will stay in the factory for another year. Your security team is uneasy about the app reaching the database through a port opened to the internet.
- Every morning the finance team connects to a cloud server over remote desktop, and that port is open to the internet. The connection should come only from the office, over an encrypted path.
- The office firewall was replaced, and nobody can find the old VPN settings' equivalents on the new device. The values for the new box should simply be ready, without asking anyone.
- Your reporting tools live with another cloud provider while customer data sits on Nesnet. The two environments need a large nightly transfer over an encrypted, permanent path.
- You're about to move servers to the cloud, but the applications on them have fixed IP addresses written in dozens of places. The office network needs to reach into the cloud while the move runs.
What changes
| Today | With Nesnet |
|---|---|
| Traffic between office and cloud crosses ports opened to the internet. | The two networks are joined by a permanent IPsec tunnel; traffic is encrypted end to end, and no port is opened to the outside. |
| A VPN virtual machine on the cloud side has to be built, patched and kept running. | The tunnel opens on your cloud environment's gateway; there's no separate device to maintain. |
| The far end's settings are found by trial and error, in emails between two teams. | Nesnet gives you a ready list of values for your office device, and most firewalls agree with them straight away. |
| When the tunnel drops, hours go into working out which side is at fault. | The console shows the tunnel's state and why it won't come up, so you know at once whether the problem is in the office or the cloud. |
| Moving servers means changing their IP addresses. | Layer 2 VPN stretches the office network into the cloud, so servers keep their addresses as they move. |
From today to live: how it works
- 1
Discovery call
Walk Nesnet's team through how many locations will connect, your office device and the networks on both sides. You leave knowing the tunnel layout and what drives the price.
- 2
Gather the details
Settle the office device's public IP, the subnets on both sides and the pre-shared key or certificate. On the cloud side, your gateway's public IP serves as the local end.
- 3
Define the tunnel
The tunnel is defined on your gateway in the cloud console or through the API. On the office side, Nesnet's values go into the far-end device.
- 4
Allow the traffic
An allow rule for the tunnelled networks goes on the gateway firewall. Once the tunnel is up, servers on both sides reach each other.
- 5
Watch and grow
Follow the tunnel's state and statistics in the console. When a new office or cloud joins, open another tunnel on the same gateway.
What you get
Nothing to install on the cloud side
The tunnel opens on the gateway that comes with your cloud environment, so there's no VPN virtual machine to install, license or patch. On maintenance night, the only device you think about is the firewall in your office.
A ready value list for your office device
Nesnet gives you the values to enter on your office device: IKE version, Diffie-Hellman group, digest and encryption algorithms, PFS and dead-peer detection interval. Most firewalls agree with them on the first try, so no trial-and-error emails pass between two teams.
Strong encryption from the start
A new tunnel uses IKEv2, Diffie-Hellman group 14 and SHA2-256, with AES-128 for IKE and AES-GCM-128 for tunnel traffic, and PFS switched on. You never start from a weak legacy setting, and you can show your security team the reasoning behind every value.
Work with older or different devices
If the far end needs a different set, IKE, tunnel and dead-peer detection values are chosen in a custom profile. IKEv1, IKEv2 and IKE-Flex, which picks either automatically, are supported, with a wide list of Diffie-Hellman groups and tunnel encryption up to AES-GCM-256.
Certificate or pre-shared key
Tunnels authenticate with a pre-shared key (PSK) or with an endpoint certificate validated by a certificate authority. If corporate policy forbids shared keys, you build the same tunnel with certificate authentication instead.
A key that's written once and never read back
The pre-shared key is write-only in the API and can't be read back, so once it's entered nobody can see it again through the API. The only copy stays with the team that chose it, not in front of everyone with console access.
Only the networks you pick enter the tunnel
A standard tunnel is policy-based: you list the subnets on both sides, and the tunnel carries traffic only between them. Each tunnel can hold several local and remote subnets, and the office guest Wi-Fi never reaches the cloud.
Route-based tunnels
A route-based tunnel (VTI) sets up a virtual tunnel interface and sends traffic to it with static routes. When the office gains a subnet you update a route, not the tunnel definition; Nesnet uses the same design on its own SD-WAN link.
A tunnel for every office
One gateway can hold a separate tunnel for each office, factory or remote cloud. Tunnels are enabled, disabled, re-keyed or deleted one by one in the console, so a change at one branch never touches another's connection.
Offices behind address translation
If the office device sits behind address translation (NAT), such as an ISP modem, the remote identity can be a domain name (FQDN) or an email-style ID instead of an IP. A small office without a fixed public IP can still join.
Choose who starts the connection
The cloud side can start the tunnel (Initiator), only answer the office (Respond-only) or bring it up when traffic arrives (On-demand). Whatever direction your office security policy calls for, the tunnel follows it.
A dropped tunnel comes back on its own
Dead-peer detection (DPD) polls the far end at a regular, adjustable interval and notices when the link is lost. With the cloud side as initiator, the tunnel rebuilds itself once the office internet returns, without anyone touching it.
Let the console say which side is at fault
Each tunnel shows as up, down, degraded or unknown, and if it won't come up the IKE failure reason is right there in the console. Within the first minute you know whether the office device or the cloud side is to blame, and nobody spends hours comparing logs.
Watch it with logs and statistics
Tunnel statistics are read from the console and the API, and detailed logging can be switched on per tunnel while troubleshooting. You see which step a connection attempt stalls on, and whether traffic really goes through the tunnel, without guessing.
Large packets don't get stuck
The packet fragmentation (DF bit) policy can be set to copy or clear. If file transfers or remote desktop sessions freeze on some lines because of large packets, this setting is the first fix to try, with no device swap at the office.
Tunnel rules kept apart from internet rules
Traffic through the tunnel needs its own allow rule on the gateway firewall. Opening the accounting server to the office while the internet sees only the website happens in the same table, without the two blending together.
A redundant gateway
IPsec terminates on a gateway running active-standby, so if the active side fails the service moves to the standby. That redundancy is built automatically when your gateway is created, with no separate redundancy setting for your tunnels.
Stretch your network into the cloud at layer 2
The same gateway runs layer 2 VPN in server or client mode, extending an office network segment into the cloud as it is. Servers keep their IP addresses during the move, and the fixed addresses inside applications never need editing.
Why Nesnet
No appliance on the cloud side
The tunnel opens on the gateway in your cloud environment, and traffic goes straight to your cloud network's router. There's no VPN virtual machine to install, license and keep alive.
Measured, strong defaults
A new tunnel comes with defaults measured on Nesnet's platform: IKEv2, Diffie-Hellman group 14, SHA2-256, AES-128 for IKE, AES-GCM-128 for the tunnel, PFS on. That set is handed to you as a ready list for your office device.
Nesnet runs the same design on its own network
Nesnet runs route-based, multi-tunnel IPsec as the cloud link of its own SD-WAN service. The team that sets up your tunnel is the one operating that design every day.
Tunnel, rule and address on one screen
The tunnel, the firewall rule that lets its traffic through and the public IP used as its local end all sit in the same cloud console. Changing the network never means hopping between three systems.
The cloud end is in Türkiye
The tunnel's cloud end and your servers run on Nesnet infrastructure in the Equinix Istanbul (Dudullu) and Türk Telekom Ankara data centres. Traffic from your office reaches your cloud network without a stop in a region abroad.
Example scenarios
A database in the factory, an application in the cloud
Situation
A manufacturer moved its application servers to the Nesnet cloud, while its ERP database stays in the factory for another year. The application needs the database without anything opened to the internet.
Outcome
A tunnel is built between the factory firewall and the cloud gateway, and Nesnet's values are entered on the factory device. An allow rule for tunnel traffic goes on the gateway; the two sides talk only over the defined subnets, and no database port is exposed.
A finance team closing its remote desktop port
Situation
A company's finance team reaches a Windows server in the cloud over remote desktop, with the port open to the internet. Every night the server logs show password guesses from abroad.
Outcome
A tunnel goes up between office and cloud, and the remote desktop rule is changed to allow only the office network through the tunnel. The exposed port closes, and the team keeps working from the same shortcut.
A nightly transfer between two clouds
Situation
A development team keeps customer data on the Nesnet cloud and runs reporting with another cloud provider. Every night a large transfer has to cross between them over an encrypted, permanent path.
Outcome
An IKEv2 tunnel links the two clouds, with certificate authentication. One night the tunnel won't come up, and the team reads in the cloud console that the other side's certificate had expired.
Servers moved to the cloud without new IP addresses
Situation
An organisation is moving its office servers to the cloud, but its internal applications have dozens of fixed IP addresses in their configuration.
Outcome
Layer 2 VPN stretches the office network segment into the cloud, and the servers move one at a time, keeping their addresses. When the move is done the stretch is removed, and the servers carry on in the cloud network with the same addresses.
An office replacing its firewall
Situation
A company is replacing its office firewall with another brand, and the person who knew the old VPN settings has left.
Outcome
Nesnet's ready value list is entered on the new device and the tunnel comes up on the first attempt. The settings now live in the console and the list, not in one person's memory.
Who does what
| Nesnet | You |
|---|---|
| Runs the gateways active-standby and operates the infrastructure the IPsec service depends on. | Manage the office firewall or router and enter the values on it. |
| Provides the tunnel value list for your office device. | Decide the subnets at both ends and the pre-shared key or certificate. |
| Pre-allocates a public IP to your gateway and operates internet connectivity. | Manage the allow rules on the gateway firewall for traffic through the tunnel. |
| Keep the office internet line up and running. |
Who it is for
Companies partway through a cloud move
Companies that have moved application servers to the cloud while a database, file server or production-line software still sits in the office or the factory. The two sides talk over an encrypted path, with no ports opened to the internet.
Organisations with a head office and a few branches
Organisations that want their head office and a small number of branches permanently connected to their cloud servers. Each location gets its own tunnel, all watched from one console.
Teams building a hybrid setup
Teams creating a permanent link between Nesnet and another cloud provider or their own data centre. An IPsec-capable device or service on the other side is all it takes.
IT teams running their own firewall
Teams that manage their office firewall themselves and want to choose tunnel parameters deliberately. A default set is ready, and every value can be tuned when needed.
Teams keeping IP addresses during a move
Teams that don't want to change server IP addresses while moving to the cloud. Layer 2 VPN on the same gateway stretches the office network into the cloud for the length of the move.
May not be the right fit
If you need to link many branches to each other and the cloud, with line redundancy and per-application path selection, SD-WAN is the better fit; branches join a centrally managed network rather than separate tunnels.
This service isn't for individual users connecting from home or the field; Site-to-Site VPN joins networks, not people.
If dynamic routing (BGP) between office and cloud is a requirement, these tunnels won't meet it; IPsec on the cloud gateway routes with static routes.
Under the hood
There is no separate Nesnet add-on behind Site-to-Site VPN: IPsec is a built-in, self-service feature of your edge gateway in the cloud console, with the software-defined network layer running the tunnels underneath. Customer gateways run Active/Standby, the redundant layout IPsec requires. Tunnels are managed from the cloud console and through the platform API, and Nesnet's own automation tools use the same official API. What Nesnet adds here is operations rather than code: a ready parameter list for the far end, a team that already runs route-based tunnels for its SD-WAN service, and the firewall and public IP the tunnel depends on being managed in the same place.
Building blocks
- Cloud portal and API
- tunnel definitions, self-service panel and automation
- Dedicated customer gateway
- the edge gateway that terminates the IPsec tunnel
- Redundant gateway layer (Active/Standby)
- moves the IPsec service to standby on failure
How it compares
| Option | When it is the right choice |
|---|---|
| SD-WAN | You have several branches and want line redundancy, per-application path selection and central policy instead of managing one tunnel per site. |
| L2 VPN on the same gateway | You need to stretch a network segment at layer 2, for example to move servers without changing their IP addresses; the gateway also runs L2 VPN in server or client mode. |
Technical specifications
| IKE version | IKEv1, IKEv2, IKE-Flex; default IKEv2 |
|---|---|
| Diffie-Hellman groups | 2, 5, 14, 15, 16, 19, 20, 21; default 14 |
| IKE digest | SHA-1, SHA2-256, SHA2-384, SHA2-512; default SHA2-256 |
| IKE encryption | AES-128, AES-256, AES-GCM-128/192/256; default AES-128 |
| Tunnel mode | ESP (IP protocol 50), tunnel mode |
|---|---|
| ESP encryption | AES-GCM-128/192/256, AES-128, AES-256; default AES-GCM-128 |
| PFS and SA lifetime | PFS on; tunnel SA 3600 s, IKE SA 86400 s |
| Dead peer detection | Default 60 s; adjustable 3–60 s |
| Authentication | Pre-shared key (default) or CA-validated certificate |
| Connection mode | Initiator (default), Respond-only, On-demand |
| DF bit | COPY (default) or CLEAR |
| Tunnel type | Policy-based; route-based (VTI) |
|---|---|
| Routing | Static routes; no dynamic routing (BGP) on these tunnels |
| Local endpoint | Public IP allocated to the gateway |
| Remote identity | IP, FQDN or e-mail |
| Redundancy | Active/Standby gateway |
| Billing unit | Per tunnel; L2 VPN is a separate unit |
If something breaks
If the active side of the gateway fails
The IPsec service runs Active/Standby, and if the active side goes down the service moves to the standby. This redundancy is created together with your gateway; there is nothing extra to order.
If the office stops answering
Dead peer detection probes the far end every 60 seconds by default and notices when it disappears. In Initiator mode the tunnel re-establishes itself as soon as the office side is back.
If the tunnel will not come up
When a tunnel shows DOWN, the IKE failure reason is visible in the panel. You can tell straight away whether the problem is on the office side or the cloud side, before two teams start comparing logs.
Frequently asked questions
Pricing and first steps
Pricing
Site-to-Site VPN is billed monthly, one unit per tunnel; layer 2 VPN is a separate unit. The gateway and public IP the tunnel relies on are part of your cloud environment's resources. Invoices are issued as e-Invoice or e-Archive documents.
What the price depends on
- Number of IPsec tunnels
- A layer-two VPN unit, if you stretch a network segment to the cloud
- The gateway and cloud organisation the tunnel attaches to (a prerequisite)
- The public IP address allocated to the gateway
How to get started
- 1.Tell us which offices and networks to connect using the form, or call 0800 606 1071.
- 2.The tunnel layout and price are worked out in one call.
- 3.You receive the value list for your office device, and the tunnel opens on your gateway.
Encrypt the path between your office and the cloud
Tell Nesnet's team how many locations you want to connect and which device runs in your office; you'll hear back within the same business day. Nothing is installed on the cloud side, and your office device's values arrive ready.