go2tencentcloud Blocked by Security Group DROP Rules

Setting up a green environment

We run GitLab on a Tencent Cloud CVM instance. Besides hosting repositories, this GitLab also stores Spring Cloud Config (SCC) files that are consumed by production applications. Messing up an upgrade here would break config resolution for a lot of services, not just Git access.

I needed to upgrade GitLab to a newer version, and I wanted to do it with a blue-green approach. Spin up a green instance with the new version, migrate the data over, test everything, then cut over. If something goes wrong, the blue instance is still running untouched.

The plan was simple. Spin up a new CVM with the same disk layout, same OS, same everything, and keep it completely isolated from the production instance. No traffic should flow between blue and green unless we explicitly allow it.

So I did what any reasonable person would do. I configured the security groups to DROP all traffic between the two instances.

Here is what the security group rules looked like. The production instance, call it gitlab, had this egress rule:

{
  action           = "DROP"
  protocol         = "ALL"
  port             = "ALL"
  cidr_block       = "<green-instance-ip>/32"
  rule_description = "gitlab-green - Tencent CVM"
}

And the green instance, gitlab-green, had the mirror ingress rule:

{
  action           = "DROP"
  protocol         = "ALL"
  port             = "ALL"
  cidr_block       = "<production-instance-ip>/32"
  rule_description = "gitlab - Tencent CVM"
}

Clean, simple, and completely isolated. Or so I thought.

Attempting the migration

To clone the production instance to the green one, I used go2tencentcloud. If you are not familiar with it, go2tencentcloud is Tencent Cloud's online migration tool. It migrates systems and applications from a source server directly to a destination CVM without needing to create or upload images [1]. You run a client on the source server, the tool connects to the destination, and it copies everything over.

The destination was a fresh CVM with a bare OS. Same system disk size, same data disk size, but no pre-built image. Just an empty instance waiting for the migration to land.

I kicked off the migration and waited.

Error one: host-to-host connection

Almost immediately, the migration failed.

Error code: ERROR_HOST_TO_HOST_CONNECTION
Failure cause: The migration source cannot connect to the target instance.
Please verify network connectivity between the source and target, and ensure
port 80 is open in the target security group's inbound rules.

Right. The security group rules I was so proud of were blocking the migration tool. The tool tries to connect from the source to the target, and my DROP rules said no. Fair enough.

The error message specifically said port 80. The documentation also says the destination needs port 80, 443, and 3389 open [2]. But the error only mentioned port 80, so I followed the advice. I added a temporary ACCEPT rule for TCP port 80 from the production IP on the green instance's ingress, and a matching ACCEPT rule for TCP port 80 to the green IP on the production instance's egress. Both placed before the DROP rules.

Here is what the green instance's ingress looked like after the fix:

ingress_rules = [
  {
    # TEMPORARY: Allow port 80 from production for migration
    action           = "ACCEPT"
    protocol         = "TCP"
    port             = "80"
    cidr_block       = "<production-instance-ip>/32"
    rule_description = "TEMP - gitlab - Allow migration port 80"
  },
  {
    action           = "DROP"
    protocol         = "ALL"
    port             = "ALL"
    cidr_block       = "<production-instance-ip>/32"
    rule_description = "gitlab - Tencent CVM"
  },
  # ... other rules
]

I restarted the migration.

Error two: data transmission

It failed again.

Error code: ERROR_DATA_TRANSMISSION
Failure cause: Data transmission failed. Please check the network connectivity
between the source machine and the target instance, or contact customer service.

This one was frustrating. The host-to-host connection error was gone, which meant port 80 was open and the initial handshake worked. But the actual data transfer was failing. The error message was vague, no mention of which port or protocol was failing. The guide linked from the error was not helpful either.

At this point I realized my mistake. I had no idea what ports go2tencentcloud actually uses during the data transfer phase. I only knew it needed port 80 for the initial connection because the first error told me so. The documentation mentions ports 80, 443, and 3389 [2], but the error message only called out port 80. That mismatch between the docs and the error message tripped me up.

I decided to stop guessing and just open everything. I changed both temporary rules from TCP port 80 to ALL protocols and ALL ports.

ingress_rules = [
  {
    # TEMPORARY: Allow all ports from production for migration
    action           = "ACCEPT"
    protocol         = "ALL"
    port             = "ALL"
    cidr_block       = "<production-instance-ip>/32"
    rule_description = "TEMP - gitlab - Allow migration"
  },
  {
    action           = "DROP"
    protocol         = "ALL"
    port             = "ALL"
    cidr_block       = "<production-instance-ip>/32"
    rule_description = "gitlab - Tencent CVM"
  },
  # ... other rules
]

Same change on the production instance's egress side. ALL protocols, ALL ports, both directions.

I restarted the migration one more time.

It worked. The migration completed without issues.

Closing

The root cause was simple. I configured complete network isolation between the two instances with DROP rules, then tried to run a tool that needs direct connectivity between them. The DROP rules were doing exactly what I asked them to do.

The interesting part is why the first fix, opening only port 80, was not enough.

In Tencent Cloud security groups, rules are evaluated in order from top to bottom. The first rule that matches the traffic wins [3]. My DROP rules were the first ones in the list, and they matched everything. When I added the ACCEPT rule for port 80, it went before the DROP rule, so port 80 traffic was allowed. The initial connection worked, but the subsequent data transfer phase apparently uses additional ports or protocols beyond what the error message suggested.

I am not sure exactly which ports go2tencentcloud uses during data transfer. The tool uses rsync-like behavior under the hood based on what I saw, but I did not dig into it further. The important thing is that trusting only the error message was the wrong call. The documentation listed three ports (80, 443, 3389) [2], and the actual tool behavior seems to need more than what the error described.

References

[1] Tencent Cloud, "Online Migration Overview," Cloud Virtual Machine documentation, 2026. [Online]. Available: https://www.tencentcloud.com/document/product/213/35639. [Accessed: Sep. 18, 2026].

[2] Tencent Cloud, "Server Migration via a Migration Tool," Cloud Virtual Machine documentation, 2026. [Online]. Available: https://www.tencentcloud.com/document/product/213/55046. [Accessed: Sep. 18, 2026].

[3] Tencent Cloud, "Security Group Overview," Cloud Virtual Machine documentation, 2025. [Online]. Available: https://www.tencentcloud.com/document/product/213/12452. [Accessed: Sep. 18, 2026].