We envision a world where the connection is the network: cloud services, connected devices and endpoints, easily and securely connect to each other, any time, anywhere.
A great feature called a Jumpbox (aka JumpServer) allows access to endpoints on remote LAN when you are located on a local LAN. Jumpbox features can be embedded into expensive network appliances like VPNs and routers. Or they can be on an inexpensive Raspberry Pi, OpenWRT router like a GL iNet Mango, or other micro board. Either way, they provide valuable endpoint access options when you need the feature.
To understand a Jumpbox, let’s look at a LAN — it can be local or remote. It’s typically a self-contained network of devices, endpoints, and services providing users of the LAN with a way to communicate between their devices. Multiple LANs can talk to each other via a WAN if configured to do so, keeping security and various networking architectures in mind.
Now let’s say you need access to a remote LAN, and the VPN appliance or another gateway appliance isn’t allowing you to connect to the remote LAN. Is the remote LAN down? Is it working, but the gateway device is blocking the connection? Things can get complicated when layers of hardware and security are involved.
An option would be to physically drive to the remote LAN location and determine what the issue may be that is preventing the remote access. But what if the remote LAN is hundreds or even thousands of miles away? Today it’s common to provide a managed service for LAN management because it can centralize support with higher-level technical experts. Typically the goal is to avoid a “truck roll”, which means not sending a technician out to investigate the problem. It can be expensive to send a qualified technician!
A Jumpbox can provide remote access to the LAN and even to the devices on a LAN. It then acts as a mini gateway on the LAN and allows you to access the LAN and then ‘jump’ via SSH or other services to other connected devices on that LAN. When set up and configured, it’s a secure entry point that gives authorized users access and ultimately can get the primary gateway diagnosed and working again.
Remote access via traditional appliances stops working for several reasons. Sometimes, network admins are busy and fat finger configurations of LAN appliances that are critical to bridge or access the network. These fat finger mistakes can be fixed but may require a reboot. Or an SSH connection is the only way to get it fixed. If the appliance doesn’t allow access, you need someone to handle it at the remote location. If an independent Jumpbox was set up on the remote LAN, it would be possible to “jump” to the problem devices from a Jumpbox appliance. It also has the side benefit of saving a truck roll because there is no need to send a technician to solve the problem.
Even if the public and hard-wired internet connection goes down because of a service outage, adding a cellular hotspot to the remote LAN and Jumpbox will provide you with the required access.
A Jumpbox does not have to be expensive, making it a no-brainer to include on a LAN. Using a Raspberry Pi, an OpenWRT router like a GL iNet Mango, or other micro board with Remote.It gives you a powerful yet inexpensive Jumpbox option that any LAN can utilize. With its VPN-like tunnels, Remote.It can securely manage inbound connections and direct them to other LAN resources. Even if troubleshooting isn’t the main requirement, an RPI-based Jumpbox can be a simple and effective means of remote managing a LAN from just about anywhere.
To get started, download and install Remote.It on a networked device. Then set up a service like SSH or HTTPS that provides access to LAN devices. It’s that simple. And it works!