Firewalld ports opened on multiple zones. Also, does Veeam have a proxy for end-user traffic?

[rwatt]

Case #06296563

I'm sure it's the way I'm presenting the questions and information, but my case isn't getting me answers.

First question, does Veeam offer a product or service that would allow client-end desktop traffic reach the VBR servers without giving the clients direct open ports to the VBR servers? We are wanting to explore backing up sensitive desktop computers of some employees and reading over the documentation it seems like those desktop agents require a lot of firewall ports to be opened directly to various VBR servers. I understand that, but I would not like to do that. Is there a proxy role or another Veeam product that would allow us to funnel such traffic through it as a middle-man between users and VBR?

Regarding the firewalld zones question, we have an RHEL9 server running both the proxy and repository roles. Since it's RHEL9, I'm trying to work within firewalld zones. I've got a "veeam" zone that I've added the source IPs of the VBR server, other proxies and repos, as well as the SQL servers for transaction logs). Per https://helpcenter.veeam.com/docs/backu ... ml?ver=120 and https://community.veeam.com/script-libr ... zones-5064 I've specified "FirewalldZones=veeam" in the following files:

• /opt/veeam/transport/VeeamTransportConfig
• /etc/VeeamNetConfig

Code: Select all

# grep -B12 FirewalldZones /var/log/VeeamBackup/VeeamEnvironmentSvc.log
[12.09.2023 22:45:48.318] <139687746580928> tpl      | Loading transport options.
[12.09.2023 22:45:48.318] <139687746580928>          | /opt/veeam/transport/VeeamTransportConfig was found.
[12.09.2023 22:45:48.318] <139687746580928> tpl      | Non-default option [AgentOrphanTimeoutSec] : [1200]
[12.09.2023 22:45:48.318] <139687746580928> tpl      | Non-default option [AgentHangTimeoutSec] : [3600]
[12.09.2023 22:45:48.318] <139687746580928> tpl      | Non-default option [AgentShutdownTimeoutSec] : [60]
[12.09.2023 22:45:48.318] <139687746580928> tpl      | Non-default option [FipsMode] : [true]
[12.09.2023 22:45:48.318] <139687746580928> tpl      | Non-default option [MaxLogSize] : [15728640]
[12.09.2023 22:45:48.318] <139687746580928> tpl      | Non-default option [MaxLogCount] : [10]
[12.09.2023 22:45:48.318] <139687746580928> tpl      | Non-default option [ServicePort] : [6162]
[12.09.2023 22:45:48.318] <139687746580928> tpl      | Non-default option [ServiceUser] : [root]
[12.09.2023 22:45:48.318] <139687746580928> tpl      | Non-default option [BaseLogDirectory] : [/var/log/VeeamBackup]
[12.09.2023 22:45:48.318] <139687746580928> tpl      | Non-default option [IptablesAutoupdate] : [false]
[12.09.2023 22:45:48.318] <139687746580928> tpl      | Non-default option [FirewalldZones] : [veeam]

After restarting the Veeam services, you can verify in the log that it recognizes the proper zone. Once traffic starts flowing, ports start getting added to the "veeam" zone. However, I noticed that ports 6160/tcp and 6162/tcp get added to two other zones: "public" and a self-created "management" zone. No Veeam IPs exist in those zones. The "management" zone has IPs for sysadmins for cockpit and ssh. The "public" zone has the interface only with no IPs.

I'm trying to understand the behavior, because my expectation is that specifying the "veeam" zone in the files above it should limit where Veeam opens ports.

Here's the "veeam" zone without the IPs (6160/tcp 6162/tcp 2501/tcp 2504/tcp were added dynamically by the Veeam services):

Code: Select all

veeam (active)
  target: DROP
  icmp-block-inversion: yes
  interfaces:
  sources: [removed 5 IPs]
  services: ssh
  ports: 6160/tcp 6162/tcp 2501/tcp 2504/tcp
  protocols:
  forward: no
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks: echo-reply echo-request
  rich rules:

And this is what I'm seeing on the "management" zone:

Code: Select all

management (active)
  target: default
  icmp-block-inversion: yes
  interfaces:
  sources: [removed IPs]
  services: cockpit ssh
  ports: 6160/tcp 6162/tcp
  protocols:
  forward: no
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks: echo-reply echo-request
  rich rules:

[Mildur]

Hi Richard

Can you please check your case number again? You have posted your Contract Number (#02).
Case Number should start with #06.

First question, does Veeam offer a product or service that would allow client-end desktop traffic reach the VBR servers without giving the clients direct open ports to the VBR servers? We are wanting to explore backing up sensitive desktop computers of some employees and reading over the documentation it seems like those desktop agents require a lot of firewall ports to be opened directly to various VBR servers. I understand that, but I would not like to do that. Is there a proxy role or another Veeam product that would allow us to funnel such traffic through it as a middle-man between users and VBR?

Our Agents needs to be able to talk to the backup server in order to work. For service provider and larger customer, we provide a solution called Veeam Cloud Connect and Veeam Service Provider Console.
The Veeam Agent only talks to the Veeam Cloud Connect Gateway. Management of the Veeam Agent is completely done within the Veeam Service Provider Console.
A Cloud Connect Gateway behaves like a proxy server between the agent and the management server. On the machine, Veeam Agent and a management agent are installed. The management agent will talk to the Service Provider Console through the Cloud Connect Gateway. Cloud Connect can also be your backup target for the Agent backups. In that case, backup traffic will also transferred through the Cloud Connect Gateway.
Another benefit of this solution, no VPNs are required. The Cloud Connect Gateway can be made available over the internet.

Best,
Fabian

[rwatt]

Sorry about that. It's #06296563. I don't seem to be able to edit the original post.

Thanks for that suggestion about Veeam Cloud Connect and Veeam Service Provider Console. I'll check those out.

[Mildur]

Thank you, I have updated your post.

Best,
Fabian