I have an open case with support: #02079118. They have suggested I post here as a feature request
Essentially what I'd like to do is use the Agent for Linux to backup to a remote B&R server that sits behind a firewall. I have setup all the correct port forwarding but for some reason after the initial setup of the job the actual backup attempts to talk to the internal IP of the B&R server. This can be seen in the logs as follows:
[23.02.2017 08:12:15] <140268905989888> lpbcore| Starting backup client for agent with UID [{0ac9a604-240f-4a31-901a-526c86796e24}]. Client id: [1ee5]
[23.02.2017 08:12:15] <140268905989888> lpbcore| IP endpoints: [10.2.1.11:2502].
[23.02.2017 08:12:15] <140268905989888> | Trying to connect to the endpoint [10.2.1.11:2502]
[23.02.2017 08:13:18] <140268905989888> | Connection status: system:110 ( Connection timed out ).
[23.02.2017 08:13:18] <140268905989888> lpbcore| Starting backup client for agent with UID [{0ac9a604-240f-4a31-901a-526c86796e24}]. Client id: [1ee5] Failed.
[23.02.2017 08:13:20] <140268905989888> lpbcore| BackupJobPerformer: Creating backup. Failed.
[23.02.2017 08:13:21] <140268905994080> lpbcore| LpbManSession: Processing commands. ok.
[23.02.2017 08:13:21] <140268905989888> lpbcore| ERR |Job has failed.
[23.02.2017 08:13:21] <140268905989888> lpbcore| >> |Failed to connect to the port [10.2.1.11:2502].
[23.02.2017 08:13:21] <140268905989888> lpbcore| >> |--tr:Failed to connect to target endpoint.
[23.02.2017 08:13:21] <140268905989888> lpbcore| >> |--tr:Unable to connect to agent endpoint.
[23.02.2017 08:13:21] <140268905989888> lpbcore| >> |Backup job has failed.
[23.02.2017 08:13:21] <140268905989888> lpbcore| >> |An exception was thrown from thread [140268905989888].
In simplistic terms the infrastructure is as follows:
CentOS Server with Agent -> FW (NAT) -> internet -> FW (NAT) -> B&R 9.5U1 (Server and Repo on one box)
This setup works for B&R to remote B&R, so would be nice to be able to do the same with the Agent.
For some reason the agent ignores the external IP (in this case a hostname) used in the backup job creation, during the backup process. Instead when the job starts it wants to connect to the internal IP of the B&R server. This indicates there must be some sort of communication taking place because how else would it know what the internal IP is?
Edit: Maybe I need more coffee? Are you commenting on the feature I want to change or the typo?
Just one question - do you have your repo on the same server where VBR resides at? Also did you specify an IP, or hostname on the VBR configuration step in VAL?
the missing NAT-support is the last showstopper for us to use the agent on our remote hosts (and finally remove the other crappy backup-products).
Would it be possible to add it as feature-request?
Just one question - do you have your repo on the same server where VBR resides at? Also did you specify an IP, or hostname on the VBR configuration step in VAL?
Repo and VBR are on the same box. I used a hostname. The hostname resolves correctly to the external IP. You suggesting I rather just try the external IP? I didn't try that actually.
PTide wrote:
Please also check this post for a workaround.
Would it be possible to add it as feature-request?
Sure, feature request has been noted.
@emilec
If got it right, your vbr server has an external IP (the one that you've specified in VAL) and an internal IP (the one that VAL is attempting to contact). Is that's the case?
This involves adding a secondary IP for the repo that matches your public IP address, then adding the repo, by that IP, to the VBR server. This effectively fools the VBR server into thinking that the public IP is the address of the repo and that's the address it sends to the client to connect.
PTide wrote:If got it right, your vbr server has an external IP (the one that you've specified in VAL) and an internal IP (the one that VAL is attempting to contact). Is that's the case?
Yes.
In simplistic terms the infrastructure is as follows:
CentOS Server with Agent -> FW (NAT) -> internet -> FW (NAT) -> B&R 9.5U1 (Server and Repo on one box)
This involves adding a secondary IP for the repo that matches your public IP address, then adding the repo, by that IP, to the VBR server. This effectively fools the VBR server into thinking that the public IP is the address of the repo and that's the address it sends to the client to connect.
Thanks. I did see that, but I'm not changing a working production service to accommodate:
1) My VAL testing
2) A missing feature / bug (IMHO)
I recollect that there is a very similar issue with Endpoint. I guess that if a secondary IP is added then VBR will return two IPs resulting in the same behaviour.
PTide wrote:I recollect that there is a very similar issue with Endpoint. I guess that if a secondary IP is added then VBR will return two IPs resulting in the same behaviour.
In my case the host only has one IP, which is the internal one.
No, there are none. However, new Agent is able to backup to Cloud Connect directly, so you don't have to expose the whole range of ports on the backup site.
). Don't worry too much about a typo by the way