Unit 3.6: Hybrid Connectivity: VPN, NAT, and Cross-Connect

Introduction

Three of FinCorp's hardest networking requirements are about reaching across a boundary: an encrypted site-to-site link from the corporate data centre into the cloud during migration, a way for private cloud servers to pull patches and reach SaaS endpoints without ever owning a public IP, and a low-latency private path between two of FinCorp's own VDCs. The platform answers each with a distinct product, and the products do not overlap: a VPN Gateway encrypts traffic over the public internet, a NAT Gateway gives private servers outbound-only egress, and a Private Cross-Connect joins VDCs on a private LAN. This unit establishes when each applies and its non-negotiable constraints, then builds the two that carry the migration: a VPN tunnel and a NAT Gateway for private egress.

1. The Three Hybrid Primitives and How to Choose

The selection collapses to one question per requirement: are you crossing the public internet encrypted, leaving a private network outbound, or joining two private networks privately?

VPN Gateway establishes a secure, encrypted site-to-site connection between an on-premises network and your VDC private LANs over the internet, using either IPSec tunnels or WireGuard peers. It is the migration workhorse: it connects a corporate data centre or branch office to cloud resources for the duration of a cutover and beyond. Its defining constraints are firm. The IPSec implementation is IKEv2 only; IKEv1 is not supported, so any legacy peer configured for IKEv1 must be reconfigured. Authentication for IPSec is by pre-shared key (a 32-character PSK is recommended). High availability is an active-passive option you couple with the tier: enabling it runs the gateway in active-passive mode so a redundant tunnel automatically takes over on failure, and that HA pair presents a single public IP, so the on-premises peer always targets one address. Tunnel and gateway IP addresses are IPv4 only, though the payload carried across the tunnel can be dual-stack IPv4 and IPv6. BGP is not offered; routing is static, defined by the network CIDRs you list on each side of the tunnel. Per-tunnel throughput is up to 1 Gbps, and the tier sets the ceilings on LANs and tunnels.

NAT Gateway is the egress path for private workloads. It lets VMs inside a VDC reach the internet without any public network interface: the gateway performs Source NAT so private VMs can initiate outbound connections and receive the responses, while inbound connections initiated from the internet are refused. This is the honest shape of the product and the most common point of confusion: NAT Gateway is SNAT-only, with no DNAT and therefore no inbound port forwarding. If you need inbound, that is a load balancer's job, not the NAT Gateway's. It requires a reserved public IPv4 address (it can carry multiple), supports up to six private networks per gateway, and is highly available, run across multiple availability zones in a region. Its documented uses are precisely the private-server outbound cases: pulling OS and software updates, reaching NTP, letting the Backup Service reach private VMs, and restricting outbound access to specific trusted endpoints.

Private Cross-Connect joins multiple VDCs over a private LAN with no public exposure, for safe data passage with lower latency and better performance than routing between them over the public internet. Its constraints are categorical: the participating VDCs must be in the same region and under the same contract; cross-region and cross-contract are not supported. All NICs on all connected VDCs must share the same IP range, an address may not be used in more than one instance, and each LAN can belong to only one Cross-Connect. Bandwidth is comparable to a normal private NIC, and the feature itself carries no charge. A LAN is wired into a Cross-Connect by setting the connection's identifier on the LAN resource, and a Cross-Connect can only be deleted once it has been disconnected from all LANs and VDCs. Where two sites need a dedicated carrier-provided line rather than a same-region VDC-to-VDC link, that is a separate Cloud Connect dedicated-line service, distinct from Private Cross-Connect; this unit's builds use the VPN and NAT primitives.

Requirement	Product	Defining constraint
Encrypted site-to-site link over the internet (e.g. on-prem to cloud during migration)	VPN Gateway	IKEv2 or WireGuard, no IKEv1; static routing (no BGP); active-passive HA on one public IP
Private servers need outbound internet (patches, NTP, SaaS, backup) with no public IP	NAT Gateway	SNAT-only, no inbound; reserved public IP required; up to six private LANs
Join two of your own VDCs privately and fast	Private Cross-Connect	Same region and same contract only; shared IP range; one Cross-Connect per LAN

During a migration cutover these three play complementary roles: the VPN Gateway carries the encrypted bridge between on-premises and cloud while workloads move; the NAT Gateway lets migrated-but-not-yet-public private servers reach the internet for agents, patches, and backups; and a Cross-Connect privately stitches together VDCs that must exchange data within the region. None substitutes for another.

DCD Implementation Walkthrough

You will build the two primitives that carry FinCorp's cutover: an IKEv2 IPSec VPN Gateway with one tunnel back to the corporate data centre, and a NAT Gateway giving the private application LAN outbound-only egress. Both reuse the three-LAN VDC from Unit 3.1.

Build goal: Provision a VPN Gateway tunnel; provision a NAT Gateway for private egress.

Prerequisite: reserve public IPs first

Both gateways consume a reserved public IPv4 address, and the address must be reserved in the same location as the gateway before you create it. Using IP Management, reserve one IPv4 address for the VPN Gateway and one for the NAT Gateway, in the region where the VDC lives. A DHCP-assigned address will not work; these gateways select from reserved addresses only.

Steps - VPN Gateway and IPSec tunnel (in the Data Center Designer):

From the VPN Gateways page, click Create VPN Gateway.
In Properties, set a Name, the Location (matching the reserved IP and the VDC), and select the reserved public IP Address from the drop-down. (The IP and the data centre must be in the same location.)
In Tier, choose the tier sized to your LAN and tunnel needs (Standard allows up to 5 LANs and 10 tunnels/peers; Enhanced up to 10 LANs and 20; Premium up to 15 LANs and 30). Select the High Availability variant of the tier to run active-passive: redundant tunnels automatically take over during a failure, minimising downtime, behind the single gateway IP.
In Protocol, choose IPSec. The IKE Version is IKEv2 by default (there is no IKEv1 option to select; this is the only supported IKE version).
In LAN Connections, add the private LAN that will use the gateway. Choose a private IP for the gateway from the LAN's CIDR; the recommended range is .2 to .9, and the address must not already be in use in the VDC. (Note: a VPN Gateway cannot attach to a LAN directly managed by Managed Kubernetes; attach an additional node-pool LAN if that is your target.)
Click Save. The gateway STATE shows PROVISIONING, then AVAILABLE. You can begin creating the tunnel while it is still provisioning.
On the VPN Gateways page, click Create Tunnels for this gateway. Enter a tunnel Name, the Remote Host (the on-premises peer's public IPv4 or FQDN), and the PSK under Authentication (method PSK; use a strong 32-character key).
Set the Initial Exchange (IKE_SA_INIT) phase: pick a Diffie-Hellman group, an Encryption Algorithm, and an Integrity Algorithm from the offered lists (for example DH group 16-MODP4096, AES256, SHA256), with an IKE lifetime between 3600 and 86400 seconds.
Set the Child SA (ESP) phase: choose the matching Diffie-Hellman group, Encryption Algorithm, and Integrity Algorithm, with an ESP lifetime between 600 and 14400 seconds.
Define the routed networks: Cloud Network CIDRs (the IONOS-side subnets allowed across the tunnel) and Peer Network CIDRs (the on-premises subnets). These static CIDR lists are the routing; there is no BGP. Save the tunnel, then configure the on-premises device with identical parameters and verify the tunnel reaches an active state.

Steps - NAT Gateway for private egress (in the Data Center Designer):

Open the VDC and confirm a private LAN containing at least one VM exists (the private application LAN from Unit 3.1).
Add a NAT Gateway to the workspace and connect its interface (source network) to that private LAN.
Select the NAT Gateway and open its Properties in the Inspector > Settings. Set a Name and add a public IP address from the reserved addresses (one is enough; multiple can be added).
Create a NAT rule. Set a name and a Protocol (TCP, UDP, ICMP, or ANY). For Source > Public IP, select one of the gateway's public IPs (this masks the outgoing source address). For Source > Subnet, enter the private VM or subnet in CIDR notation (for example 10.10.10.0/24). Optionally restrict Target > Subnet to specific external destinations to allow egress only to trusted endpoints.
Set the LAN default route to the gateway. On the private VMs, the routing table must send internet-bound traffic to the NAT gateway: point the default route (0.0.0.0/0) at it, or add a dedicated route per external target if a default route is not acceptable. Without this routing change the gateway exists but no traffic uses it.
If those private VMs need DNS resolution while using the NAT default route, ensure a SNAT rule covers UDP, otherwise default DNS resolution will fail.

Common mistakes:

Reserve the static public IP before creating the gateway; both gateways pick from reserved addresses and a DHCP address cannot be used.
Do not look for an IKEv1 option, there is none; the peer must speak IKEv2 (or use WireGuard). Phase-1 and phase-2 parameters must match on both ends exactly or the tunnel will not establish.
The VPN HA pair shares one public IP; configure the on-premises peer to target that single address, not two.
NAT Gateway is SNAT-only: there is no inbound/DNAT path. Do not try to publish a service through it; use a load balancer for inbound.
Provision the NAT Gateway and its rules before expecting egress, then change the LAN default route to the gateway, the routing change is the step people forget, and traffic silently never leaves until it is made.
Missing a UDP SNAT rule breaks DNS for VMs whose default route is the NAT gateway.

The tunnel parameters carry a real architectural point: the routed subnets are static CIDR lists on each side, not a dynamic protocol. A short API view of the same tunnel makes the immutable shape explicit (the phase settings and the two CIDR arrays are the whole routing contract):

curl -X POST 'https://vpn.de-fra.ionos.com/ipsecgateways/{gatewayId}/tunnels' \
  -H 'Authorization: Bearer <token>' -H 'Content-Type: application/json' \
  --data '{ "properties": {
    "name": "to-fincorp-dc",
    "remoteHost": "vpn.fincorp.example",
    "auth": { "method": "PSK", "psk": { "key": "<32-char-psk>" } },
    "ike": { "diffieHellmanGroup": "16-MODP4096", "encryptionAlgorithm": "AES256", "integrityAlgorithm": "SHA256", "lifetime": 86400 },
    "esp": { "diffieHellmanGroup": "16-MODP4096", "encryptionAlgorithm": "AES256", "integrityAlgorithm": "SHA256", "lifetime": 3600 },
    "cloudNetworkCIDRs": [ "10.0.0.0/24" ],
    "peerNetworkCIDRs":  [ "198.51.100.0/24" ] } }'

Summary

Hybrid connectivity on IONOS is three non-overlapping products. The VPN Gateway carries encrypted site-to-site traffic over the internet with IKEv2 (or WireGuard), static CIDR-based routing, and an active-passive HA option that presents a single public IP. The NAT Gateway gives private workloads outbound-only internet access via SNAT, with no inbound path, requiring a reserved public IP and a deliberate LAN default-route change. Private Cross-Connect joins VDCs privately but only within the same region and contract. Choosing among them is a matter of which boundary you are crossing, and during a migration the VPN and NAT primitives, built here, carry the cutover traffic.

Key Points:

VPN Gateway is IKEv2/WireGuard with no IKEv1; routing is static CIDR lists (no BGP); HA is active-passive on one shared public IP; up to 1 Gbps per tunnel.
Reserve the public IPv4 address (same location as the VDC) before creating either gateway; DHCP addresses cannot be used.
NAT Gateway is SNAT-only (no inbound/DNAT), needs a reserved public IP, supports up to six private LANs, and only forwards traffic once the LAN default route points at it.
For VMs whose default route is the NAT gateway, a UDP SNAT rule is required or DNS resolution breaks.
Private Cross-Connect is same-region and same-contract only, requires a shared IP range, allows one Cross-Connect per LAN, and is free; it is not a cross-region or cross-contract link.

Important Terminology:

SNAT (Source NAT): Rewriting the source address of outbound packets so private hosts can initiate internet connections; the NAT Gateway does this and refuses unsolicited inbound (DNAT) traffic.
IKEv2: The key-exchange protocol the IPSec VPN Gateway uses; the only supported IKE version, IKEv1 is not available.
Pre-shared key (PSK): The shared secret authenticating an IPSec tunnel; a 32-character key is recommended and must match on both peers.