Discussions related to using object storage as a backup target.
Post Reply
Daithi
Enthusiast
Posts: 78
Liked: 3 times
Joined: Oct 16, 2013 9:19 am
Contact:

SOBR - Azure Archive - SSH and IP

Post by Daithi »

Hi,

I understand we need to allow SSH from our onsite Veeam server to create the Proxy Helper Virtual Machines in Azure. These VMs get created and deleted so may have different IP addresses each time.

I want to harden our SSH outbound rule on the server so it will only be able to SSH into the Veeam appliances in Azure.

Is there anyway to set a static IP address or a DNS name for these virtual appliances, instead of relying on quite a large range from Microsoft?
HannesK
Product Manager
Posts: 14160
Liked: 2807 times
Joined: Sep 01, 2014 11:46 am
Full Name: Hannes Kasparick
Location: Austria
Contact:

Re: SOBR - Azure Archive - SSH and IP

Post by HannesK » 1 person likes this post

Hello,
not really, as there is one archiver proxy machine per per backup chain, that would still be up to 64 machines. If you have Azure Direct Connect, one could use internal instead of public IP addresses (but even then, it's multiple addresses)

Best regards,
Hannes
Daithi
Enthusiast
Posts: 78
Liked: 3 times
Joined: Oct 16, 2013 9:19 am
Contact:

Re: SOBR - Azure Archive - SSH and IP

Post by Daithi »

Thanks. I guess a VPN connection could be a good way to go. It's a pity we can't limit/specify what the addresses would be as it seems a bit unwieldy now
veremin
Product Manager
Posts: 20255
Liked: 2248 times
Joined: Oct 26, 2012 3:28 pm
Full Name: Vladimir Eremin
Contact:

Re: SOBR - Azure Archive - SSH and IP

Post by veremin »

I think you can create a dedicated subnet, select it in the appliance settings and create a rule for this specific IP range only.
micoolpaul
Veeam Vanguard
Posts: 207
Liked: 105 times
Joined: Jun 29, 2015 9:21 am
Full Name: Michael Paul
Contact:

Re: SOBR - Azure Archive - SSH and IP

Post by micoolpaul » 1 person likes this post

Hi,

Apologies to revive this older topic, but from what I can see this feature request is still outstanding. I'd like to add my +1 to the feature request with the following justifications:


Isolated Backup Tenants:
We're seeing more and more customers wanting a separate tenant for their backups vs production for their AWS/Azure environments. Previously we've had suggestions that to avoid the dynamic public IP address allocations currently implemented and subsequent open firewall rules, utilise an ExpressRoute or VPN.
Quite a few customers have utilised ExpressRoute or VPNs for their production tenants but will be unwilling to pay extra for a second tenant's connection to these services to avoid the dynamic public IP address headaches of present.

Azure/AWS Recommendations:
We're also seeing Amazon & Microsoft steering customers away from direct internet access per VM, opting for centralised firewalls for routing and preventing IPv4 exhaustion. But without a way to statically assign an IP address to aim at within VBR, we're stuck with a 1:1 public IP address for each archiver appliance.

Firewall Headaches:
We currently can't specify static IP addresses or even just reserved IP addresses within AWS/Azure to reuse whenever a new archiver appliance gets created currently, so anything public is dynamic. Even the ability to reserve a couple of IP addresses that the archiver appliances could allocate to themselves temporarily when free would be a huge step forwards for firewall security. Veeam are talking about Zero Trust but currently to communicate over WAN you need to allow port 22 outbound from your VBR server to the entire internet, or at best allocate to a firewall manufacturer specific list of IP addresses per region for AWS/Azure and hope that they've kept that list up to date, and even then you're allowing communication to an entire Azure region...

So, please if we could get some more granular control over this it would be greatly appreciated!
-------------
Michael Paul
Veeam Legend | Veeam Certified Architect | Veeam Vanguard
Post Reply

Who is online

Users browsing this forum: KYamada and 7 guests