Name Resolution Veeam 9.5 Update 4

[PhilippS_BIT]

Hi everyone,

after Updating to U4 i have experienced a strange change in Name Resolution from Veeam Components.
We have a tricky network setup in place and the Veeam mount Services needs to connect to a NATed WAN IP of the Veeam B&R Server.
This is implemented with a hosts file.

With Update 4 Veeam only uses IP Addresses an no hostnames to reach its components. After a rollback to Update 3a everything was working again.

I have created a support ticket but now solutions so far.
CaseID 03376778

Any clues?

[HannesK]

Hello,
as there are quite many "tricky NAT" setup options... could you draw a picture?

Just guessing, but is it possible that somehow the "run server on this side" checkbox is not set anymore? Or if you never used it, could this maybe help to solve your problem?


Best regards,
Hannes

[PhilippS_BIT]

Hi there,

thanks for the reply.
I try to explain the setup. Every side has a public IP NATed to either the Veeam VBR Server and to a JumpHost in the Customer Environment.
On the Customer Side there is a Veeam Console, Mount Srv and all Veeam Explorers installed. This JumpHost also works as Guest Interaction Proxy.
On the customer side the dns is configured to resolve the Veeam Servers Hostname to it´s public IP which is NATed to his private IP.

In case of a file restore the Veeam Console on the JumpHost is able to mount the Backupfile and initiate the restore.

After Upgrading to Update 4, the restore process fails because the JumpHost tries to connect to the Veeam VBR Server with it private IP. Thats because it does not resolve the hostname to the public IP.
This breaks the whole concept of isolated customer environments.

[dtang]

Hi Philipp,
The technical case is currently being reviewed internally according to the last mail I've sent you. Please allow us some time for log review and follow-up. As soon as you will receive new findings you can update the thread. I will provide to our colleagues the diagram that you posted above.

[HannesK]

thanks for the picture.

Just to make sure: did you try the checkbox I mentioned before?

[PhilippS_BIT]

@Hannes: No, the checkbox was not ticked. Do i need to set this for the Jumhost in this case?

@dtang: Thanks for the reply. Take the time you need. If i can assist you with further Logs or something. Please let me know.

[HannesK]

yes, please try it out. I ask myself how it worked before, but it's worth a try.

[PhilippS_BIT]

I will try. But i have to Install Update 4 again to reproduce the error. Right now we are running U3a wich runs fine.

Here is a snippet from MountSvc Log

After Update 4

[23.01.2019 10:46:23] <04> Info Number of additional connections: [4]
[23.01.2019 10:46:23] <04> Info [AP] (3616) connecting to 'PRIVATEIP:2500;PRIVATEIP:2501', user '{5fcc6210-3c43-4d16-b1bb-6ab4470cd296}'
[23.01.2019 10:47:05] <20> Info [ReconnectableSocket] Stop confirmation was sent on [c757873f-cb2b-4d45-92f2-9f21329a4700].
[23.01.2019 10:47:05] <20> Info [ReconnectableSocket] Stop request was sent on [c757873f-cb2b-4d45-92f2-9f21329a4700].
[23.01.2019 10:47:05] <20> Info [ReconnectableSocket][StopCondition] Stop request was received on [c757873f-cb2b-4d45-92f2-9f21329a4700].
[23.01.2019 10:47:05] <20> Info [ReconnectableSocket][StopCondition] Stop confirmation was received on [c757873f-cb2b-4d45-92f2-9f21329a4700].

Before Update 4

[07.02.2019 15:33:55] <48> Info [InMemoryAgentHive] Registering windows agent. LeaseId: [a2da6604-d1b6-4d12-aa94-6caeafcb69ef]
[07.02.2019 15:33:55] <48> Info Number of additional connections: [10]
[07.02.2019 15:33:55] <48> Info [AP] (4815) connecting to 'PRIVATEIP:2500;FQDN:2500', user '{5cebe767-a699-4322-a8ef-ba84f4280aad}'
[07.02.2019 15:34:17] <48> Info Creating FCT mounter

I replaced the IP Adresses and the FQDN with generic placeholders

[HannesK]

to test without the requirement to upgrade: can you install a windows VM at a customer site and try to add it with IP address? you should have the same issues like in U4 without setting the checkbox.

[nickgr@avi.co.za]

Hi,

This is a late response to this post, however did you ever receive any feedback from Veeam regarding this issue?

We are experiencing similar issues regarding remote site backups when we use a HOSTS file entry to direct traffic over a dedicated backup network between our two datacenters (the remote site proxies are detecting the private backup network IP address for the servers, which is not routable across the WAN), and are struggling to find a way to resolve this. It was working before-hand, and believe that it may be related to the update of B+R to Update 4.

[foggy]

Hi Nick, the OP's case was closed after he was not able to reproduce the issue. There's a chance this was the result of some sort of misconfiguration. If hints given above do not help, I recommend contacting support for assistance. Thanks!