DEV Community: Remote.It

Bouncer - Diagnose Network Connection Problems

Brenda Strech — Wed, 21 Dec 2022 16:13:03 +0000

In this article we describe Bouncer, an open source tool that we created to help solve some of the problems described in the previous two articles. We also describe some of the other networking issues we encountered in working with Docker containers, in particular on macOS. Bouncer is not limited to connections involving Docker containers though.

‘Open source tool for determining MTU values in Docker containers’ covers the subject of asymmetric maximum transmission unit (MTU) and provides a basic overview of how Remote.It and Remote.It tools may be used to discover problems with MTU.

We also found that Docker containers on macOS ignore the Don’t Fragment (DF) bit. Without support for the DF bit it turns out that it is difficult to discover the MTU and MRU of a network connection. Read more about 'Docker and the DF Bit'.

What is Bouncer?

Remote.It Bouncer is a software tool written by Remote.It to help diagnose connection problems. For example, Bouncer can help diagnose problems with MTU and the DF bit. Bouncer is a server that can test the MTU of a connection made using UDP. You connect to the Bouncer server with netcat, or a similar networking tool, and request the return of a UDP packet with a data size that you specify. Bouncer returns a packet with characteristics and properties that specify. For example, you can set the packet to be returned with the DF flag. You can also specify clearing the DF flag if supported in your OS. In our experience, macOS does not currently appear to support setting the DF flag.

You can find Remote.It's open source Bouncer at Github https://github.com/remoteit/MTU_Bouncer provided under the MIT License.

We have also used Bouncer to discover endpoints that do not allow fragmented packets. For example, you can request Bouncer to return a large MTU packet and set the DF bit on to test fragmented packets. If you do not get a response on an otherwise known good connection, then something, somewhere in your path may be dropping fragmented packets.

Bouncer Usage

usage: ./mtu_bouncer [-h] [-v(erbose)] [-d][pid file] [-l listen_tcp_port]
        -h this output.
        -v console debug output.
        -d runs the program as a daemon with optional pid file.
         -l Listen port (defaults to 9999)

Examples of Bouncer use

Run the Bouncer server:

./mtu_bouncer

Connect to the Bouncer server using netcat:

nc -u <serverIP> 9999

Bouncer uses UDP, so you will have to send response, even a null character, to allow Bouncer know your IP address. So, when you hit return after entering the netcat command, the terminal console will wait for you to enter the response. For example, you could use this command to send a newline and cause Bouncer to prompt you for action:

echo -n "/n" | nc -v -u bouncer.remote.it 9999

You can ask the Bouncer server to send you a UDP packet with a payload of specified size. For example, you can successively enter 10, 100, 1472, 1473f to request Bouncer to send packets of size 10 (with DF=1), 100 (DF=1), 1472 (DF=1) and 1473 (with DF=0):

ops@ops-mac-mini ~ % nc -u <serverIP> 9999
10
Must be between 20 and 4000 (add f on end to allow fragmentation)
100
100 (128 MTU DF=1)
..............................................................................
1472
1472 (1500 MTU DF=1)
.........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
1473
On size 1473 (1501 MTU dfrag=1) sender failed to send with error Message too long code 90
1473f
1473 (1501 MTU DF=0)
.........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................

Building Bouncer

Using the makefile in the src directory of the repo should build Bouncer on most Linux or Unix platforms. There is also a win32 project for building on Windows console app.

What is MTU?

The OSI model consists of seven abstract layers: Physical, Data link, Network, Transport, Session, Presentation, and Application. The Physical layer may be Ethernet, for example. Ethernet carries frames that carry the packets.

There is a limit on the size of the Ethernet frame that typically limits the size of data to 1500 bytes. This limit of the link layer is called the MTU, maximum transmission unit.

If the IP layer has a datagram to send, and the datagram is larger than the link layer's MTU, IP performs fragmentation, breaking the datagram up into smaller pieces called fragments so that each fragment is smaller than the MTU.

When two hosts on one network communicate with each other, there is a single network MTU. When two hosts communicate using multiple networks, each link can have a different MTU. The important numbers are not the MTUs of the two networks to which the two hosts are connected, but the smallest MTU of any data link that packets traverse between the two hosts. The smallest network MTU is called the path MTU.

The path MTU between any two hosts is not necessarily constant and may depend on the route being used at any time. Routing need not be symmetric so that the route from A to B may not be the route from B to A, and thus the path MTU need not be the same in both directions. In that case the MRU or maximum receive unit may not be the same as the MTU.

What is the DF bit?

The DF bit is a single-bit field within the Internet Protocol (IP) header of a packet that determines whether a router is allowed to fragment a packet. IP fragmentation is an process that breaks a packet into pieces or fragments, so that the resulting pieces can pass through a link in a network connection that has a smaller MTU than can handle the original packet size. The fragments are then reassembled by the receiving host. RFC 1191 specifies the path MTU discovery mechanism (PMTUD), a way to determine the path MTU (PMTU) at any time using the DF bit.

Following RFC1191, PMTUD uses the DF bit to discover the PMTU of a path. A source host initially assumes that the PMTU of a path is the known MTU of the first hop, and sends all datagrams on that path with the DF bit set. If a datagram is too large to be forwarded without fragmentation by a router along that path, then the router will discard the datagram and return a Internet Control Message Protocol (ICMP) Destination Unreachable message with a code that corresponds to "fragmentation needed and DF set". Upon receiving that code and message, which is essentially a "Datagram Too Big" message, the source host reduces the assumed PMTU for the path.

PMTUD will end when the host's estimate of the PMTU is low enough that datagrams can be delivered without fragmentation. Or the host may end PMTUD by stopping to set the DF bit in the datagram headers because, for example, it is willing to have datagrams fragmented. Normally, the host continues to set DF for all datagrams, so that if the path changes to a lower PMTU, the new PMTU will be discovered.

macOS tool issues

One of the limitations that we found with netcat on macOS was a limit of 1024 bytes in terminal input. This system limit is set as follows, presumably inherited from BSD:

define MAX_INPUT             1024   /* max bytes in terminal input */

This 1024-byte limit makes it harder to use netcat to generate packets large enough to test the MTU of a path. A Github project documents some of other undocumented semantics of Apple's Network framework.

Why use Remote.It with Docker?

Remote.It is a powerful connection tool that can connect any two hosts or devices using a peer-peer connection with an agent on each host. Remote.It can also connect using a web-based tool and a proxy to any target host, using a single agent on the target host.

Developers can be used to connect containers within a host, containers in different hosts on the same network, containers on different networks, or even containers in different data centers for example.

Suppose container 1 has a default IP address 172.17.0.1 and container 2 also has a default IP address 172.17.0.1. Remote.It allows you to connect these two containers.

Summary

We found a problem with support of the DF bit in a macOS Docker container. We also described MTU, how a path can have asymmetric MTU and an example of an asymmetric MTU situation in a Docker container and why it is important to support the DF bit in order to discover MTU and asymmetric MTU/MRU. We described how to discover an asymmetric MTU using Remote.It and the use of MTU Bouncer.

Docker and the DF bit

Brenda Strech — Wed, 21 Dec 2022 16:12:49 +0000

We found that Docker containers on macOS ignore the Don’t Fragment (DF) bit. Without support for the DF bit, it is challenging to discover the MTU and MRU of a network connection.

Why is this important? Without knowing the MRU and MTU for a connection, it is hard to create a network connection with maximum efficiency, and sometimes, it may even be hard to create a network connection that works at all.

What is the DF bit?

The DF bit is a single bit field within the Internet Protocol (IP) header of a packet that determines whether a router is allowed to fragment a packet. IP fragmentation is a process that breaks a packet into pieces or fragments so that the resulting pieces can pass through a link in a network connection that has a smaller MTU than can be handled by the original packet size. The fragments are then reassembled by the receiving host. RFC 1191 [Mogul and Deering 1990] specifies the path MTU discovery mechanism (PMTUD), a way to determine the path MTU (PMTU) at any time using the DF bit.

Following RFC1191, PMTUD uses the DF bit to discover the PMTU of a path. A source host initially assumes that the PMTU of a path is the known MTU of the first hop, and sends all datagrams on that path with the DF bit set. If a datagram is too large to be forwarded without fragmentation by a router along that path, then the router will discard the datagram and return an Internet Control Message Protocol (ICMP) Destination Unreachable message with a code that corresponds to "fragmentation needed and DF set". Upon receiving that code and message, which is essentially a "Datagram Too Big" message, the source host reduces the assumed PMTU for the path.

PMTUD will end when the host's estimate of the PMTU is low enough that datagrams can be delivered without fragmentation. The host may also end PMTUD by stopping to set the DF bit in the datagram headers because, for example, it is willing to have datagrams fragmented. Normally, the host continues to set DF for all datagrams, so that if the path changes to a lower PMTU, the new PMTU will be discovered.

Docker and the DF bit

We performed some experiments using a Docker container running on macOS. We summarize these results first, and then show the corresponding macOS Terminal logs.

We used the Remote.It MTU Bouncer tool to send or bounce packets back to us of a certain requested size both with and without the DF bit being set (DF=1). We first ask to be sent a series of packets with DF=1 and length 1770 (which fails, too long), 1470 (succeeds), 1472 (succeeds), 1473 (fails to send, too long). Then we ask for a packet with DF=0 of length 1473 and that packet never arrives, and the same occurs with length 1472. Thus, we suspect that Docker does not maintain the DF bit somewhere between the Docker container and the macOS host OS.

To check this, we then move to the host macOS, eliminating the Docker container, and ask for a packet with DF=1 length 1472 (succeeds), DF=1 length 1473 (fails, too long), then DF=0 length 1473 (which succeeds but previously failed inside the Docker container).

We can conclude that somewhere the DF bit is not being communicated somewhere between the macOS Docker container and host macOS.

Here is the macOS Terminal log corresponding to the experiments and results described above:

~ # nc -u bouncer.remote.it 9999
1770
On size 1770 (1798 MTU dfrag=1) sender failed to send with error Message too long code 90
17
Must be between 20 and 65535 (add f on end to allow fragmentation)
1470
1470 (1498 MTU DF=1)
..........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
Must be between 20 and 65535 (add f on end to allow fragmentation)
1472
1472 (1500 MTU DF=1)
..........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
Must be between 20 and 65535 (add f on end to allow fragmentation)
1473
On size 1473 (1501 MTU dfrag=1) sender failed to send with error Message too long code 90
1473f
1472f
1472 (1500 MTU DF=0)
..........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................^C~ #
~ # exit
ops@ops-mac-mini ~ % nc -u bouncer.remote.it 9999
1472
1472 (1500 MTU DF=1)
..........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
Must be between 20 and 65535 (add f on end to allow fragmentation)
1473
On size 1473 (1501 MTU dfrag=1) sender failed to send with error Message too long code 90
1473f
1473 (1501 MTU DF=0)
..........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
ops@ops-mac-mini ~ %

Note in this case, when we connect to a server located at bouncer.remote.it using netcat and you hit return after entering the netcat command, the terminal console waits for you to enter something. In the above example, we asked the server to send packets of length 1770, 17, 1470, 1472, 1473, 1473f (the f flag sets DF=0), 1472f, 1472, 1473, 1473f, as we probed the path to determine the MTU.

What is Docker?

Docker allows you to package and run an application in a loosely isolated secure environment called a container. The isolation and security allow you to run many containers simultaneously on a single host. Containers are lightweight and possess everything needed to run the application, so you do not need to rely on anything installed on the host. You can share containers with anyone and ensure that the same container that works in the same way everywhere.

Docker is written in the Go and takes advantage of several features of the Linux kernel to perform its functions. For example, Docker uses a technology called namespaces to provide the isolated workspace that forms the container. When you run a container, Docker creates a set of namespaces for each container.

Docker thus has some characteristics that are inherited from Linux and some characteristics that are determined by or inherited from the host OS, in our case macOS. This “split personality”, can cause problems and this article describes one of problems.

Why use Remote.It with Docker?

Remote.It is a powerful network connection tool. Remote.It can connect any two hosts or devices using a peer-peer connection with an agent on each host. Remote.It can also connect using a web-based tool and a proxy to any target host, using a single agent on the target host.

Remote.It can be used to connect containers within a host, containers in different hosts on the same network, containers on different networks, or even containers in different data centers, for example.

As an example of a network connection that would be difficult to create by other methods, suppose container 1 has a default private IP address 172.17.0.1 and container 2 also has the same default IP address 172.17.0.1. Remote.It allows you to connect these two containers.

Docker asymmetric MTU

If we run Remote.It in a Docker container running on macOS we see the following:

Connected to ID user@remote.it - f3:25:9f:01:33:b9:f1:ed at 192.168.2.21:37020
Session Max Packet Detected 1450 (MTU) Max Data Tunnel Size 1386 bytes.
Session Max Packet Received 1500 (MRU) Max Data Tunnel Size 1436 bytes.
last packet from Session peer 0 seconds ago
retry at count 0

Note that we have an asymmetric MTU: the container has an MTU of 1450 bytes (allowing to a tunnel payload of 1386 bytes with a header and encryption overhead of 64 bytes) but an MRU of 1500 bytes (with the same 64-byte overhead).

The asymmetric MTU was discovered using the DF bit. Without support for the DF bit the discovery of MTU and asymmetric MTU, or different MTU and MRU, would be very difficult. As outlined earlier, you also can contend with the support of the DF bit in a macOS Docker container.

Summary

We described the problem we found with the support of the DF bit in a macOS Docker container. We also described MTU, how a path could have asymmetric MTU, and an example of an asymmetric MTU situation in a Docker container, and why it is important to support the DF bit in order to discover MTU and asymmetric MTU/MRU. We described how to discover an asymmetric MTU using Remote.It and the use of MTU Bouncer.

Open source tool for determining MTU values in Docker containers

Brenda Strech — Wed, 21 Dec 2022 16:12:39 +0000

This article provides a basic overview of how Remote.It's open source tool may be used to discover problems with MTU (maximum transmission unit). Did you know MTU values can by asymmetrical? Do you know how to test for this within your Docker network? Remote.It has written a tool to help identify these issues.

Docker asymmetric MTU

If we run Remote.It or other services in a Docker container running on macOS we see the following:

Connected to ID user@remote.it - f3:25:9f:01:33:b9:f1:ed at 192.168.2.21:37020
Session Max Packet Detected 1450 (MTU) Max Data Tunnel Size 1386 bytes.
Session Max Packet Received 1500 (MRU) Max Data Tunnel Size 1436 bytes.
last packet from Session peer 0 seconds ago
retry at count 0

Note that we have an asymmetric MTU: the container has an MTU of 1450 bytes (allowing for a tunnel payload of 1386 bytes with a header and encryption overhead of 64 bytes) but an MRU of 1500 bytes (with the same 64-byte overhead). In this case, Remote.It has discovered the MTU by sending packets of various lengths. The discovery is a step-by-step process and Remote.It stops when it has found a packet length that works. The discovery algorithm is granular in that Remote.It may stop a few bytes before the actual MTU. If we run a test program and exhaustively search for the exact MTU, we find the Docker MTU on macOS is 1478 bytes (with a UDP data payload of1450 bytes)

Now, If we run Remote.It on the macOS machine we see the following:

Session List
session index 1 of id 0x558C1B10794B03B05571579018B7AB4433F4DD9A is in state 3 encrypt type 3
using spi is 0x33F4DD9A
Connected to ID user@remote.it - 80:00:01:7f:7e:03:c7:3c at 10.60.0.3:63804
Session Max Packet Detected 1500 (MTU) Max Data Tunnel Size 1436 bytes.
Session Max Packet Received 1500 (MRU) Max Data Tunnel Size 1436 bytes.
Session at 19 seconds of 7200 seconds max life
last packet from Session peer 5 seconds ago
retry at count 0

Now we see the full symmetric MTU of 1500 bytes. Note: This connection was made using chacha20 encryption. If we had used a lighter weight encryption, we might see Tunnel Size 1450 bytes.

Looking at the Docker interface on the container running inside macOS, we see the following:

~ # ifconfig
eth0    Link encap:Ethernet  HWaddr 02:42:AC:11:00:02
          inet addr:172.17.0.2  Bcast:172.17.255.255  Mask:255.255.0.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:34808 errors:0 dropped:0 overruns:0 frame:0
          TX packets:40066 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:16585975 (15.8 MiB)  TX bytes:9236031 (8.8 MiB)lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:1 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:151 (151.0 B)  TX bytes:151 (151.0 B)~ #

The container thinks the MTU is 1500 bytes. Without further information, we would think the MTU is symmetric but we have seen above that it is not.

Wireshark

If we look at the packets on the wire using Wireshark for example we can see the MTU.

MTU Bouncer

Remote.It has written and released an open source tool called MTU Bouncer to allow you to check for asymmetric MTU. MTU Bouncer sends a UDP packet back to you with a given length.

See https://github.com/remoteit/MTU_Bouncer

Here is sample output from running MTU Bouncer:

Home-MacBook-Pro:~ user$ nc -u bouncer.remote.it 9999
17
17 (45 MTU)
...Must be between 16 and 1472
^CHome-MacBook-Pro:~ user$

Bouncer uses UDP, so you will have to send response, even a null character, to allow Bouncer know your IP address. So, when you hit return after entering the netcat command, the terminal console will wait for you to enter the response. In the above case, we entered 17 to request Bouncer to send a UDP packet of length 17 with DF=1 (You can also set DF=0, meaning that the bit is not set).

What is MTU?

There is a limit on the size of the Ethernet frame that typically limits the size of data to 1500 bytes. This limit of the link layer is called the MTU, maximum transmission unit.

RFC 1191 [Mogul and Deering 1990] specifies the path MTU discovery mechanism, a way to determine the path MTU at any time.

A network with an asymmetric MTU is the situation the focus of this article.

What is Docker?

Docker allows you to package and run an application in a loosely isolated secure environment called a container. The isolation and security allows you to run many containers simultaneously on one host. Containers are lightweight and contain everything needed to run the application, so you do not need to rely on what is currently installed on the host. You can easily share containers, and be sure that everyone you share with gets the same container that works in the same way.

A container is a runnable instance of an image. You can create, start, stop, move, or delete a container using the Docker API or CLI. You can connect a container to one or more networks, attach storage to it, or even create a new image based on its current state.

Docker is written in the Go programming language and takes advantage of several features of the Linux kernel to deliver its functionality. Docker uses a technology called namespaces to provide the isolated workspace called the container. When you run a container, Docker creates a set of namespaces for that container.

These namespaces provide the layer of isolation. Each aspect of a container runs in a separate namespace and its access is limited to that namespace.

One of the reasons Docker containers and services are so powerful is that you can connect them together, or connect them to non-Docker workloads. Docker containers and services do not even need to be aware that they are deployed on Docker, or whether their peers are also Docker workloads or not. Whether your Docker hosts run Linux, Windows, or a mix of the two, you can use Docker to manage them in a platform-agnostic way.

Why use Remote.It with Docker?

Suppose container 1 has a default IP address 172.17.0.1 and container 2 also has a default IP address 172.17.0.1. Remote.It allows you to connect these two containers.

Summary

We have described MTU, how a path can have asymmetric MTU and an example of an asymmetric MTU situation in a Docker container. We described how to discover an asymmetric MTU using Remote.It and the use of MTU Bouncer.

Learn more about how Remote.It makes connections by reading this article.

Is your MySQL server open to the public internet?

Brenda Strech — Thu, 21 Jul 2022 00:17:00 +0000

According to an article by Shadowserver foundation, there were 2.3 million MySQL server instances on port 3306 that were scanned and found accessible worldwide. I was really surprised by the large number and am pretty certain that most people didn't do this on purpose.

First, let’s talk about the reason why having your MySQL (or any port) accessible on the public internet is an attack surface. Any port which is accessible on a public IP address will be scanned, this is a fact. Once a port has been scanned and found that there is a service responding, then the attacks will begin. These will include brute force attacks of username/password combinations, known exploits of OS and applications, various other known Common Vulnerabilities and Exposures, and new hacks are being developed constantly.

Mitigation

Here are the common things people do to attempt to remove the risk.

Add a VPN

You could add a VPN to allow access to the MySQL server to allow you to close the external port on the public IP address.

Pros:

You got your MySQL port off the public internet and you can do the same for other resources
You can manage the users who need access centrally

Cons:

Trading one public IP address and port for another.
Can be expensive
Some MySQL databases only have a public endpoint such as an AWS RDS MySQL setup for public access. VPNs can't solve this problem.
Authenticated VPN users still can see all of the resources tied to the VPN even though they are not authorized to use all of them
Subnet Collision can render this solution untenable. You can end up with some headaches down the road, especially when you are in the cloud and have multiple VPCs with resources you need to access simultaneously. For example, you have a developer who needs to access MySQL, Redis, RDS Postgres, DynamoDB, etc at the same time, but they are on different VPCs with subnet collision (CIDRs which are the same). Your VPN client will not work in this situation
You may need public access for some users and resources. In this case you will need to have an access list. Now you are maintaining both a VPN and an allow list. This would be the case for a contractor.

Use IP allow lists

Another option is to manage an IP allow list to prevent port scanners from detecting the port. This can be an additional step to adding a VPN to prevent the VPN port from being detected.

Pros:

Only requests originating from the list of IP addresses that are allowed will be able to detect the port and connect

Cons:

These lists are hard to maintain since you will need these security group definitions in many places when you are deployed to multiple VPC and/or Cloud Vendors
Hard to ensure that the IP address you allowed is static to a user/resource. For example, a cellular hotspot dynamic IP
User onboarding and offboarding is often incomplete, leaving a potential attack vector.
As users change locations or their IP address gets reassigned and the authorized user needs to wait for DevOps to update the rules resulting in productivity and time loss.

The above solutions are not Zero Trust Network Architecture where you are giving each user access to only the resources to which they are authorized. Least privileges possible.

Use Remote.It

Remote.It allows you to close the open port while still allowing your people and resources access. When you connect to a resource such as MySQL via Remote.It, you will be given a localhost address and a unique port. You can use this in your development environment connection configuration, database query tools, etc. There is no connecting, disconnecting, and reconnecting when you change locations or your laptop wakes up from sleep. These on demand connections will go idle when you are not actively using it and go active when you do.

Easy to install
- Simple one line install for most resources
- Works in the cloud (AWS, Azure, Google Cloud) as well as on-prem servers.
Easy to implement
- Use the organization feature to create tags on your resources
- Create roles to define your member permissions (including filtering by tags)
- Add members to your organization by email address
Easy to maintain in one central location for all of your resources
Easy to audit (Logs are available for connections to your resources)
Can manage this via a Desktop UI or graphQL API
You can also roll this out gradually without needing to do a big switch.

Is your MySQL server exposed?

Use our tool to see if your MySQL server is exposed.

If your MySQL server is exposed, consider implementing the mitigations listed above. The recommendations can be used together. Remote.It accounts are free for up to 5 endpoints.

We support these popular cloud providers:
AWS
Azure
Google Cloud

Have a self-hosted database? We support that as well with options for Windows and Linux distributions.
Learn more about Remote.It and get started

If you have any questions, comment below or drop us a line at support@remote.it

Solve Your Cloud Access Problems In Less Than 5 Minutes

Brenda Strech — Tue, 28 Jun 2022 22:29:56 +0000

Spend time developing, not managing

There are many challenges that cloud developers face today and many revolve around quick, simple, and consistent access to the cloud resources such as databases. As a developer, you want to build software, not spend your time dealing with setting up your development environment.

Whether you are using an existing database or creating a new one, the process can be painful and take a lot of time. You want to make sure your data is accessible but also private, but sometimes you may be making choices that compromise one goal or the other.

Maintaining “developer” databases to run locally: To stay productive, you may use a database that allows a developer to run a database server locally. The scripts to set up the database must be maintained and only have a small sample of example data. The more database types you need the more CPU, memory and storage the developer laptop needs, for example postgreSQL, MySQL, redis, etc. Such a model is not a full-scale representation of the real-world environment and that makes it difficult to reproduce, debug, or test fixes. Deploying debug versions of your application so you can reproduce an issue with extra logging is time consuming.

Making copies of production databases to run locally: This can put a strain on your laptop, you may have a database that is just too big to run locally, or your data contains PII or other sensitive data that should not be on a laptop.

IP allow lists: You need to hide your open ports on public IP addresses and ports such as 3306 for MySQL, or you open your port for attacks. You can try and use IP lists and security groups, but the problem is that you need to maintain these lists in each environment. As a developer, this can mean access is complicated by the manual process of adding your IP address, or if you move location or work from home where you may not have a fixed external IP address, you are faced with repeated requests to devops to update the access rules. This process can introduce security risks when you don’t remove invalid IP addresses.

Using VPNs: VPNs become more and more complicated and limiting as you expand to multi-cloud or multiple VPCs and accounts that lead to subnet collisions. Such a problem may mean you can only connect to one VPN at a time. You may still end up with an open port that you may try to hide with IP allow lists that are maintained at each location where a VPN is used. We know that VPNs are not as secure as once thought.

All of these issues make on-boarding and off-boarding new developers or contractors much more time intensive tasks, resulting in less time developing or making sure that access is cut off when a contractor or developer leaves.

What if you could have the benefits of access to your cloud resources without any of those problems?

The Solution

Remote.It enables remote development, staging, and production resources to be directly available as if they are running directly on the developer's local machine. You can start coding independent of your location and multi or hybrid cloud environments.

Deployment is quick and easy: Taking away all of these hassles (Setup typically takes 5 minutes or less).

Access can be granted and removed centrally: With the Organization Management feature, access can be granted specifically by resource, unlike a VPN where you technically get access to the entire LAN. You can create roles that have specific permissions and assign the roles to members of the development team based on their need for access.

Add SAML integration: Where login credentials are controlled by your SAML provider, you just simply manage the role of the user. User management can be handled by either the Desktop Application, Web Portal, or GraphQL API. This creates Zero Trust Network Access (ZTNA).

When you connect to a resource such as MySQL via Remote.It, you will be given a localhost address and a unique port. You can use this in your development environment connection configuration, database query tools, etc. There is no connecting, disconnecting, and reconnecting when you change locations or your laptop wakes up from sleep. These on demand connections will go idle when you are not actively using it and go active when you do.

Setup
Setup will be creating a VM which will act as a jump box to reach your database resources, registering it in Remote.It, and then adding the services (access endpoints for the resources).

You will need:

Remote.It Desktop Application (version 3.5.2 or greater)
A Remote.It account
AWS console access to the account which can access the VPC where the database(s) reside

Example provided here is for AWS, but is similar for Google Cloud and Azure.

Follow along using this video or the written directions on Zero-Trust AWS Access & AWS RDS (Postgres and MySQL)

Step 1: Launch and register your Jump VM.
After signing in to the account and selecting the region where your database is hosted, launch a new instance from the EC2 dashboard. (You can leave the instance type at t2.micro).

Key Pair: Select an existing one for your account or create a new one. This is used for SSH access to this instance.
Network Setting: You can create a new security group and deselect SSH. This will ensure no exposed external ports. Don’t worry you can still access SSH from Remote.It.
Open Advanced Settings: We will be entering the one-line command into the User data field

Open Remote.It and get your one-line command:

In the "User data", field enter #!/bin/sh + return and your copied command

Click “Launch Instance”
Once the instance initializes, it will automatically appear in your Remote.It desktop with an SSH service.

Step 2: Add service endpoints for your database(s).
Get your internal endpoint address or internal IP address for your database (Example of MySQL at AWS show below)

Click “Add Service” and enter required information

Click Save.
In a couple of moments, you will be able to connect to the service.

Step 3: Create your org and/or add your team members (optional).
Remote.It provides a couple of different options to manage access to your resources which even includes limiting access to specific services.

Learn more about organizations
Learn more about sharing

Usage
Now that you have Remote.It set up, create the connection(s) you need. Remote.It will provide an address and port that resolves to localhost. Use this in your tools such as MySQL Workbench, PGAdmin, or in your IDE development environment variables where you normally put the address. The address is unique to you, but will be ready on demand whenever you use them. Try switching networks where your public IP changes. This connection is resilient to those changes and doesn’t require a VPN, but you have the confidence that the port(s) are not on the public internet.

For more information about how to use Remote.It, check out the support documentation here.