Why is the Proxmox Worker Proxy So Different?

[MrGrim]

I'm evaluating Veeam Proxmox support as part of efforts to eliminate Broadcom from all aspects of my life professional and personal, and I've started on a low stakes deployment to some personal systems with community edition. All was going pretty well until I got to the Proxmox worker setup.

I was expecting it to work like everything else in Veeam. I setup a Linux server and add it to the managed server list, then I deploy the Proxmox worker role to it. To my surprise, that's not at all how it worked. It's odd, but I persisted.

My setup is a VBR server behind a NAT connecting to proxies on various leased hosts on the internet. When using the bog standard Linux managed server there is the "Run server on this side" option to make sure VBR always connects to the proxy instead of the other way around, but as discussed Proxmox Workers are not managed Linux servers, and this option is not present. No problem, I figured. Veeam has always operated using DNS names so I'll just make sure I have set up a public DNS record for the VBR server name and forward the appropriate ports.

When that didn't work I started monitoring traffic from the worker only to discover it's trying to connect to the VBR servers internal IP address. So, instead of resolving the name like _every other part of Veeam does_, this particular connection acts more like a FTP server and passes the IP for the reverse connection. That's... terrible. Why isn't it resolving the VBR servers name to find the correct IP to use? I'm at a wall. To get past this I'd need to do customized NAT rules under Proxmox to forcefully rewrite the destination to the correct IP which would be a management nightmare.

This whole setup is such a major departure from how Veeam operates. It loses all of the flexibility and power of the architecture. Please tell me a more standard deployment scenario is in the works. This is not something I can use either personally or professionally as it stands.

[MrGrim]

For what it's worth, a mess of NAT rules on both sides did finally get this going. I really hope this isn't necessary in the future.

[Mildur]

Hi Michael,

As outlined in our Help Center, the Proxmox VE server requires a direct IP connection to the backup server. NAT connections are not supported (Considerations and Limitations):

The Proxmox VE server must be able to establish a direct IP connection to the backup server. Connections through NAT gateways are not supported.

I setup a Linux server and add it to the managed server list, then I deploy the Proxmox worker role to it.

The worker role is not deployed to a managed server. Instead, you must select a Proxmox host, and the backup server will deploy a new Linux based virtual machine to that Proxmox host and use it as a worker.

Best regards,
Fabian

[MrGrim]

Yes I understand. My question is why was this approach taken? It has so many limitations but no apparent advantages. I'm struggling to think of a technical justification or requirement.

Pros:

* ... I suppose it's mostly automatic?

Cons:

* Cannot transfer years of knowledge from the managed server + agent approach.
* Cannot use organization templates and SOPs for hardened and optimized systems. E.g.
* Unable to install IDS/IPS solution on appliance.
* Unable to apply tunables like TCP buffer or congestion control algorithm, very important for good bandwidth over high latency high throughput connections.
* Unable to manage log forwarding to SIEM.
* Honestly could go on a while here so let's cut it there.
* Restricted capabilities due to needing to redo years of lessons learned from prior approach, e.g. the "Run server on this side" option.

An appliance option I'm sure is favored and works great for some users, but it shouldn't replace the agent on a managed server approach using the tried and true Veeam services. I would ask Veeam consider this going forward. As it is, it's a problem when planning for a migration to Proxmox from VMware.