remote (active) client with local Director, and 2x Storages: custom storage port(s)?

60 views
Skip to first unread message

tim.b...@gmail.com

unread,
Apr 21, 2022, 11:41:22 AM4/21/22
to bareos-users
Dear all,

I would like to achieve the following: I have multiple remote clients which I want to backup in our local LAN, where 1 director and 2 storage daemons are. I would like to have the client contact the director (and storages), so I only need to have 3 port forwards (client(s) -> Director, and client(s) -> 2x storages). So I do not need to open ports on all the clients for director + storage (also, the WAN IP of our LAN is used by multiple organizations, who knows what they are doing).

Additionally, I already have a LAN Address configured between one internal client, and one internal storage (to circumvent a slow network-switch for this important/long backup).

So it should be a client-initiated connection: https://docs.bareos.org/TasksAndConcepts/NetworkSetup.html#client-initiated-connection and I think this should work out without problems with the port forwardings.

But if I don't want to use "passive client", how can my remote clients get the correct WAN IP + port of the storages (the port forwarding is from WAN-IP:random-Port -> storage-LAN-IP:9103) to connect to the storage daemon? I could use a hostfile on the client, but how can I set a custom port (also considering there are 2 different storage daemons, and one is already using LAN for a direct cable connection with one client).

is there any way to do this, or do I have to use (at least) passive client so the storage daemons connect the client directly? (while I should have remote clients be able to connect to the one director).

thanks

tim.b...@gmail.com

unread,
Apr 29, 2022, 8:52:10 AM4/29/22
to bareos-users
Hello,

this is not an answer to my initial question, but I settled with passive clients. Its far easier, and works like a charm with 2 (local) storage daemon to backup a remote client. Not ideal from the perspective of opening up the client, but I think it would not have worked otherwise do to our constraints of port usage, and having 2 storage daemons.
Reply all
Reply to author
Forward
0 new messages