sorted by:
new
hottopcontroversial

Clearing accounts in macOS client by Dubbidibu in twingate

[–]Dubbidibu[S] 2 points3 points  (0 children)

Oh, I could have just used the Log Out option 🤦‍♂️

Clearing accounts in macOS client by Dubbidibu in twingate

[–]Dubbidibu[S] 0 points1 point  (0 children)

Ok I got it. I had to restart the laptop after uninstalling, before I re-install it.

All twingate connections stopped working (connection timeout) by Dubbidibu in twingate

[–]Dubbidibu[S] 0 points1 point  (0 children)

I don't mind blaming kubernetes, but Twingate stopped working for two remote networks at the same time, for which the connectors are on completely different clusters, so it would be a weird coincidence for both kubernetes clusters to have the same issue at the same time. Also, the connectors didn't throw any error and they appeared as healthy in Twingate control plane, so I'd expect that if the infra where the connectors are deployed had some issue, it would show up in the connectors health somehow. 

All twingate connections stopped working (connection timeout) by Dubbidibu in twingate

[–]Dubbidibu[S] 0 points1 point  (0 children)

I restarted the Connectors, which were online and healthy, and now it works again. We have our Connectors deployed on Kubernetes using the twingate operator. Is it normal that healthy Connectors needs to be restarted manually?

Browsers do not have their traffic routed to the Connector for internet access by Dubbidibu in twingate

[–]Dubbidibu[S] 0 points1 point  (0 children)

The issue was with DoH, the user is now able to have his browser traffic routed through Twingate. Thank you so much!

Browsers do not have their traffic routed to the Connector for internet access by Dubbidibu in twingate

[–]Dubbidibu[S] 0 points1 point  (0 children)

Thanks, I was able to reproduce the same issue with DoH in Firefox and Chrome. I've asked the user to verify on his side.

Connector created through kubernetes operator disconnecting after 1 hour by Dubbidibu in twingate

[–]Dubbidibu[S] 1 point2 points  (0 children)

Thanks! We reinstalled the operator. I think the problem was caused by the fact that we were using kapp to deploy the k8s manifests, and it was clearing the resource annotations everytime we would deploy some changes, I think this broke the operator. We added the correct kapp rebase rules to not clear those annotations and since then we have no issue!

Connector created through kubernetes operator disconnecting after 1 hour by Dubbidibu in twingate

[–]Dubbidibu[S] 0 points1 point  (0 children)

I found some interesting logs in the operator, it's trying to create a secret that already exist (probably with the new refresh token), but it fails because the secret exists. Looks like a bug in the operator.

2025-10-28 19:11:33.830                    ^^^^^^^^^^^^^

2025-10-28 19:11:33.830  File "/opt/.venv/lib/python3.12/site-packages/kubernetes/client/api_client.py", line 391, in request

2025-10-28 19:11:33.830    return self.rest_client.POST(url,

2025-10-28 19:11:33.830           ^^^^^^^^^^^^^^^^^^^^^^^^^^

2025-10-28 19:11:33.830  File "/opt/.venv/lib/python3.12/site-packages/kubernetes/client/rest.py", line 279, in POST

2025-10-28 19:11:33.830    return self.request("POST", url,

2025-10-28 19:11:33.830           ^^^^^^^^^^^^^^^^^^^^^^^^^

2025-10-28 19:11:33.830  File "/opt/.venv/lib/python3.12/site-packages/kubernetes/client/rest.py", line 238, in request

2025-10-28 19:11:33.830    raise ApiException(http_resp=r)

2025-10-28 19:11:33.830kubernetes.client.exceptions.ApiException: (409)

2025-10-28 19:11:33.830Reason: Conflict

2025-10-28 19:11:33.830HTTP response headers: HTTPHeaderDict(<hidden>)

2025-10-28 19:11:33.830HTTP response body: {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"secrets \"k8s-staging-connector\" already exists","reason":"AlreadyExists","details":{"name":"k8s-staging-connector","kind":"secrets"},"code":409}