IP or FQDN address given to Veeam Agent managed by Veeam Backup

[dcit]

What IP or FQDN address is given to Veeam Agent managed by Veeam Backup when backuping to Veeam Backup repository?

I would except FQDN of Veeam Backup proxy managing that backup repository.

But it seems that IP address of one of network interfaces of that backup proxy is given, which is resulting for us in:
Error: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond x.y.z.w:2502

Connection to public IP of that Windows Server is mandatory server-to-server IPsec encrypted (enforced by Windows firewall connection security rule), so any unencrypted traffic is rejected. If FQDN is given, then it would be OK - in ...\etc\hosts on Windows Server backuped by Veeam Agent there is FQDN of that proxy -> IP address connectable through IPsec tunnel (different from that server-to-server IPsec) - so it would connect without problems (ping FQDN works, and "nc -v hiyori2.dcit.cz 2502" connects, and "nc -v -n 80.79.28.28 2502" timeouts).

Solution for us would probably be to add appropriate IPsec connection rule to that backuped server to Windows firewall, so connection to public IP of that proxy would be possible - I have tried it and it works.

But nevertheless it seems to me like bad idea to give IP address instead of FQDN, may be you should correct this behaviour (if my theory is right of course, and it really behaves like this).

[Mildur]

Veeam Agent and NAT is not supported, if using a vbr server as a backup target.
You need a vpn if your Veeam agent is outsite of your network somewhere in the internet.
Or you can use Backup to Cloud Connect, if you are a service provider.

See a ongoing discussion about Veeam Agent and NAT:
veeam-agent-for-windows-f33/featurerequ ... c7147c138e


From the Guide:

https://helpcenter.veeam.com/docs/agent ... tml?ver=50

Veeam Agent for Microsoft Windows should be able to establish a direct IP connection to the Veeam Backup & Replication server. Thus, Veeam Agent cannot work with Veeam Backup & Replication that is located behind the NAT gateway.

[dcit]

Veeam Agent is in my network, Veeam Backup proxy with local storage is outside of my network, and I am using VPN, only traffic tries to go directly through public internet instead of choosing IP address available through VPN.

As I have already written I have managed to solve it by allowing that direct internet connection, but still it does seems to me like correct behaviour, it seems to me that it is a bug. So I have posted that even when I have no other motivation than making world better by software being less buggy (by reporting bug(s) to software maker).

[nikolaj]

Veeam Agent is in my network, Veeam Backup proxy with local storage is outside of my network, and I am using VPN, only traffic tries to go directly through public internet instead of choosing IP address available through VPN.

Perhaps, another viable solution is to map traffic akin to something that iptables can offer. On Windows, you could achieve that via port mapping [1] / forwarding [2].

So you'd have something like this:

Code: Select all

netsh interface portproxy add v4tov4 listenport=xxxx listenaddress=x.x.x.x connectport=xxxx connectaddress=x.x.x.x

[dcit]

Yeah, that should work too, thanks for the tip. Or may be some NATing on our FortiGate firewall (that machine with Veeam Agent has it as default route). But in our case adding that Windows firewall IPsec connection rule was probably most elegant solution.

[dcit]

This issue got to me back like a boomerang.

I was forced to disable that Windows firewall IPsec connection rule as a way to force backup -> copy backup traffic through site-to-site IPsec VPN.
Relevant support case: #07084366 — copy backup Failed to decrypt TLS data error after upg 11a -> 12.1

But it have broken Veeam Agent backup (as I have forgotten about issue I have written about in this post, so I was surprised by it).
Relevant support case: #07092054 — Veeam Agent does not tries to connect to FQDN only to IP addresses of proxy

I was able to solve it by somehow "dirty hack" by configuring on that offsite server as second IP new IP (as sigle IP - netmask /32) which is accessible from backup server @HQ (which I backup using Veeam Agent, OS drive of that server) using DNAT on our FortiGate (and then it goes through site-to-site VPN). As it seems that Veeam is giving all IP addresses of that offsite server to Veeam Agent, this way one of these addresses is reachable.


What I would like to have answer from relevant Veeam product manager on is:
Do I understand correctly that it is impossible to set up Veeam Agent managed by VBR to connect to Veeam Backup repository using its FQDN and Veeam sees this as a feature and does not intend to change this behaviour?

[VladOst]

If, after successful mutual configuration of the VBR server and client, on the client side (Linux) execute
# veeamconfig vbrServer list
then it becomes obvious that the server is sending its FQDN to the client. The question remains - how to add your own parameters there, and not those that the Server received from the system settings.
I believe that VEEAM’s financial interests are intervening here to force additional purchases of Cloud solutions or their partners as service provider, covering this with a noble mask of security...
Of course, this is their right, so for now the only solution left is the dirty solution of adding a white IP gateway to the server’s network interface parameters, and port forwarding on the gateway. But, in some cases this is not the best practice, because the gateway may be behind a CDN, and then you will have to add several IPs, and sometimes they can even be dynamic (like Cloudflare).
The recommended option with a VPN is also not an option, especially on Windows computers with clients, because it is almost impossible to keep the VPN constantly connected and sometimes without user login (service) using standard Windows tools...