Major Issues After Upgrading to Veeam V13: Port 443 Conflict

[n.koch]

Hello everyone,

We are an MSP and have over 50 VBR installations in use and have been with Veeam for over 8 years.
I have never had so many problems with Veeam updates from one version to the next.
Not only are there problems with the updates from V12 to V13, but there are also other problems with App-Aware. I will have to stop rolling out the updates to V13 because it is causing almost nothing but problems.

My current problem is that V13 now requires port 443.
I have updated the VBR on a physical server and port 443 is already occupied by an important application at the customer's site. I cannot change that.

Veeam Support advised me to only enable port 443 for the update, which I did. However, after the update, VBR does not work when port 443 is occupied again by another application.

Why did the Veeam programmers assume that port 443 was not already occupied on the customer's servers? I don't understand that.

I guess I'll have to downgrade to V12 or uninstall V13 and install Veeam Agent on the server instead.
Are there any plans to allow users to specify a different port in Veeam during the update in the future?

Veeam Support - Case # 07910543

Thank you.

[Gostev]

Hi, Niko. Yes we plan to allow this in the future if there's big demand.

Generally we do not expect the backup server to be shared with 3rd party apps as that commonly leads to unpredictable behavior. And especially we don't expect there would be 3rd party apps accepting incoming connections, as this is the recipe for security breaches resulting in complete take over of the backup server, which as you know contains keys to the entire production environment. Therefore, it's considered a very bad deployment practice.

Thanks

[n.koch]

Hello Gostev,

Thank you for your quick response.

Many customers only have a single server because they cannot afford an extra backup server. Unfortunately, this means that some customers have to install Veeam on the domain controller, as this is still better than having no backups at all.

In this case, what would make more sense: downgrading to V12 or switching to Veeam Agent V13? Assuming that Veeam Agent V13 does not require port 443.

[Gostev]

For a single server backup, installing VBR is an overkill of course, so I would go with VAW every time.

[n.koch]

Thanks for the feedback. I need to continue the existing backup chains from V12 here. Is it possible to continue the backup chains from V12 with VAW?

Do I still need to submit an official feature request regarding changing port 443 or have you already taken care of that?

[Dima P.]

Hello NiKo,

The request is already noted, thank you! Out of curiosity, could you share which applications are blocking port 443 on your customers’ installations? Thank you!

[n.koch]

Thank you.

It is the Timemaster Application (This is time tracking software, time tracking is mandatory in Germany)

[Gostev]

Strange, we have a huge R&D office in Germany and I don't believe we're doing anything like it... at least not with this software I guess.

No, it's not possible to continue backup chains between products unfortunately.

[Rumple]

Unfortunately, this means that some customers have to install Veeam on the domain controller, as this is still better than having no backups at all.

I can't agree with this at all....today, 75% of the point of backups is to recover WHEN you are compromised and putting it on a DC (or any other domain joined server basically eliminates any change at recovery.
Restoring files or a VM from other events is almost an afterthought now. Your clients have a better chance at getting ransomwared then needing to restore due to hardware or software issues.

This is a very simple solve. Put in a desktop with SSD/storage drives in it and leave it in a workgroup with all inbound traffic blocked (and connect it to a cloud immutable storage. It's a very cheap, but very effective solve to enable recovery.

Putting VBR on domain, and on a DC (or any other server sharing services) is going to literally result in a compromise not only encrypting your environment but encrypting your backups as well.

[ftravinsky]

Once I was working in Service Provider for SMBs, we were deploying NAS for Samba backup storage and VBR as a VM.
DC and/or any 3rd party apps better be a dedicated VMs as well. Virtualization!

Seems your all-in-one setup is far from basics:
https://www.veeam.com/blog/321-backup-rule.html

IMHO, with v13 released your best cheapest shot is running a dedicated PC with Linux Hardened Appliance.
Or selling users Cloud backups with just VAW on-premise.



However I concur with a request to change the default port TCP:443.
As a lousy security measure Veeam Web interface should be able to run on a non-standard port.

[GrandAdmiral]

Hello NiKo,

The request is already noted, thank you! Out of curiosity, could you share which applications are blocking port 443 on your customers’ installations? Thank you!

In my case the application blocking Veeam is... Veeam .

We have a dedicated VM for our SP Cloud Connect instance with VSPC presently occupying 443.

[Dima P.]

Hi Benjamin,

Thank you for the feedback! With VSPC you can modify the port in the IIS settings, does that work?

[Dagr]

Had the same issue on an instance of Enterprise Manager, all due to the IIS server's Default web page where using port 443

Would appreciate an option to set a new port if 443 is detected as "in use"

[johnwatson]

You will also run into this issue when your host server is also a Hyper-V Replication server as well as VBR server. You will not be able to upgrade from VBR 12 to 13 until you change ports.

Although, its an easy fix.

Step 1: Hyper-V Setting -> Replication Configuration -> Change Specify the Port from 443 to something else

Step 2: For each VM on each host and Replica Server -> Settings -> Replication -> Change Replica server Port from 443 to what was set in Step 1.
This step will prevent you having to delete and re-replicate the VM

[ENBS]

@johnwatson: Had the same issue. Netstat only listed "PID 4: SYSTEM", took me quit a while to figure out that it was Hyperv-Replica.

[Dima P.]

Hello folks,

Thank you for sharing the details! That helps a lot!

Would appreciate an option to set a new port if 443 is detected as "in use"

We are investigating this possibility for future versions. Thank you!

[PhilippKE]

You will also run into this issue when your host server is also a Hyper-V Replication server as well as VBR server. You will not be able to upgrade from VBR 12 to 13 until you change ports.

Although, its an easy fix.

Step 1: Hyper-V Setting -> Replication Configuration -> Change Specify the Port from 443 to something else

Step 2: For each VM on each host and Replica Server -> Settings -> Replication -> Change Replica server Port from 443 to what was set in Step 1.
This step will prevent you having to delete and re-replicate the VM

We have several Veeam installations, each currently running Hyper-V without replication. Port 443 appears to be in use and cannot be changed without reconfiguring replication.

Surely there must be another way to resolve this besides modifying the entire Hyper-V configuration?

[GrandAdmiral]

Hi Benjamin,

Thank you for the feedback! With VSPC you can modify the port in the IIS settings, does that work?

Hi Dima

Yes that's worked for the Veeam conflict but I've also had to remove our backup ADFS endpoint since that can't have it's port reassigned. Most of our SMB customers using ADFS don't have a backup endpoint and therefore can't upgrade to V13 until the B&R port can be changed.