External IP address required for 12.3 upgrade of GCP appliance

[srlarsen]

Is there a current effort underway to be able to upgrade the appliance without requiring an external IP? It seems like this keeps popping up in different places and really causes us problems with security and our architects that control the policies. I have a current ticket open(07634532) for upgrading our appliance and it is just frustrating to once again hit the issue with external IPs being required. We temporarily opened up the security policy and got past that issue but now they believe port 22 is blocked. It would be so much simpler and more secure if we had the option for all the communication to be done over internal/private IP addresses.

[srlarsen]

Also, can the GCP marketplace appliance be updated to the latest version so we could deploy from the marketplace and connect to it that way? We have more problems trying to deploy from the VBR server than deploying from the marketplace and then connecting to it.

[Vitaliy S.]

Hi Stephen,

Unfortunately, public/external IP is currently required to perform the upgrade, however, let me discuss it with the dev team to see if we can address this issue in our future updates.

As for the marketplace image, then new versions will only be delivered via Veeam B&R (including installation and upgrade), there is no way to update the standalone version. I will take a look at your case details and forward the setup config to our QA team so that they make it part of their test plans for future versions.

Can you shed some light on the problems with the deployment you have (apart from what is discussed here)?

Thanks!

[srlarsen]

The 12.3 upgrade went fine on everything except the GCP cloud appliance. When the upgrade process attempted the upgrade on the appliance it initially failed for a permission. We worked with our architects and got the needed permissions added. Then it failed because of the external IP requirement. Working with our architects once again, they temporarily lifted the requirement so the upgrade process could run. Now we are receiving a socket timeout. Port 22 was suspected but we can show that the VBR server can access port 22 on other VMs with internal and external addresses. That is where our case is now. The last time we had an issue, I was able to deploy via the marketplace and then connect VBR to it and restore the config, that is why I also asked about updating the marketplace image.

[Vitaliy S.]

I see, that's unfortunate that you've faced these issues during the upgrade process, but we are no longer planning to update/allow deployments via the marketplace. It looks like the private deployment was mostly the issue, so I will ensure it is part of QA plans when testing the upgrade procedure. Thanks for sharing your feedback.

[srlarsen]

An update for anybody else that runs into this issue.
We had to add the permission of deploymentmanager.deployments.create to our service account.
We had to temporarily lift our policy that restricts the creation of VMs with external IPs.
We had to create a firewall rule for port 22. It was suggested in the ticket that we open it up for over 4000 addresses but our network/security teams did not like that. After testing, we found that the network tag on the existing appliance carried over to the temp VM created by the upgrade, so our network team created an ingress rule for port 22 based on that network tag.
We had to update the metadata on the project and set enable-oslogin=FALSE to get rid of the permission denied publickey error.

Just wanted to update for others and possibly myself if I forget

[Vitaliy S.]

Thanks Stephen for doing it, highly appreciated!