No connection could be made because the target machine actively refused it 10005

Thank you for your response.

The Azure matter is a red herring. Sorry for any confusion I have caused. I’ll clarify.

The backup server has LAN IP 192.1YY.1.62/24 and is domain joined on untagged on VLAN 1.

The backup server is a VM on the physical host with IP 192.1YY.1.3/24 and is domain joined on VLAN 1.

All other VMs are also domain joined with IP in range 192.1YY.1.0/24 and are untagged on VLAN 1.

All physical machines are also domain joined with IP in the range 192.1YY.1.0/24 and are untagged on VLAN 1.

All of the VMs and physical machines can ping and nslookup successfully. They all have domain network discovery set to on.

In the 192.1YY.1.0/24 network all physical and virtual devices are connected at Layer 2, so there are no firewalls and Layer 3 devices in the network path between devices. All of the devices are Microsoft (Server 2022 or Windows 10 22H2) and have Windows Defender Advanced Firewall with Veeam deployed inbound and outbound rules. I have even specifically added rules inbound and outbound for port 10005 on the backup server and each of the physical hosts I have tried to back up with agents. 

This picture shows the registry key “Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam EndPoint Backup” with the only confusing entry being the SqlServerName which is “(localdb)” but the real SQL server is 192.1YY.1.58/24.

Short of installing WireShark, how can I explore whether there is a silent firewall drop? I’d still like to know how the Agent is configured, and whether it gets settings from some fort of configuration file.

Hi @DrThirsty -

Did you attempt to disable Windows Firewall on the client devices to see if it is indeed the issue? Do you have UAC enabled anywhere? This would also cause a problem. The following are ports VBR uses with Win Agent:

https://helpcenter.veeam.com/docs/agentforwindows/userguide/ports.html?ver=60

Veeam also has a KB of that very error DrThirsty. Give it a look over and try the steps Veeam suggests to see if any resolve your issue:

https://www.veeam.com/kb4557

Hope that helps.

Thank you everyone, I will be following your suggestions this afternoon.

Sorry for any delay in replying to your postings. I am in the UK and it is currently British Summer Time (UTC/GMT+1) so time zone differences may sometimes apparently delay my replies and responses.

I had some thoughts as well. The agents are successfully deployed from server to endpoint (client) and rescans work fine. So there is connection from server to client. The client can connect to the server ports 80, 443, 445 and many others, but not port 10005 although the port is listening. Both server and client are running Sophos Intercept X antivirus and I shall take a look at the Sophos logs to see whether it is causing the problems. Are there any known issues with Veeam 12 and Sophos AV, or any sources of articles on that topic?

Hey! Fellow Brit here 👋

Id expect Sophos/Intercept-X to impact performance more than anything else, KB1999 (https://www.veeam.com/kb1999) has the details of required/recommended exclusions so I would check those. Only way I’d see intercept x getting involved is if you’re using any of the network protection options that restrict client to client communication when a client is unhealthy.

Id try the PowerShell command from the KB article others have shared to confirm that the 10005 port is bound to all interfaces not just randomly your WAN/DMZ one. I wouldn’t expect this but again just looking for clear explanations.

I’d also suggest checking that your windows firewall rules aren’t scoped too narrow such as explicit remote/local IP addresses only for port 10005, or even bound to the wrong binary, I’d start with your VBR server as you said this is common across multiple endpoints.

Also, I completely understand not wanting to install wireshark on all your endpoints and VBR, you can take a PCAP without it (kinda). You can use “netsh trace start” with some other parameter options to generate an ETL file and then use etl2pcapng to convert to something readable by wireshark: https://github.com/microsoft/etl2pcapng/releases

Hi Experts,

I have followed https://www.veeam.com/kb1999 instructions, adding exclusions to Sophos Intercept X for the backup server. That made no difference.

Here is the result of netstat -na | findstr “10005” which I think shows all NICs listening and that the Veeam.BackupService is bound to the port.

Here’s all of the automatically installed Windows Defender Advanced Firewall inbound rules created when Veeam is installed, plus a specific inbound for port 10005.

Here’s the latest result of Test-NetConnection from a physical endpoint with the agent successfully installed.

 I’m next going to try some sort of WireShark-ing… Any further suggestions most welcomed. Thanks in advance.

Hi @DrThirsty -

From the Global/Main Menu in the Console, you can try to set your Preferred Network to see if that works for you:

https://helpcenter.veeam.com/docs/backup/vsphere/select_backup_network.html?zoom_highlight=preferred+network&ver=120

Investigating further, ALL of the Veeam ports (8543, 9402, 20443, 33034,33035, 9401,9419… all of them) are bound to the WAN NIC (i.e. the WRONG) NIC. 

I have tried to specify the Preferred Network in the Veeam management console. Made no difference, even after restarting all the Veeam services.

This must be something that is configured at the time of installation.

I can find no relevant references to port 10005 in the registry. So, there must be a setup or configuration file (.config or .xml or something else) in which the bindings are defined at the time of installation. Any thoughts?

My (..I really don’t want to do this unless I must...) action of last resort is to completely uninstall Veeam, delete all the registry keys, delete all of the Veeam folders and the config in the AppData\Local\Veeam folder of the installation account. Disable the WAN NIC, then clean install Veeam to see if it binds to the (correct) LAN NIC.

There are no “deny” rules on any firewalls.

Does Veeam have something like a hosts or routing table somewhere? Everything is pointing to the wrong NIC.

I can’t be the first person to have tripped into this issue. I am running out of ideas...

Hi @coolsport00 

Thanks for confirming that my action of last resort may be a way to fix this. I am currently using a 30 day evaluation license, so don’t know whether I am in a position to raise a ticket with Veeam Support. I will look into this.

I should also mention, that this is all being done in my company’s Test Environment (not the Production Environment). Our intention is to evaluate Veeam and if it does what we need, then we would be buying about 10x full licenses; one for HQ, one for R&D Centre, one for each of the Manufacturing Hubs etc. Each location has a dual NIC DMZ server with a LAN NIC and a WAN NIC where the WAN NIC sits behind firewalls and load balancers to connect to the internet and, particularly, to Azure storage blobs. We have to be able to install Veeam onto these DMZ servers without disabling the WAN NICs because we need the WAN NIC up so that we can IKEv2 VPN connect through the DMZ tunnel between the IT Department at HQ and all the other locations…

That’s why I am persisting with investigations in the registry and in the Veeam application folders. If it is possible to modify a .reg key or a .config file to fix a binding, we can create a script to do that overnight without disrupting operations.

Also, though we do try to help with issues Community members inquire about here, please keep in mind we are *not* Support. We only offer suggestions. Just FYI 😊

Hi @DrThirsty - completely understand. I just wanted to make sure of that though...some don’t realize this 😊

Hi @DrThirsty -

Thank you for sharing what worked for you. Again, there may be a cleaner way to do what you want by contacting Support. At the very least, I would recommend you going over to the Forum to share your dilemma with the Product Mgmt team. They may have a better solution for you. They’re pretty good at responding to queries.

Best.