I have finally found some spare time and I decided to test Veeam Backup & Replication on Linux v13 [Beta] in my home lab. It is BETA, so it is good to test it and be prepared for the final release, even anything can change before the final release is available.
There is clear information that update and upgrade into newer versions will not be possible, but I'm really curious how Veeam transition from Windows to Linux is doing.
Anyway, let's test it and get the feeling about the Veeam future with Linux based systems.
Planing
Veeam Linux Appliance installation is done via booting DVD ISO image and console interaction. It can be installed in virtual or physical machine. Using Virtual Machine has multiple benefits. The important requirement is, that the server (VM in my case) must have at least two 256 GB disks, otherwise the installation failed. That's why I use 270 GB disks to be sure installation succeed.
My VBR VM Specification:
- 2x vCPU
- 16 GB RAM
- OS Disk: 270 GB (thin)
- Other Disk: 270 GB (thin)
- 1x vNIC
- OS Type: Rocky Linux 9.2
Installation
Installation is relatively OK. Here are some interesting details:
- Veeam Admin has username veeamadmin and the length of his password must be more than 15 characters.
- Veeam Admin has to use MFA (Multi-Factor Authentication). For example Google Auth. During the installation of Veeam Appliance there is QR code to scan into your MFA and successful authentication is validated.
- There is another role. Veeam Security Office (username veeamsso) which is most probably intended for double person verification of some critical tasks.
Management
Host Management is accessible via HTTPS on port 10443, which is n my case https://vbr.home.uw.cz:10443
Main Control Panel is accessible via HTTPS on standard port 443, which is in my case https://vbr.home.uw.cz:443
You can also manage the host via console TUI as visible on screenshot below.
![]() |
VBR console TUI to manage the host |
After installation I was able to ping the VBR host, but ports 443 and 10443 were not available.
Troubleshooting #1
Remember, this is BETA, so there could be bugs. Let's do some network diagnostics.
![]() |
After installation ping was working, but ports 443 and 10443 not |
Reboot did not helped. It is time for serious troubleshooting.
SSH is not available, so only way is to use console. I realized, that console TUI is sometimes badly responsive and does not react to keyboard. However, I was able to login and double check that HOST MANAGEMENT WEB UI is up and running.
![]() |
Host Management Web UI is running. |
Why I cannot access Web UI? If service is running and system is reachable over network (ping), it must be something like firewall. I must login into shell for further troubleshooting. After SHELL is enabled, there is message ... "AWAITING SECURITY OFFICER APPROVAL". I'm also Security Officer, so how can I approve it? I think, it does not work in BETA yet, because I can use for example ALT+F6 to switch on another VTY (Virtual Terminal) and login to VBR console without any approval.
VBR Linux Appliance is based on Rocky Linux 9.2, which is Red Hat linux flavor with systemd.
User veeamadmin is regular user with UID 1001 and it is not in sudoers, therefore it cannot do linux administration of VBR appliance system.
There is no nc, wget or fetch utilities to test if ports 443 and 10443 are available via localhost.
Fortunately enough, there is curl, so I was able to download portable binary file of nc.
curl -L -o mync https://github.com/H74N/netcat-binaries/raw/refs/heads/master/build/nc64
and try to run
However, I was not able to run mync binary because all directories where I have access are mounted with noexec option. Period. I'm not able to test if web services are accessible from localhost.
I also tried to access localhost:443 and localhost:10443 by curl and telnet, but it does not work, so it looks like there is no service listening on these ports. See screenshot below.
![]() |
Cannot connect to port 443 and 10433 on localhost |
When I use ss (socket statistics dumper), to see what process is listening there, it does not return anything on ports 10443 and 443.
ss -tulnp | grep 10443
ss -tulnp | grep 443
However, the reason it does not return any process listening on these ports can be due to not having root permissions.
In terms of systemd, I checked directories
- /lib/systemd
- there is nothing Veeam specific
- /etc/systemd/system
- there is veeampgsql.service which is just symbolic link to /usr/lib/systemd where is default postgresql service
- veeamguestinteraction.service which is probably not interesting
- /run/systemd/units
- veeam services are visible in screenshot below
![]() |
VBR Appliance systemd services related to Veeam |
The most relevant service is veeamwebsvc but when checking the status (systemctl status veeamwebsvc), it is running without any issue. That's what reports TUI as well.
Firewall is managed by iptables, but I have no permission to list firewall rules (iptables -L -n)
To be honest, I do not have any other ideas how to troubleshoot this issue, so I will try reinstall it from scratch because other folks reporting successful deployments and my environment is pretty standard so there is no reason it should not work.
Troubleshooting #2 (user root hacked)
Based on Jan Prucha suggestion in comment, I reset the Root Password by leveraging rd.break. So, now I have root access into the Veeam VBR Linux system and I was able to run command ...
ss -tulnp
as root and identify what process is listening on ports 443 and 10443. What was my surprise there is no process listening on these ports? See. screenshot below.
![]() |
There is no process listening on ports 443 and 10443 |
That's the root cause why I cannot access VBR web management. Nothing is listening on ports where web management should run. Why there is nothing running? Who knows? I have also listed all processes in the linux system and I have not found any process which should be responsible for Web management.
I have also checked firewall configuration by command ...
iptables -L -n
... and firewall is activated and running but not blocking anything and accept everything as clearly visible on next screenshot.
![]() |
Firewall is active but not blocking anything |
Any other idea for further troubleshooting? Now I have root access to the system.
Summary (so far)
If redeployment will not be successful and I would end up in the same situation, I will try to open this topis in Veeam Community Forum.
Stay tuned.
3 comments:
Chybějící práva pro běh iptables, hmmmm. Co zkusit standardní "hacknutí root účtu" (pomocí rd.break při startu), jak se to dělá na každé RHEL certifikační zkoušce? To by Vás mohlo posunout dál v investigace.
Aktuálně si nemyslím, že by to bylo firewallem, protože ani curl na localhost nic nevrací, takže se to chová fakt divně. Služby vypadají , že běží, ale na HTTPS request se nic nevrací.
Každopádně hacknout se na roota je celkem dobrý nápad a mohl bych zkusit adresnější troubleshooting s rootovskými právy.
Jdu to zkusit a dám vědět.
Tak heslo na roota jsem zmenil a mam root prava ve Veeam Linux Appliance.
Rozsiril jsem blog post o sekci Troubleshooting #2 (user root hacked), kde jsem zjistil, ze firewall je sice aktivni, ale vsechno propousti a nic neblokuje, takze firewallem to nebude.
Take jsem zjistil, ze na portech, kde by mel byt web management (443, 10443) nic nebezi a neposloucha, takze to logicky nemuze fungovat.
Proc je to v takovemto stavu nevim a po tydenni dovolene, (takze az v cervenci) se k tomuto temat vratim.
Nejaky dalsi tip na troubleshooting?
Post a Comment