Transport Encryption E2E with less Proxy servers and still with Hot-Add Method

Some very interesting information here Marcel.  Thanks for sharing this.

Thanks for sharing ​@makacmar ...and nice screenshots, most important of which imo is where to configure the network traffic security! 😊

Hi ​@makacmar. It would be helpful if larger or higher-resolution images could be shared in the future

  There are requirements of several level of encryption. This could be enabled on

• Backup level – encryption inside of backup job (for VM) (for agent is encryption on repository and for plugin is on database level)
• Platform level – encryption of VM should be provided
• Transport level – encrypted transport of backups to repository

For companies of sensitive data with highest security is not enough only to have encrypted backup and VM, but as well transport of backups.

Hot-Add Method

               Veeam can take a snapshot and create link of snapshot (cloned VM) and attach virtual disks on Veeam Proxy. This is provided via ISCSI Hot-Add method, where backed up VM and Veeam proxy are running on the same ESX host.

               This is best practice. So, the best is used with so many proxy servers as how many ESX hosts we have, because is best performance, latency of backup.

               It could be used less proxy servers, but risk must be considered like performance and latency. Second issue that encryption of transport end-to-end is not valid anymore!

1. Less Proxy Servers

               Less proxy servers could be used and Veeam Proxy Server as Virtual Appliance is able to work and use Hot-Add method during backup. This is not valid only, if ESX hosts are near by themselves.

               If vSAN is stretched as one datastore you proxy server and backup VM if it’s on:

• ESX host next to ESX host with Veeam Proxy
• ESX host located in another datacenter as ESX host with Veeam Proxy (if connection is fast enough)

• Hot-Add is not valid if

• ESX host is in another cluster (in this case NBD/NBDSSL is used)

      Hot-Add method by multi-cluster solution

• for each cluster

2. Encryption E2E

Transport Encryption from Proxy Server to Repository Server is managed by Veeam:

Creation of link to snapshot (cloned) on another ESX host is not same like on the same ESX host. This communication can be compromised (Red Hot-Add method).

To protect it, it must be enabled encryption on vSAN level.

There are several methods how to encrypt transport of backup from another ESX host. One of them, on vSAN, is to use vSAN Data In-Transport Encryption.

Multi-cluster Solution

hope now is fine :) sorry, i did not count that resolution will be so high degraded 

Hi ​@makacmar , sorry but I'm not sure I understood the article correctly. Could you send references to the official documentation or forum posts where you found this information? Thank you, and sorry for the trouble..maybe tomorrow morning my mind will be fresher and I will read everything without any problems! 😃

Hi marco_s,

Veeam i using VMware feature hot-add transport mode for fastest way on vSphere, where VMware is described this method here:

https://vdc-download.vmware.com/vmwb-repository/dcr-public/8f96698a-0e7b-4d67-bb6c-d18a1d101540/ef536a47-27cd-481a-90ef-76b38e75353c/doc/GUID-AA324E06-714D-4AD5-A76D-40B0BD7E81F3.html

There is written: “This involves a SCSI HotAdd on the ESX host where the target VM and backup proxy are running”

To this statement is statement of Veeam as well.

For costs saving we decided to use less proxy servers, than are ESX hosts.

In Veeam is possible to set encryption for transport between components, so between proxy and repository, where is data flow.

If Proxy Server is on the same ESX host, there is no option for attack as data are grabbing directly datastore, which is attached on that ESX host.

Question came, if Proxy Server is located on ESX host(1) and customer VM is located on another ESX host(2). We have opened this question to VMware (now Broadcom) in Germany.

They have been confirmed, that if encryption is not in place, then there is possible attack, because data flow is physically from one ESX hosts to another ESX host.

Their suggestion was to enable “vSAN Data In-Transport Encryption,” which we have been used to fulfill requirements for highest level of audit (in Germany Audit C5), which is required for companies with sensitive data.

Thank you for your reply ​@makacmar .

So, this “limitation” is only for vSan environments, correct?

It’s hot-add transport specific, which is working for VMS, NFS, vSAN datastores.