The installation was from WSL2 Docker.
Looks like after I enable LOG_LEVEL 7
2023-08-04 21:01:16 [WARNING] [libsdwan] [controller] operator(): failed to get SD: Invalid token, err code 1
2023-08-04 21:01:16 [DEBUG] [libsdwan] [controller] verify_token: {"alg":"ES256","kid":"REDACTEDA","typ":"DAT"} {"nt":"AN","aid":"REDACTED","did":"842600","jti":"REDACTED","iss":"twingate","aud":"bhakat","exp":1REDACTED,"iat":REDACTED,"ver":"4","tid":"REDACTED","rnw":REDACTED,"rnetid":"REDACTED"}
2023-08-04 21:01:16 [WARNING] [libsdwan] [controller] parse_verify_token: token verification failed: token expired
2023-08-04 21:01:16 [WARNING] [libsdwan] [controller] operator(): failed to get an access token: Invalid token
Hi Abhishek,
The likely culprit of the issue you’re seeing is some sort of time offset between what time our servers think it is and what time your machine thinks it is.
Unfortunately I can’t directly check as you’ve redacted the iat and exp values from your token, but if you take those values and convert them to human readable time using something like epochconverter.com you should be able to compare the times you see for iat (Issued At) and exp (Expires At) and the corresponding timestamp in the log (in this snippet it would be 2023-08-04 21:01:16
What is likely happening is the time on the machine/container is either ahead or behind of where it should be (likely due to an incorrect timezone), so your machine thinking it’s 9pm local time/whatever time GMT is asking our controller for a token, but it’s actually +/- an hour or more GMT and we’re responding with a token that is either issued/expires “before” you asked for it, or more than an hour afterwards, etc, which makes it “invalid”.
You may need to make sure your BIOS machine as well as your WSL2 Clocks are set “properly” - please see this Stack Overflow question/answer for details on the WSL2 side of things: WSL2 Clock is out of sync with Windows - Stack Overflow
Please let us know if you have any other questions.
Thanks,
-arthur
2023-08-05 01:13:15 [DEBUG] [libsdwan] [controller] verify_token: {"alg":"ES256","kid":"REDACTED","typ":"DAT"} {"nt":"AN","aid":"126513","did":"842600","jti":"REDACTED","iss":"twingate","aud":"bhakat","exp":1691181802,"iat":1691178202,"ver":"4","tid":"16942","rnw":1691178502,"rnetid":"29455"}
Doesn’t look like the clock issue. Any other reason token can fail to verify ?
I can see a token with exp still having 1 hour to go says expired.
What does this log line mean parse_verify_token ?
[libsdwan] [controller] parse_verify_token: token verification failed: token expired
Hi Abishek,
In the most recent log line you posted, your system is showing a timestamp of 01:13:15 - and the iat value is a timestamp of 1:43:22 PM GMT
Even taking out the potential large differences of hours, assuming they line up properly with your TZ vs GMT, as far as the connector can tell, the token was issued (x:x:22) 7 seconds AFTER it was asked for (x:x:15).
This is why the token is “expired”. the system time is not necessarily past it’s exp time, it’s just “outside” of the iat > exp range.
There is likely something causing your clock to be off by a few seconds which is resulting in this issue.
Can you verify that the host system is actively syncing to an NTP server, and that your container is inheriting that time?
Thanks,
-arthur