Connect to MongoDB Atlas Cluster without external IP

Hey,

We’re in the process of securing our environment and looking for a way to provide our developers with a secure way to establish a connection with a local client. We want to avoid adding a Network Access rule with whitelisting 0.0.0.0/0 and yet allow our devs to connect using AWS authentication.

We already tried 2 methods:

  1. Reverse proxy - in this method we tried to setup a reverse proxy (Nginx) to one of the clusters nodes but this method not works as expected when the selected node is not the primary (Compass fails to display the databases while mongosh displayed the dbs). We also had to use “Direct Connection”.
  2. SSH tunnel - we configured an openssh server and defined the SSH connection in Compass but failed to establish a connection.

What could be the way to establish a connection using a proxy or something similar, to an Atlas Cluster?

Thank you all in advance!

did you try SSH tunneling on a spare machine for this purpose? Can you describe how you set it up for port forwarding? It is possible you may have missed a step.

This thread may help for this case: linux - How to forward a port from one machine to another? - Unix & Linux Stack Exchange

Hey Yilmaz,
Thanks for replying!!

I’m using MongoDB Compass and configured the SSH (in the Advanced Connection Options/SSH tab) so the host is a host which its IP is whitelisted in the MongoDB Atlas cluster. The SSH connection is established successfully.

I’m not using an ordinary SSH tunnel, as described in the link provided.

Best,

Umm, is it putty on windows? if so, the tunneling is only from developer machines to that host machine. you also need a second step to forward that host to your cluster, set on the host itself.

dev pc port 27017 → tunnel → middle host port 27017 → forwarding → atlas cluster port 27017

port numbers may change to your needs.

No… it’s in Compass

It should be the native way to connect through SSH.

We are trying to establish a connection to a MongoDB Atlas Cluster:
mongodb+srv://the-domain-of-the-cluster.mongodb.net

The cluster is acessible by a specific IP, of a machine where we install an openssh-server, let’s call it the bastion.

We’d like to use the bastion as a proxy or something like that to be able to establish a connection, using a local client such as MongoDB Compass, to the Atlas Cluster, which only allow the bastion IP to connect.

Hope that makes it clear now :pray: :heart:

First, thanks for this image, I did not know Compass could do that.

Second, this is still the same as putty or other ssh commands. Compass uses your dev pc’s ssh port to tunnel to that host, but it connects to a data port on that machine that is supposed to run a mongodb server. Since this middle host does not run data server, hence comes the connection error.

you need to “also” set that host to forward that port you try to connect from Compass to Atlas cluster’s port. this is the second leg of forwarding you are missing.

I have done 2-machine setups previously but this one is about connecting “at least” 3 machines back to back. it is actually how hackers use to connect to a target through many leaps.

GatewayPorts and iptables methods in the link I provided mentions about how to do this briefly. you may search these terms for more details on official pages.

by the way, this method, as you see, requires a spare middle server. and you seem to have one. that is why I am trying to make it out with this method.

I am just sorry I do not have the exact steps to do the setup.

This sound too complex to me. Atlas is using SRV record to list the cluster nodes. I was assuming the Compass SSH capability knows to configure the tunnel to forward traffic to the nodes.

So the combination of providing an SRV endpoint (mongodb+srv://) with SSH server that is allowed to the cluster should makes it possible to connect to the cluster… Hope that this make sense.

I don’t know about SRV internals but “tunneling” is always from point A to point B through SSH port (mostly port 22) with secure encrypted connection. “Forwarding”, on the other hand, takes your packets from a designated port and redirects it as is to another machine. Here we want to go to point C. if SRV needs a port range, then the middle host should provide that too.

this also the case when you set your wifi router to your laptop for torrent programs or some games. have you ever done that to your router?

anyways, you are getting the grasp of it. Compass has A to B. you also need B to C to complete it. Compass handles the range from A to B, you may need a range from B to C (I guess it is mandatory at least for replicaset connections)

it might sound too complex as of now, but if you can keep reading and trying (trial&error) you will see it is just a bunch of commands to set some configuration. a few hours or a few days, it all depends on you. you just need to encourage yourself :wink:

I have found a script to set iptables on the middle host here: Add/Update iptable NAT port forward rule based on hostname instead of ip address (github.com)

you will need direct addresses of cluster servers. Open your Atlas page, Deploymeny->Database->Connect. there select “your application” and choose a pretty old driver version that gives you a connection string with “mongodb://xxx-shard-00-00.yyy…”. use those addresses in the script and incremental ports on the host (17-18-19 etc) for each server.

then use these ports within your connection string along with the ip of middle host.

The downside of this method is that the IP addresses of servers may change in time and you need to run the script to fix it.

Thanks for all the effort Yilmaz!

We ended up using sshuttle to initiate a VPN like connection over SSH, similar to what you suggested.

1 Like

that seems a nice one. saves from checking IP changes :slight_smile: as long as it is maintained and bug free it is great.

by the way, in case you revert to iptables method, I have found a possible ping bug in the script I linked: ping result may give a different output. my alpine setup gave “data bytes” instead of “bytes of data”. so head up.