Gluetun repeatedly logged a successful connection to a NordVPN US server followed by AUTHFAILED, this happens all the time throughout various parts of the day or the week. My NordVPN credentials work on other devices and services. After changing the VPN city to another US location, SparkBox reported that the VPN was up with a US exit. The cause of the original rejection is still unknown. Can you check why that location failed authentication and whether SparkBox can make this easier to diagnose?
5 replies
Chris wrote:
Thanks for laying out what you saw. Since another US exit came up, that points toward the original connection attempt rather than proving your credentials are wrong, but the post alone doesn't show why that endpoint returned AUTHFAILED. Could you share your SparkBox version and a few Gluetun log lines around one occurrence, with usernames, passwords, tokens, server addresses, and any media names removed? Please don't paste a full config or credential file. That will let us distinguish what the log actually reports before suggesting a change.
Nultima wrote:
I checked the version and Gluetun logs; the logs I can see don’t show AUTHFAILED. They show a TLS timeout on one connection attempt, followed by a successful connection to another server. SparkBox version: 1.6.834. Sanitized Gluetun log lines around the connection attempt: 03:48:35Z UDP connection attempt to [redacted server]:1194 03:49:35Z TLS key negotiation failed to occur within 60 seconds 03:49:35Z TLS handshake failed 03:49:50Z UDP connection attempt to [redacted server]:1194 03:49:50Z Peer Connection Initiated 03:49:52Z Initialization Sequence Completed 03:49:54Z Public IP lookup reported a United States exit These log lines show a TLS timeout followed by a successful connection. They don’t show AUTHFAILED, so I can’t confirm that error from the available logs. However, before all of this: There was a Gluetun log that shows a successful connection to Nord’s us[redacted].nordvpn.com server, followed by Nord returning AUTHFAILED repeatedly. So the tunnel reaches Nord; the failure is at authentication on that connection. The logs don’t show why Nord rejected it, and they don’t prove your credentials are wrong. Given that Nord works for me elsewhere on other devides, a rejection tied to this particular server or its backend is a reasonable possibility—but it’s not confirmed. The cleanest test is to try a different NordVPN US location, but we have tired that before and it still caused issues, so it occasionally still connects and it points to the original serve
Chris wrote:
Thanks for checking and for correcting the earlier picture. This excerpt shows a TLS negotiation timeout followed by a successful connection; it does not show AUTHFAILED, so it cannot establish an authentication rejection or its cause. The separate earlier AUTHFAILED report remains unverified from these lines. If you still have that specific event, could you share only the few sanitized lines around the exact AUTHFAILED message, with the server address and any credentials removed?
Nultima wrote:
"The Gluetun log I just checked shows a TLS negotiation timeout to one NordVPN endpoint. Fifteen seconds later, it connects to another endpoint, us[redacted].nordvpn.com, and completes initialization. There’s no AUTHFAILED in this log. My earlier claim that Nord returned AUTHFAILED repeatedly wasn’t supported by the logs I can verify, and I shouldn’t have presented it as fact. That fits intermittent connection trouble better than an authentication rejection, but it doesn’t establish why the first endpoint timed out—or confirm what happened in the earlier event you described."
Chris wrote:
Thanks for checking and correcting that. The excerpt you verified shows one TLS negotiation timeout, followed by a successful connection to another endpoint; it does not show an authentication failure, and it doesn’t tell us why that first attempt timed out. There’s no evidence here that your credentials are the problem, so I wouldn’t change them based on this log. If the timeout happens again, the useful next check is a short sanitized excerpt covering that attempt and the following connection; please keep server addresses and credentials redacted.