How to Set up Centralized Remote Management / Console / Dashboard

In order to manage many servers from a single screen without having to log on to each server individually, you need to use the Server Enterprise edition as the “master” and connect to it all other instances of BackupChain you have running on other computers. All instances of BackupChain can be remotely managed, except the Server Edition, which cannot be managed by a master.

Two Possible Connection Scenarios Combined

Essentially the master console is just another computer running BackupChain Server Enterprise edition or later but has the additional capability of connecting to other servers as well. Connections are handled via TCP and can be inbound or outbound.

Note that the way servers are connected for the purpose of remote management does not affect their backups and how their backups are run or stored. The connection scheme is entirely and exclusively limited to the remote management of these servers.

Inbound Connections

Inbound TCP connections are connections from a slave to the master. The slave is the server being managed by the master.

Outbound Connections

An Outbound connection is a connection made by the master to the slave.

Once the connection is established, it doesn’t matter whether it was done via an inbound or outbound connection. It does matter, however, for the setup and authentication phase of the connection.

Example diagram showing a mixed-mode setup

The diagram below shows a mixture of both methods, and also illustrates how the same console can receive connections from slaves on the LAN as well as connections coming from the internet, and at the same time it can also make connections to slaves:

The above diagram shows a master console that is connected to three different slaves, i.e. it can remotely control three other servers. Two of those are on the same LAN and one is external and is accessed over the internet.

For slaves on the internal network, you can use outbound as well as inbound connections and you can always use both methods in combination, but not to connect to the same slave twice from the same master.

When to use inbound and when outbound?

The reason why BackupChain offers both methods is to offer flexibility and security.

When the master receives the connections from the slaves, it doesn’t have to know where the slave is. It just needs to know the slave’s name and management password in order to establish trust when the connection comes in. The master also has to be configured to listen for incoming connections in order for this to work.

By using inbound connections, from the master’s perspective, the connection has to be configured at the slave side and all devices along the path need to be configured accordingly. For example, slave #1 in the diagram needs to be configured to connect to the master server, and the master server has to be configured to accept incoming connections. In addition, as with all slaves, you need to add the server in the master’s server tree, then indicate that the connection is inbound, and set the password required to manage slave #1. Then, when slave #1’s connection comes in, the server will recognize the slave by its network name and they will be able to communicate as long as the password is correct.

Outbound connections are typically used in the case of slave #3 above. Because firewalls generally allow outbound traffic, slave #3, which could be a server at a customer site, does not require any additional configuration than what is mentioned above. Slave #3 will be configured to connect to the master console and at the master console you need to add the
server, enter the inbound slave name, and enter its password.

In order for slave #3 to reach the master server, however, the connection needs to go through its local router and firewalls, the public internet, then the enter company’s firewall and router at the receiving office, the local LAN, and finally arrive at the master console.

Slave #3 will use the router’s public IP address or a domain name mapped to it in order to access it. It also has to know the port number. For example, slave #3 could be configured to connect to the master at address: 83.45.23.55:16888, or billsitservice.com:16888, where billsitservice.com maps to the static IP address 83.45.23.55, which is the public IP address of Bill’s internet router.

Bill needs to allow incoming TCP traffic in the router’s firewall (or in a separate firewall if a third device is used) on TCP port 16888 (this is just an example port, you can use any available port number). Furthermore, the router now has to use TCP port forwarding in order to forward the TCP link to the master console. Let’s say the master server’s internal static IP address is 10.0.0.3. The router needs to forward the incoming external TCP port 16888 traffic to 10.0.0.3 also on port 16888. BackupChain will need to be configured to accept incoming connections on port 16888 in this case. Once the link arrives at the master server, whether from the internal LAN or from the internet, it will be processed the same and its origin doesn’t matter.

Note that BackupChain adds itself into the standard Windows Firewall as exception; hence, you don’t have to configure it for inbound or outbound TCP connections. However, if your organization uses a 3^rd party firewall software or separate device or non-standard firewall settings, you will need to configure each firewall to allow inbound and/or outbound TCP
traffic on the port of your choosing, in our example TCP port 16888.

Outbound connections from the master to the slave have their use and benefits, too. However, as you can see from the diagram, if you wanted the master to connect to slave #3, the entire configuration process (router port forwarding and firewall) would have to be done at the site where slave #3 is located. If Bill is an IT service provider with hundreds of customers, his crew would have to configure each customer’s router and firewall to let the remote management traffic come in. In addition, customers may feel concerned that a port has to be opened. Naturally, the solution that requires less work and is more secure is the one pictured above. Bill would not have to configure anything, assuming no 3^rd-party firewall other than the standard Windows firewall is being used, because the standard Windows firewall by default permits outbound traffic, and so do most internet routers. Note that corporate networks naturally will have additional routers that may need to be configured for outbound traffic as well.

Our example company “Bill’s IT service” will make the choice to use outbound (slave to master) connections at each site. Bill would only have to configure his own router and firewall at the office, and only once. Once this is configured, the master console will receive automatically all connections from all customer sites without further configuration. The servers will have to be added individually to the console, however, because for each site you must have the management password in order to connect.

Typical use for outbound connections (master to slave)

Within a LAN, you may want to have multiple laptops connect to the same group of slave servers and manage them. In that case you don’t have to worry about routers and firewalls, since the standard Windows firewall is configured by BackupChain to allow incoming traffic to BackupChain’s service.

In this scenario you would configure each server to accept incoming connections, say on port 16888. Then on each device you want to use as a master, enable remote management and add each server individually. Configure it to be an outbound connection, enter the slave’s static IP address and port number, say 10.0.0.4:16888, and the slave’s password. This can be done to a number of master devices connecting to the same slave computers.

The same slave computer can also be configured to connect to multiple masters and also accept incoming connections from other masters. As you can see the system allows for a secure and flexible interconnection with various network patterns.

General Recommendations for Setting up Remote Management

 
Use static IP addresses everywhere, for your servers on the LAN as well as for your public internet router if the traffic is to go through the internet. The latter is not a must but a better solution because when the ISP changes the IP address of your router, the communication links will break.·
If any “smart/intelligent/sophisticated” firewall has to be crossed, turn on SSL encryption. This is because firewalls listen into the protocol and may mistake the data transfer as a security threat.·
You must turn on SSL encryption on all slaves if you plan to use it anywhere. It’s more secure but adds a small resource overhead per link. The same SSL setting (either on or off) has to be used on all connected devices.·
Make sure you choose a port number that is not being used by the software packages you normally deploy. In the case of Bill’s computer service example above, it only affects the receiving server. In the case where the link will be coming to a router through the internet, the port number has to be available for forwarding in the router as well.

·        Stick to the same port number on all servers for simplicity

·        Use high port numbers above 5000; those are generally not being filtered by ISPs or used by other services

·
Use netstat –a to see which ports are being listened to on a particular server and help you choose a free port number.

Troubleshooting Remote Management Connectivity

 
Use netstat –a to see which ports are being listened to on a particular server and help you choose a free port number.

·
Check the Remote Management Log, the log may be opened from the main menu·
Make sure the password and addresses are not misspelled·
All addresses should be static. Check with ping command that domain names resolve to the correct address

·
Set up a local LAN test first before trying the connection from an external network. I.e. set up the master and connect another device to be the test slave connecting to the master. When the connection is confirmed to be working, try the connection from the external network or internet. This method eliminates the possibility of a local issue before you move on to the router and public firewall configuration.

·
Some ISPs block certain port numbers on certain sites. It can happen that from your FL office you can connect fine but from a different office with a different ISP you can’t. By the way, with most routers you can define several port numbers to be forwarded to the same internal address and port. This will allow you to connect to your home office site using different ports, such as billsitservice.com:16888, billsitservice.com:50000, etc. and all connections can be forwarded to the same internal server at 10.0.0.3:16888

·        Turn off firewalls for a test if you suspect the connection is not coming through