Veeam Agents with VPN addresses

[TitaniumCoder477]

Support tickets 04268727 and 04291985

Scenario:

** All IP addresses are dynamic; no static leases. **

Workstation protection group:
- All assets remain on company LAN (192.168.0.0/24)
- Assets only ever have one IP address
- An asset's IP address has a low probability of change due to lease renewal

Laptop protection group
- All assets float between company LAN (192.168.0.0/24) and other environments, such as end user home, coffee house, client sites, etc.
- Assets will often have two IP addresses: (1) the local LAN address that the variable environment provides and (2) the VPN address when the VPN is connected
- The probability that an asset's company LAN IP is recycled back into the pool is high because of the mobility of the device
- The probability that an asset's VPN address is recycled back into the pool is also high because of the probability the asset will NOT be connected to the VPN at any given time
- The probability that an asset will have the same logical IP address as another asset at a completely separate physical location is high because many consumer routers use the same networks (i.e. 192.168.1.0/24 in this instance)

Protection groups were targeting device hostnames but are now targeting AD group membership; unfortunately both methods exhibit the problem described below.

Problem:

Because Veeam tracks ALL the IP addresses of an asset in a protection group, there is high probability for Veeam to confuse one asset with another. This has proven to be true on two separate occasions for us. On one occasion, we were attempting to backup providers' laptops; they floated between medical offices on different routable networks and also connected through VPN; this presented a high probability of devices having each other's IP addresses at varying times, and Veeam was unable to track this reliably. We ended up having to abandon ship on using Veeam to backup these endpoints because backup chains were all too often mixed up. The second occasion is the one I'm dealing with at present and to which the aforementioned case numbers pertain. In this case, the problem is more simplistic:
1. One user has a workstation that is permanently offsite; the asset has a local LAN IP address from his consumer router (192.168.1.x) and occasionally has a VPN address
2. However, because the VPN address is recycled into the pool, Veeam gets confused about once a week
3. When the Protection Group runs (about 30 minutes before the job runs), Veeam scans the laptop which is included in the protection group and which previous had VPN address 10.212.134.x; however, how that VPN address belongs to this workstation which is NOT part of any protection group
4. Veeam gets confused and installs the agent on the workstation
5. When the backup job runs, the workstation, which is not part of any protection group, attempts to backup across the VPN tunnel

Solution:

Veeam protection groups need to have a granular option whereby a specific network can be required for an asset to be considered "online." For example, in the present scenario, I would configure the laptop protection group to only consider an asset online if it has a company LAN IP address. This would result in Veeam never considering it online even if it's reachable with a VPN address. This would result in the asset never backing up across the VPN. And this would solve the problem described above.

Now, this solution would only solve my issues because I don't actually want to backup the laptops across the VPN. I am sure there are Veeam customers that actually DO want to backup laptops across a VPN, in which case, another solution would need to be designed so that Veeam can better track devices that have dynamic IP addresses.

I hope this lengthy post has adequately detailed a realistic world scenario that may or may not be visible to Veeam at the moment. It is certainly something I am running into and would probably run into more often if more of our clients wanted us to backup end user machines which inherently rely on dynamic IP addresses. This entire post is completely irrelevant for server assets because they, in most cases, would always have a static IP address.

UPDATE:
Another, potentially better, solution would be for the Veeam protection group scan job to ALWAYS compare the expected NAME with actual NAME. For example, in my scenario, it would see that WORK42 != LAPTOP123 and therefore cannot be the same asset. Therefore, even if the VPN address that LAPTOP123 previous had is now used by WORK42, Veeam would NOT proceed with installing the agent. Rather, it would conclude that LAPTOP123 is offline.

[Dima P.]

Hello James,

Thank you for your feedback, at the moment I do not have any comments to share. We will discuss your issue with the team and I'll get back to you. Cheers!

[gparker]

Hi, we are potentially facing the same issue with one of our customers....They want to backup their fleet of user PCs, some of which are on the local LAN and some are mobile and connect in to their VPN. So as James said, we either need the option "to have a granular option whereby a specific network can be required for an asset to be considered "online." For example, in the present scenario, I would configure the laptop protection group to only consider an asset online if it has a company LAN IP address. This would result in Veeam never considering it online even if it's reachable with a VPN address. This would result in the asset never backing up across the VPN", or if we have to backup mobile PCs connected to the VPN "another solution would need to be designed so that Veeam can better track devices that have dynamic IP addresses".

[Vitaliy S.]

Let me quickly chime in here. Sorry If I misunderstood something, but why not consider using Veeam Cloud Connect repositories in conjunction with VSCP ( for agent management) as a target for these computers?

In this case, you won't actually care what IP address is assigned to the agent managed by the VSPC and will always have a backup of the mobile laptop, right?

[TitaniumCoder477]

That would only work for "managed" agents which we, as a service provider would manage. I am not fully onboard with using VSPC for this large of management yet, as there are still many half-baked areas of that software. (Case and point, DB table inflating and consuming space due to no truncation of management agent update failures--yeah, this has bitten me twice now) Besides, if a client has a BNR server, we will always default to managing ALL the asset protection through that centralized server. I cannot think of a valid use case in which we would want to have to manage server jobs through the tenant BNR and workstation jobs through VSPC.

UPDATE: I guess if there was a sub-set of laptops that were indefinitely in the field, then such would be a use case for managing them through VSPC. But currently, we do not scope any desktops/laptops for backups to our cloud. The few clients of ours that even want to backup end user devices (Primary use cases: They DON'T have and want a file server with centralized storage, or a BMR would save them time over reinstalling tons of apps on power user machines) only want local backups; they do not care about 3-2-1 for these devices (while we require 3-2-1 for production server assets under our management). So backing up these devices directly to our cloud, even for laptops indefinitely in the field, is very unlikely to be desired or implemented. It would be more likely that the VSPC managed job would point the backups to a locally attached USB drive.

[Vitaliy S.]

Case and point, DB table inflating and consuming space due to no truncation of management agent update failures--yeah, this has bitten me twice now

Did our support confirm the issue and provide you the hotfix? Just want to make sure it is fixed in the next major release.

cannot think of a valid use case in which we would want to have to manage server jobs through the tenant BNR and workstation jobs through VSPC.

My suggestion was just based on your post above, as it should allow you to avoid all these issues you're having now with IP addresses and protection groups.

UPDATE: I guess if there was a sub-set of laptops that were indefinitely in the field, then such would be a use case for managing them through VSPC.

Yep, many of the MSPs I talk to are using VSPC for workloads that are always "traveling/in the field" while all servers and failover cluster backups (that have no issues with IPs as you've described) are managed by the local Veeam B&R server. So it is a combination of two solutions.

[TitaniumCoder477]

Support has identified the problem and is working with developers to ensure that failing management agent updates have some sort of log truncation to avoid inflating the table infinitely. That said, the immediate solution for us was to address the endpoints that were failing to update the management agents.

That use case might come up in the future when a split management solution would definitely be useful. My original issue for this post though is specifically endpoints that are not offsite indefinitely, the common laptop that comes to the office a few days a week and is in the field or at home other days, etc. In this case, the clients would rather backup consistently when in office than pay for additional cost of managed agent and backup to cloud etc. Hence, it would be good to have the functionality build into BNR that we've discussed in this post.

[Vitaliy S.]

Hi James,

Support has identified the problem and is working with developers to ensure that failing management agent updates have some sort of log truncation to avoid inflating the table infinitely. That said, the immediate solution for us was to address the endpoints that were failing to update the management agents.

Yes, that's an unfortunate event. I have reviewed all related pull requests in our code tracking system, so not only was this issue fixed but also we have optimized the upgrade procedure for the management agent. So hopefully, you will not see this issue ever again.

That use case might come up in the future when a split management solution would definitely be useful. My original issue for this post though is specifically endpoints that are not offsite indefinitely, the common laptop that comes to the office a few days a week and is in the field or at home other days, etc. In this case, the clients would rather backup consistently when in office than pay for additional cost of managed agent and backup to cloud etc. Hence, it would be good to have the functionality build into BNR that we've discussed in this post.

Yes, since Dima (the PM for this feature/product) is in this thread, then this FR will be taken into account when planning new releases.

Thanks!

[TitaniumCoder477]

Perfect, thanks! I appreciate Veeam's forward progress mentality!