Using two different network connections can sometimes make connectivity difficult. For example, let's say you have one connection for your servers and another connection for a local LAN.
Most of us understand the importance of making backups, and using a tool such as rsync is the best way to do so. But performing backups from one machine to another that are in close physical proximity, but not on the same network, can increase bandwidth usage needlessly for both Internet accounts.
One solution is to add a specialized firewall or server to the server connection that has a second network card connected to the local LAN, effectively giving your LAN two connections to the Internet. The advantage of this solution isn't as much the redundant network connection as it is the ability to connect to servers without going over the Internet.
However, the solution poses a few security risks of its own. As such, this firewall or special server should have firewall rules that prevent traffic, even that generated on the server itself, to the LAN. You may even opt to throw a separate firewall between this host and the local LAN.
If you have another server that you want to back up that's parallel to this one, you can do so by using port forwarding and network address translation (NAT). The easiest way is to use Shorewall for your firewall. The pertinent Shorewall rules would be:
ACCEPT lan fw tcp
DNAT lan wan:18.104.22.168:22 tcp 1022 -
This tells Shorewall to accept connections from the lan zone (the internal network) to the fw zone (the firewall/server running Shorewall). Port 1022 is the port we want to open.
The next rule defines a destination NAT (DNAT), which takes traffic received on port 1022 and forwards it to the host 22.214.171.124 (the parallel server) on port 22, the standard SSH port. Using this, you can ssh into port 1022 on the firewall server, and it will transparently forward you to port 22 of the server you really want to connect to.
This port forwarding process saves bandwidth in situations where you may have two Internet connections in the same physical location.
The modifications to the Shorewall rules allowed us to ssh from the LAN to the firewall host on port 1022 and be redirected transparently to port 22 on a parallel server. However, if you also ssh into the firewall machine, your ssh client will complain about mismatched keys for the host. In both cases, it thinks it's connecting to the same host (but using a different port).
To handle this, modify your user's ~/.ssh/config file, and make a new entry specifically for this special route to your server.
This configuration allows you to connect to the server just as you would over the Internet. In this case, execute the following:
$ ssh server
This actually connects to port 1022 on the host 192.168.5.1 (the firewall host's internal IP address), which you've already configured to forward to port 22 on the IP 126.96.36.199.
By telling ssh that the key you expect belongs to the host "server" and by telling it not to check the host's IP address (which would be wrong), you can transparently connect to a remote host through another. And ssh, or any application that uses it, won't know the difference.
In this manner, you can connect to the remote server, without going over the Internet, to transfer files and create backups, which saves bandwidth.