SSH access to Veeam Proxy Appliance for Azure Archive offloading

[fozz33]

Hi there.
Hopefully I can explain my issue here...latest version of Veeam v11.

So we have an SOBR setup using local disk as the Perf tier, Azure COOL storage as the Capacity tier and Azure ARCHIVE storage as the Archive tier.
The backups run fine to the Perf tier an dthe offloading to Azure Cool works fine. No problems here.

The issue is with the Archive tier.
For Veeam to move the backups from the Cool to Archive storage accounts, it spins up a 'veeam-proxy-appliance' Linux VM in Azure.
The Veeam server then SSHs into that on it's public IP and does the necessary steps to move the backup files between the tiers.
But the issue is our tenant allows no access to Public IPs of VMs - only to the private IPs.

I can see no way to tell Veeam that it should SSH into the Private IP of the temp Linux VM that it spins up.
I have logged this as a ticket (04885181) but also wanted to see if anyone in this support community has also come across this constraint?
It seems to be an insecure setup and I would be surprised if my company is the first to encounter it so hoping for some suggestions.


Cheers!
CF

[HannesK]

Hello,
are you using AzurePreferPrivateIpAddressesForProxyandLinuxAppliance ?

Best regards,
Hannes

[fozz33]

Cheers for that.
I have added that reg key now (and rebooted Veeam server) and will see what happens when the next SOBR job runs in a few hours and feedback.

[fozz33]

Hi there.
I am still seeing in the logs that Veeam is trying to connect to my Archive appliance using it's public IP:

Code: Select all

[30.06.2021 13:52:01] <20> Info         IP address of LiveCD VM: 52.157.109.101
[30.06.2021 13:52:01] <20> Info         [Ssh] Creating new connection 237151b0-98d0-4c69-9cc0-eff583200836 [host: '52.157.109.101', port: 22, elevation to root: 'yes', autoSudo: no, use su if sudo fails: no, host name: , IPs: [52.157.109.101], AuthenticationData: [UserName: ubuntu, AuthTypes: [KeyboardInteractive, Password]]].
[30.06.2021 13:52:01] <20> Info         [Ssh] Creating SSH connection 237151b0-98d0-4c69-9cc0-eff583200836 to server 52.157.109.101
[30.06.2021 13:52:01] <20> Info         [Ssh] Creating Granados SSH connection '237151b0-98d0-4c69-9cc0-eff583200836' (unknown protocol)
[30.06.2021 13:52:01] <20> Info         [Ssh] logon, host: '52.157.109.101', port: 22, elevation to root: 'yes', autoSudo: no, use su if sudo fails: no, host name: , IPs: [52.157.109.101], AuthenticationData: [UserName: ubuntu, AuthTypes: [KeyboardInteractive, Password]]
[30.06.2021 13:52:01] <20> Info         [Ssh] Granados '237151b0-98d0-4c69-9cc0-eff583200836' connected to . Session: [SSH Session; Local: ; Remote: ]
[30.06.2021 13:52:22] <20> Error        Failed to connect by SSH. RetryCount: '0'. MaxRetryCount: '100'.
[30.06.2021 13:52:22] <20> Error        Failed to login to host: '52.157.109.101', port: 22, elevation to root: 'yes', autoSudo: no, use su if sudo fails: no, host name: , IPs: [52.157.109.101], AuthenticationData: [UserName: ubuntu, AuthTypes: [KeyboardInteractive, Password]]. Unable to establish connection to host 52.157.109.101 on any IP address. (System.Exception)

So this s after I created the DWORD as above and set that to a value of '1' and rebooted the B&R server.
That's a shame as that reg key looked like what I needed but it seems it's mainly aimed at deploying a proxy to a Linux VM in Azure, which is not what I am doing.

Rather Veeam is creating the Linux VM itself to facilitate Archive SOBR offloading (a new feature in v11, I believe).

It's strange Veeam would use the public IP with no ability to use the internal IP (assuming connectivity is there from the B&R server to Azure internal IPS, which it is), which would be more secure and should be a simple config setting somewhere.

Hoping someone has another idea?

Cheers.

[veremin]

The referenced key works for Direct Restore to Microsoft Azure feature, for proxy and helper appliances it leverages.

For Archive Tier proxy appliance we have a different key, so try it out:

Code: Select all

ArchiveFreezingUsePrivateIpForAzureAppliance

Thanks!

[fozz33]

Great news, that 2nd reg key worked and my Archive jobs are now working like a treat!
Cheers for that info, very much appreciated.

[veremin]

You are welcome, should other help be needed - let us know. Thanks!

[codylittle]

Hey All,

Is there currently any way to have the Azure Archiver Appliance communicate over our ExpressRoute?
I'm aware that there's KB4014 but is that just for the restore appliance? If it isn't just for the restore appliance, how can I set the DNS name of the archiver appliance?
For regulatory issues we'll be unable to give the appliance a WAN routable IP.

Regards,
Cody

[Mildur]

Hi Cody

For the archive appliance, another key is required.
Can you try the reg key from veremin‘s comment above?

Thanks
Fabian

[veremin]

And since the issue about using archiving appliances over private IP addresses popped up again, we have decided to enhance the corresponding KB article and include information about the usage of ExpressRoute for Azure Archive Tier (so the regkey is not mentioned only on forums). Thanks!