Replica set and VPN

Hi! I am trying to deploy replica set with two nodes - one on server at the Internet and the second at my local computer. But I have no static white ip so trying to use third VPN server which will forward all traffic from its public ip to port 27017 on my computer. So, I have three components:

  1. server with IP x.x.x.x for first node with running mongo
  2. VPN server with IP y.y.y.y which forward 27017 to my local computer inside this VPN
  3. local computer with running mongo

But when I try to initiate replica set from server node
rs.initiate( {
_id : “rs0”,
members: [
{ _id: 0, host: “x.x.x.x:27017” },
{ _id: 1, host: “y.y.y.y:27017” }
status of node with id=1 is only STARTUP (and then invalid after some time). At the logs of my local computer I can see that there was attempts to connecting: “Authentication succeeded” … “remote”:“x.x.x.x:33072”. But nothing happen and replica at my local computer does not created.
If I try to initialize replicas from local computer(after deleting it at the server), at local logs I see
“Authentication succeeded” … “remote”:"z.z.z.z:2355 but z.z.z.z is local ip but not as expected VPNs out ip.
And at the server logs nothing happened(no attempts to connect). So I think that there is a one side connection only and I do not know how to fix it. If I use setup with replicas on two internet servers than all fine and replicas created successfully, so I thing that problem in port-forwarding approach.
I use --bind_ip at both nodes, may be I should change it at my local computer?

1 Like

Hello! I tried to replicate your issue using an ssh tunnel as a stand-in for the vpn server. Unfortunately I wasn’t able to replicate the problem and I was able to build the replica set. Either way though from a MongoDB perspective your approach should definitely work. Don’t forget to post the solution if you end up working out what’s gone wrong!

Thank you for your reply. I do not find the reason and decided to put server inside my VPN and its working.

Welcome to the MongoDB Community Forums @111801!

I suspect the problem with your port forwarding approach may have been a mix of hostnames/IPs that were not consistently resolvable for all members of the replica set.

For example:

  • All members of the replica set need to be able to connect to each other on the IPs or hostnames listed in the replica set configuration.

  • A replica set member must be able to find its own hostname or IP in the replica set configuration.

You can workaround these requirements using hostnames in your replica set config and some manual tweaking of hostname resolution, but port forwarding isn’t as straightforward, flexible, or reliable as a VPN configuration when you are trying to host a distributed database.

Port forwarding routes traffic between limited ports and destinations; VPNs create bridges between networks that can route all traffic.