You can establish connectivity from the destination database to the source database
through a secure reverse SSH tunnel. This method requires a bastion host VM in
the Google Cloud project as well as a machine (for example, a laptop on the
network) that has connectivity to the source database.
> [!IMPORTANT]
> **Important:** If your source is within a VPN (in AWS, for example, or your own on-premises VPN), your source connection profile should use the VPN IP address and port instead of the source IP address and port.
The Database Migration Service collects the required information at migration creation
time, and auto-generates the script for setting it all up.
[](https://docs.cloud.google.com/database-migration/docs/postgres/configure-connectivity-reverse-ssh-tunnel#lightbox-trigger) **Figure 1.** Migration networking example: source connectivity over an SSH tunnel. (click to enlarge) 
## Set up a reverse SSH tunnel
The following steps are performed in the Database Migration Service flow for
[creating a migration job](https://docs.cloud.google.com/database-migration/docs/postgres/create-migration-job.md.txt), to set up a reverse SSH tunnel between the source
database and Cloud SQL instance. After you provide some parameters, you
execute a set of `gcloud` commands on a machine which has connectivity
to both the source database and to Google Cloud.
1. Select the VM instance used to establish connectivity between the source database and the Cloud SQL instance. Typically this is a VM running in the VPC where the application accessing the new Cloud SQL database runs. The VM instance serves as the SSH tunnel bastion server.
2. You can use an existing Compute Engine VM instance for this purpose.
1. Choose the Compute Engine VM instance from the list.
2. Provide a free port that the SSH tunnel can use.
> [!NOTE]
> Note: For the reverse SSH tunnel to work, set the `GatewayPorts` parameter to `yes` in the `/etc/ssh/sshd_config` file on the target server. After you update the file, restart the sshd service using the `sudo systemctl restart sshd.service` command. If you don't want to change the configuration of your existing VM, then create a new VM.
3. Alternatively, you can create a new VM at this step. Select
`CREATE A COMPUTE ENGINE VM INSTANCE` and the generated script
includes instructions to create it.
1. Provide a name for the VM instance.
2. Select a machine type for the VM.
3. Specify a subnet for the VM
> [!NOTE]
> Note: A Compute Engine VM instance created by the script isn't managed by Database Migration Service. If one is created, then your organization is charged for the instance based on standard pricing, and is responsible for its management, including deleting the instance when it's no longer needed.
4. Click **VIEW SCRIPT** to view the generated script.
> [!NOTE]
> By default, the script will generate a public IP address for the Compute Engine VM server. If you want the IP address to be private, then do the following:
> - Alter the `gcloud compute instances create` command by adding the [`--no-address` flag](https://docs.cloud.google.com/sdk/gcloud/reference/compute/instances/create.md.txt#--address).
> - Alter the `gcloud compute ssh` command by adding the [`--internal-ip` flag](https://docs.cloud.google.com/sdk/gcloud/reference/compute/ssh#--internal-ip).
>
> Also, if you want to create a bastion host VM on a subnet which is on a shared VPC, then alter the `export SUBNET_NAME` command from the generated script to point to `/projects/project_name/regions/region_name/subnetworks/subnetwork_name`.
>
> For example:
>
> `export SUBNET_NAME=projects/myproject/regions/myregion/subnetworks/mysubnetwork`
>
> project_name is the name of the project where the shared VPC is placed. A project has regions and subnetworks. region_name and subnetwork_name are the names of the region and subnetwork that are associated with the VPC project.
> [!NOTE]
> **Note:** Make sure the replication connections section of the `pg_hba.conf` file or the cloud security groups (for AWS RDS, Aurora, or Azure) on the source database are updated to accept incoming connections on port `5432` from the bastion host VM IP address and Cloud SQL VPC IP address range.
5. **Run the script on a machine that has access to both the source database and the
Compute Engine VM**. The script performs the following operations:
- Configures the Compute Engine VM as an SSH tunnel bastion server.
- Establishes a secure SSH connection forwarding traffic from the bastion host port to the source PostgreSQL database server (port 5432).
- If you're creating a new Compute Engine VM, then after successfully
running the script, copy the VM server IP from the script output and enter
it in the provided text field. The Cloud SQL instance will be updated
as needed when you later test or start the migration job.
6. Click **CONFIGURE \& CONTINUE**.
7. [Verify your migration job](https://docs.cloud.google.com/database-migration/docs/postgres/verify-migration.md.txt) to confirm that it correctly migrated
data from your source database instance to the destination Cloud SQL database instance.
8. Depending on your network architecture, you might need to set up
additional VPN gateways in your system. For more information, see the following
pages [Create HA VPN connections between Google Cloud and AWS](https://docs.cloud.google.com/network-connectivity/docs/vpn/tutorials/create-ha-vpn-connections-google-cloud-aws.md.txt)
or [Create HA VPN connections between Google Cloud and Azure](https://docs.cloud.google.com/network-connectivity/docs/vpn/tutorials/create-ha-vpn-connections-google-cloud-azure.md.txt)
in the Cloud VPN documentation.
9. After your migration job is configured, connectivity is verified,
and VPNs are configured successfully if necessary, then you can run the job.