I've just noticed I cannot authenticate on the Frankfurt node (46.165.222.246). My token is valid (checked it with the validity checker) and it works on all of the other clusters.

Has the config changed on the German cluster?

Hello parityboy! If I'm not mistaken you are using the old Frankfurt node, right?
I have one device still runing on it and it has no problems. So this might be related to your token or more precicely to mongo db.

Maybe use this as an opportunity to change to the new Frankfurt node on 46.165.222.248
In the long run CryptoStorm has planned to switch everything to the new certificates anyways so you will it be "forced" to install the new certificates eventually if you don't use the widget.

I'm writing this post with that node and I see no problem.....

@Guest

You may be right about MongoDB, considering the fact that it works on all of the other "original" nodes. I'd noticed that the connection had dropped; when I tried reconnecting OpenVPN kept giving me AUTH_FAILED (and still does). I'm guessing that the MongoDB shards on that cluster think that my token has expired, odd considering it was working up until yesterday on a 24x7 basis...

OK --

This has now happened on the original Iceland node, as well as the new Frankfurt node with the new certificate, and the new French node with the new certificate. I'm getting AUTH_FAILED, even though the token apparently has 11 days left to run. I'm currently on the original Montreal node, and the original USA node also allows me to connect.

Could you try to connect again and send the logs to our support email? I'll talk to the guys regardless, but just in case there's something useful in logs that will help

Done.

@Support

OK, I know this is a necro, but I'm having the same issue again. I can authenticate successfully on Canada, France, Iceland, and USA but Germany refuses to authenticate me. All of the nodes mentioned are post-Heartbleed raw instances and I'm connecting from Linux Mint 14.

Can I get you to send along some logs again to [email protected]? Thanks.

Also, anyone else reading this also having any issues with the frankfurt node?

Hi Support,

No problem here ... . Just to be sure, disconnected and reconnected again, no issues authenticating.

Greetz,

/Fermi

@Support

Sent. The fact that Fermi can connect, coupled with the fact that the error I'm getting is AUTH_FAILED, tells me there's an issue with the token. Cantus suddenly thinks the token is invalid, even though the tokenizer says otherwise.

@Support

I've just had an idea. Would it be possible to develop a (possibly internal-only) tool that can check a token against the databases on the nodes to make sure it's valid on all of the nodes? I'm thinking is could be used in scenarios such as:

1) User logs into a given node. This triggers an event of some kind, and a database query is launched against all of the other nodes to check that the token is valid on those nodes as well. If a node (like Cantus) says that the token is invalid, but the rest of the nodes have the token marked as valid, there's obviously an issue with Cantus, and perhaps the node that the user is logged into (for exanple Emerald) becomes authoritative and forcibly syncs the entry for that token on Cantus.

2) Similar to 1), except that the report is sent to the database/web app used by the Tokenizer Tool instead and that mechanism becomes authoritative and updates the trouble node.

3) Originally I was going to suggest the Tokenizer Tool produce a report showing which nodes will accept the token, but this is dependent on a user going out of their way to use the Tokenizer Tool.

Interesting ideas. I think I like #2 the best (with the slight modification that the report be sent to us to deal with) as - ideally - there should be few reports generated, and we could check to see which node is the correct one. In the event of a slight desync between nodes, the node that expires first could actually be the correct one (especially if replication between nodes isn't working correctly, for whatever reason). The load burden from increasing db queries is also something that needs to be considered, but I don't know how much of an affect it might have.

This is, however, just me spitballing off of your idea, and I think there could be some benefit to putting something like that in place, so I'll pass it around to the devs

@Support

Maybe we could invert the model so that the report is generated when authentication fails, rather than succeeds. That way, quite naturally fewer reports would be generated. Sync issues between nodes would interfere with this mechanism obviously, but that's a separate issue which ideally would need to be addressed first.

Speaking of which, have you considered using something like XMPP to send sync messages between nodes, as opposed to relying on MongoDB's built-in sync mechanism (which appears to have issues and which will likely get worse the more nodes are added)?