Connecting Fivetran to Databases in a Private VPC: PrivateLink, VPN and SSH Tunnels Compared

Most Fivetran implementations stall in the same place. The connector config screen is asking for a host and a port, the source database sits in a private subnet with no public IP, and the security team has already said no to the obvious answer. Nothing about the pipeline design is blocked - the network is.

This tutorial walks the realistic options for reaching a private source, what each one costs you in setup effort and ongoing ownership, and the answers you will need when the security review starts. It covers databases (Postgres, MySQL, SQL Server, Oracle, MongoDB) and self-hosted APIs. SaaS connectors like Salesforce or HubSpot need none of this - they are reached over the public internet with OAuth.

The five options, honestly

Option	Where it works	Setup effort	Ongoing ownership	Typical use
IP allowlist over TLS	Any public endpoint	Low	Low	Managed DB with a public endpoint you are allowed to expose
SSH tunnel (bastion)	Anywhere with a host you control	Low/medium	Medium - you own the bastion	Small teams, single VPC
Reverse SSH tunnel	Networks with no inbound access at all	Medium	Medium/high	Strict no-inbound policies, on-prem
Site-to-site VPN	AWS, Azure, GCP, on-prem	Medium	Medium	On-prem sources, multiple subnets
PrivateLink / Private Service Connect	AWS, Azure, GCP	Medium	Low once built	Enterprise cloud sources, the default answer for a security review

There is a sixth option worth naming, because it changes this whole conversation: Hybrid Deployment. Instead of letting Fivetran reach into your network, you run the data plane inside it as a local agent, and only metadata leaves. If your blocker is a hard policy that source data must never traverse a vendor's cloud, that is the conversation to have rather than trying to win a networking argument.

Option 1: allowlist Fivetran's IPs

The simplest thing that works. Every Fivetran destination group is pinned to a cloud region, and each region has a small set of documented egress IPs. You allow those IPs to your database port and require TLS.

What to get right:

• Pull the IPs from your own group, not from a blog post. The group's setup page shows the IPs for your region, and they are also returned by GET /v1/groups/{group_id} metadata in the REST API. They change occasionally, and Fivetran announces changes - subscribe someone who is not you.
• Require TLS and verify it. Allowlisting is authentication by network position, which is weak on its own. Enforce sslmode=verify-full semantics wherever the source supports it.
• Use a read replica. A separate replica endpoint keeps the allowlist off your primary and keeps CDC read load off it too.

When this fails a security review, it fails for a specific reason: the endpoint is reachable from the public internet at all, and the control is a mutable IP list. That objection is legitimate and it is why the rest of this article exists.

Option 2: SSH tunnel through a bastion

Fivetran connects over SSH to a small host you run in the public subnet, and tunnels from there to the database in the private subnet. The database itself is never exposed.

Setup, in order:

1. Launch a minimal instance in a public subnet. It needs nothing but sshd - no database client, no application.
2. Restrict its security group to port 22 from the Fivetran region IPs only.
3. Allow the bastion's security group to the database port on the database's security group. Not the whole subnet - the security group.
4. Create a dedicated user, for example fivetran_tunnel, with no shell and no sudo: useradd -m -s /usr/sbin/nologin fivetran_tunnel.
5. In the connector setup, choose the SSH tunnel connection method. Fivetran generates a public key for that connection. Paste it into ~fivetran_tunnel/.ssh/authorized_keys. You never upload a private key to Fivetran.
6. Harden the entry: prefix the key with no-pty,no-agent-forwarding,no-X11-forwarding,permitopen="db.internal:5432" so the key can only open a tunnel to that one host and port.

That permitopen restriction is the difference between a bastion and a liability. Without it, a compromised key is a foothold in your VPC; with it, it is a pipe to one port.

The cost of this option is not money, it is ownership. Somebody has to patch that host, monitor it, and be paged when it dies at 03:00 and the tunnel takes six connectors down with it. Run it in an auto-scaling group of one, or use a managed bastion service, so replacement is automatic.

Option 3: reverse SSH tunnel

Some networks allow no inbound connections whatsoever - common on-prem, common in regulated environments. Reverse SSH inverts the direction: a host inside your network dials out to Fivetran's tunnel service and holds the connection open. Fivetran then rides that existing connection inward.

Use it when "no inbound, ever" is the policy. Be aware of the trade-off: the tunnel's health now depends on a long-lived outbound process inside your network. Run it under systemd with Restart=always and, critically, enable keepalives (ServerAliveInterval 30, ServerAliveCountMax 3) so a silently dead NAT translation gets torn down and re-dialled instead of leaving a tunnel that looks up and passes no traffic. Half the "Fivetran stopped syncing and nothing changed" tickets on reverse tunnels are a stale session no one noticed.

Option 4: site-to-site VPN

An IPsec tunnel between Fivetran's VPC and yours. This is usually the right answer when the source is genuinely on-premise and a cloud private-link product cannot reach it, or when several sources sit across several subnets and you would otherwise be building a bastion per network.

Practical notes:

• Fivetran will need non-overlapping CIDR ranges. Check this before the kickoff call - RFC1918 collisions with 10.0.0.0/16 are the single most common reason a VPN plan gets rebuilt.
• Scope the tunnel to the specific source subnets, not to your whole VPC, and put a route table and security-group boundary around it.
• Someone in your network team owns the tunnel's lifecycle. Get that name into the runbook while the project is still funded.

Option 5: PrivateLink and its cousins - the enterprise default

AWS PrivateLink, Azure Private Link and Google Private Service Connect all do the same conceptual thing: expose one service endpoint to one consumer over the cloud provider's backbone, with no route to the public internet in either direction, no NAT gateway, no allowlist to maintain.

This is what to propose first in an enterprise engagement, because it is the option a security architect is already comfortable with.

The AWS shape, for a database behind a Network Load Balancer:

1. Put the source behind an NLB in the private subnets. For RDS, target the instance IPs or use an IP target group pointed at the endpoint's resolved addresses, and be deliberate about failover behaviour - a stale IP target after an RDS failover is the classic breakage here.
2. Create a VPC endpoint service from that NLB.
3. Allow Fivetran's AWS principal as an allowed principal on the endpoint service.
4. In Fivetran, open a PrivateLink request for the connection (Account Settings, or via the REST API private-links endpoints) with your service name.
5. Accept the endpoint connection when it appears, then configure the connector to use the PrivateLink hostname Fivetran returns rather than your internal DNS name.

Azure uses a Private Link Service in front of a Standard Load Balancer and an auto-approval list; GCP uses a Private Service Connect service attachment. The sequence is the same: publish a service, authorise the consumer, wire the connector to the returned endpoint name.

Two things to budget for. First, PrivateLink is a per-hour-per-endpoint plus per-GB charge, small but real, and it is charged per connection - multiply it by how many sources you plan. Second, availability of private networking depends on your Fivetran plan and region; confirm it in writing before you promise it in an architecture diagram. The number of migrations that discover this in week three is higher than it should be.

Choosing, in one pass

• Source is on-prem with no inbound allowed - reverse SSH, or Hybrid Deployment if the objection is data residency rather than networking.
• Source is on-prem or spread across several networks, inbound negotiable - site-to-site VPN.
• Source is in AWS, Azure or GCP and a security review is involved - PrivateLink / Private Link / Private Service Connect.
• One source, small team, you already run a bastion well - SSH tunnel with permitopen.
• Managed database you are permitted to expose, low sensitivity - IP allowlist with enforced TLS, and revisit it later.

Validating it before you blame Fivetran

When a private connection fails, test from inside your own network first. Almost every ticket resolves in one of these four checks:

1. From the bastion or an instance in the same subnet: nc -zv db.internal 5432. If that fails, it is a security group or route, not Fivetran.
2. Resolve the hostname you gave Fivetran from the path Fivetran uses. Private DNS is the number one culprit on PrivateLink - an internal name that resolves beautifully on your laptop VPN resolves to nothing from the endpoint.
3. Check the database user's own host restrictions. A pg_hba.conf line or a MySQL user@host grant will reject a connection that arrives from the tunnel's IP even when the network is perfect.
4. Confirm CDC prerequisites separately - replication slots, wal_level, log retention. A connector can reach the database and still fail setup for reasons that have nothing to do with networking, and the error text does not always make the distinction obvious.

Log the successful path in a runbook: which method, which endpoint, which security groups, who owns the renewal of any key or certificate. Twelve months from now the person debugging it will not be you.

Where this fits in a delivery plan

Networking is the long-lead item in nearly every Fivetran rollout. Firewall changes and PrivateLink approvals move at the speed of a change-advisory board, not a sprint. Start the request on day one, in parallel with destination setup and connector design, and stage a public or sandbox source so pipeline work is not blocked while the tunnel is approved.

SyncSpur runs this path regularly: we scope the connectivity option with your network and security teams, build it, and hand back a documented runbook alongside the pipelines. If you are stuck between a private subnet and a security review, get in touch and we will map the options against your constraints - or read more about how we approach Fivetran platform setup and management and migration to the Fivetran platform.