Atlas Authentication: IP Whitelist from Network

Hi,
I got this message error while trying to connect Atlas through mongo shell.

$ mongo “mongodb+srv://cluster0-jxeqq.mongodb.net/test” --username m001-student -password m001-mongodb-basics
MongoDB shell version v4.2.3
connecting to: mongodb://cluster0-shard-00-02-jxeqq.mongodb.net:27017,cluster0-shard-00-00-jxeqq.mongodb.net:27017,cluster0-shard-00-01-jxeqq.mongodb.net:27017/test?compressors=disabled&gssapiServiceName=mongodb&ssl=true

*** It looks like this is a MongoDB Atlas cluster. Please ensure that your IP whitelist allows connections from your network.

2020-03-19T03:48:10.758+0700 E QUERY [js] Error: Authentication failed. :
connect@src/mongo/shell/mongo.js:341:17
@(connect):2:6
2020-03-19T03:48:10.768+0700 F - [main] exception: connect failed
2020-03-19T03:48:10.768+0700 E - [main] exiting with code 1

Not too sure why it says it could not make the connection since I don’t have a firewall set up that would block it. Moreover, the telnets and the ping tests were successful too including Compass being able to access to the server.

I was able to connect with the exact same string copy-n-pasted from your post.

It is something on your side.

May it is the quotes around the connection string. Try to use single quotes.

Not working yet as shown below. But I will keep on looking on my side to see what else is blocking. Thanks for the confirmation.

$ mongo 'mongodb+srv://cluster0-jxeqq.mongodb.net/test' --username m001-student -password m001-mongodb-basics
MongoDB shell version v4.2.3
connecting to: mongodb://cluster0-shard-00-00-jxeqq.mongodb.net:27017,cluster0-shard-00-02-jxeqq.mongodb.net:27017,cluster0-shard-00-01-jxeqq.mongodb.net:27017/test?compressors=disabled&gssapiServiceName=mongodb&ssl=true


*** It looks like this is a MongoDB Atlas cluster. Please ensure that your IP whitelist allows connections from your network.


2020-03-19T04:12:43.424+0700 E  QUERY    [js] Error: Authentication failed. :
connect@src/mongo/shell/mongo.js:341:17
@(connect):2:6
2020-03-19T04:12:43.436+0700 F  -        [main] exception: connect failed
2020-03-19T04:12:43.436+0700 E  -        [main] exiting with code 1

I don’t know if this helps, but my mongo info is:

$ mongo --version
MongoDB shell version v4.2.3
git version: 6874650b362138df74be53d366bbefc321ea32d4
OpenSSL version: OpenSSL 1.1.1d  10 Sep 2019
allocator: tcmalloc
modules: none
build environment:
    distmod: ubuntu1804
    distarch: x86_64
    target_arch: x86_64

Here is mine on Arch linux.

: steevej @ asus-laptop ; mongo --version
MongoDB shell version v4.0.5
git version: 3739429dd92b92d1b0ab120911a23d50bf03c412
OpenSSL version: OpenSSL 1.1.1b  26 Feb 2019
allocator: tcmalloc
modules: none
build environment:
    distarch: x86_64
    target_arch: x86_64
: steevej @ asus-laptop ; 

Some people can’t connect with the SRV string but can using seedlist. I don’t know why this happens but I have my suspicions. So, number 1 should work but could you please try all of them and report back?

  1. mongo "mongodb://cluster0-shard-00-02-jxeqq.mongodb.net:27017,cluster0-shard-00-00-jxeqq.mongodb.net:27017,cluster0-shard-00-01-jxeqq.mongodb.net:27017/test?authSource=admin&replicaSet=Cluster0-shard-0&ssl=true" --username m001-student --password m001-mongodb-basics

  2. mongo "mongodb+srv://cluster0-jxeqq.mongodb.net/admin" --username m001-student --password m001-mongodb-basics

  3. mongo "mongodb+srv://cluster0-jxeqq.mongodb.net/admin?authSource=admin" --username m001-student --password m001-mongodb-basics

  4. mongo "mongodb+srv://cluster0-jxeqq.mongodb.net/admin?authSource=admin&replSet=Cluster0-shard-0" --username m001-student --password m001-mongodb-basics

  5. mongo "mongodb+srv://cluster0-jxeqq.mongodb.net/admin?authSource=admin&replSet=Cluster0-shard-0&readPreference=primary" --username m001-student --password m001-mongodb-basics

  6. mongo "mongodb+srv://cluster0-jxeqq.mongodb.net/admin?authSource=admin&replSet=Cluster0-shard-0&readPreference=primary&ssl=true" --username m001-student --password m001-mongodb-basics

  7. mongo "mongodb+srv://cluster0-jxeqq.mongodb.net/admin?authSource=admin&replSet=Cluster0-shard-0&readPreference=primary&tls=true" --username m001-student --password m001-mongodb-basics

1 Like

Excellent! Number 1 works. Thank you so much for the help! Appreciate it.

Any feedback on the others? :slight_smile:

Watching the video again, correct me if I’m wrong, it looks like it has to be the reordering of the shards. Thanks again for the help.

I can only surmise after you’ve tested all the other connection strings and confirm which ones work and which don’t.

Hi 007_jb,

All the connection strings you’ve sent me (1 - 7) worked. The only recurring warning is:

WARNING: shell and server versions do not match

My MongoDB shell version is v4.2.3.
My MongoDB server version is 3.6.17.

Do you think this could be what caused the problem with the original string?

Thanks.

It’s interesting that 2 - 7 worked!

I’m using the same shell version as you so that warning couldn’t be the problem.

Can you confirm which country you’re located? And also try one more:
mongo "mongodb+srv://cluster0-jxeqq.mongodb.net/test?authSource=admin" --username m001-student --password m001-mongodb-basics

Hi 007_jb,

I’m from Indonesia and the connection string you’ve sent worked too.

$ mongo “mongodb+srv://cluster0-jxeqq.mongodb.net/test?authSource=admin” --username m001-student --password m001-mongodb-basics

MongoDB shell version v4.2.3

connecting to: mongodb://cluster0-shard-00-00-jxeqq.mongodb.net:27017,cluster0-shard-00-01-jxeqq.mongodb.net:27017,cluster0-shard-00-02-jxeqq.mongodb.net:27017/test?authSource=admin&compressors=disabled&gssapiServiceName=mongodb&replicaSet=Cluster0-shard-0&ssl=true

2020-03-19T11:56:38.155+0700 I NETWORK [js] Starting new replica set monitor for Cluster0-shard-0/cluster0-shard-00-00-jxeqq.mongodb.net:27017,cluster0-shard-00-01-jxeqq.mongodb.net:27017,cluster0-shard-00-02-jxeqq.mongodb.net:27017

2020-03-19T11:56:38.155+0700 I CONNPOOL [ReplicaSetMonitor-TaskExecutor] Connecting to cluster0-shard-00-00-jxeqq.mongodb.net:27017

2020-03-19T11:56:38.156+0700 I CONNPOOL [ReplicaSetMonitor-TaskExecutor] Connecting to cluster0-shard-00-02-jxeqq.mongodb.net:27017

2020-03-19T11:56:38.156+0700 I CONNPOOL [ReplicaSetMonitor-TaskExecutor] Connecting to cluster0-shard-00-01-jxeqq.mongodb.net:27017

2020-03-19T11:56:39.720+0700 I NETWORK [ReplicaSetMonitor-TaskExecutor] Confirmed replica set for Cluster0-shard-0 is Cluster0-shard-0/cluster0-shard-00-00-jxeqq.mongodb.net:27017,cluster0-shard-00-01-jxeqq.mongodb.net:27017,cluster0-shard-00-02-jxeqq.mongodb.net:27017

Implicit session: session { “id” : UUID(“2e2da9ab-810a-49f8-866e-e9ae562dbc84”) }

MongoDB server version: 3.6.17

WARNING: shell and server versions do not match

MongoDB Enterprise Cluster0-shard-0:PRIMARY>

Very good!

Can you please try one more? And if it fails, please share the output.
mongo "mongodb+srv://m001-student:m001-mongodb-basics@cluster0-jxeqq.mongodb.net/test"

From post #1 :arrow_up:, the authentication db and replica set options aren’t part of the URI (by default it should) and as a result it’s wrongly authenticating against the test db hence the authentication error.
Amazon Route 53 is the DNS service to which the SRV (list of the 3 hostnames and port) and TXT (string of options authSource=admin&replicaSet=Cluster0-shard-0) are looked up. In your case, SRV is resolving ok, but TXT somehow isn’t. This indicates that TXT is either failing to return the string of options or the resulting string isn’t getting concatenated to the URI.

Now your problem is slightly different from the other cases I’ve seen (i.e. unable to connect with a complete resolved URI), however, all of them were located in Asia. So I wonder if it’s possible for the DNS server of your ISP to cause some interference.

Here’s the documentation for the connection string URI format.

Let’s rope in @Shubham_Ranjan to feed this back to his Dev colleagues.

1 Like

Great job @007_jb!

Hi @Eric_04039,

Thanks for being patient with us. Can you please try this string one more time and share the output with us ?

mongo "mongodb+srv://cluster0-jxeqq.mongodb.net/test" --username m001-student -password m001-mongodb-basics

Thanks,
Shubham Ranjan
Curriculum Services Engineer

Hi Shubham Ranjan,

I’ve tested the connection string that you’ve sent me and it works too as shown below. I guess you guys have fixed it. Good job! Keep up the good work. :smile: :+1:

$ mongo "mongodb+srv://cluster0-jxeqq.mongodb.net/test" --username m001-student -password m001-mongodb-basics
MongoDB shell version v4.2.3
connecting to: mongodb://cluster0-shard-00-00-jxeqq.mongodb.net:27017,cluster0-shard-00-01-jxeqq.mongodb.net:27017,cluster0-shard-00-02-jxeqq.mongodb.net:27017/test?authSource=admin&compressors=disabled&gssapiServiceName=mongodb&replicaSet=Cluster0-shard-0&ssl=true
2020-03-19T17:46:08.256+0700 I  NETWORK  [js] Starting new replica set monitor for Cluster0-shard-0/cluster0-shard-00-00-jxeqq.mongodb.net:27017,cluster0-shard-00-01-jxeqq.mongodb.net:27017,cluster0-shard-00-02-jxeqq.mongodb.net:27017
2020-03-19T17:46:08.256+0700 I  CONNPOOL [ReplicaSetMonitor-TaskExecutor] Connecting to cluster0-shard-00-00-jxeqq.mongodb.net:27017
2020-03-19T17:46:08.256+0700 I  CONNPOOL [ReplicaSetMonitor-TaskExecutor] Connecting to cluster0-shard-00-01-jxeqq.mongodb.net:27017
2020-03-19T17:46:08.257+0700 I  CONNPOOL [ReplicaSetMonitor-TaskExecutor] Connecting to cluster0-shard-00-02-jxeqq.mongodb.net:27017
2020-03-19T17:46:10.602+0700 I  NETWORK  [ReplicaSetMonitor-TaskExecutor] Confirmed replica set for Cluster0-shard-0 is Cluster0-shard-0/cluster0-shard-00-00-jxeqq.mongodb.net:27017,cluster0-shard-00-01-jxeqq.mongodb.net:27017,cluster0-shard-00-02-jxeqq.mongodb.net:27017
Implicit session: session { "id" : UUID("26a02be7-2b8f-4f24-85aa-5fe839c16791") }
MongoDB server version: 3.6.17
WARNING: shell and server versions do not match
MongoDB Enterprise Cluster0-shard-0:PRIMARY> 

Best regards,
Eric O. Jonathan

Are you running it from a different network or machine?

I’m running on my laptop. Maybe networks are different since I use different wifi at different places.

Yep, this one has the admin authSource and replicaSet options appended to the URI which is why it happily connected.

Unless you can trace your steps to the location you were connected from the very first time, it would be hard to say with certainty what the problem is. But I’m still leaning towards an Internet Server Provider related issue.

1 Like