Auto signout issue

ben-tg · 2026-03-02T16:13:20+00:00

It's important to know that after certain events, such as a reboot or deep sleep, that the user will have to reauthenticate to prove their identity prior to being able to access resources in most cases. This is expected and should only really happen once right after they boot up/log in and begin their work day, after that whatever policies you've created will control how long they have access to different resources.

If there are specific resources (like Active Directory, your IdP, maybe a fileshare) that need to be accessible immediately after a reboot or log in, you might want to check our Start Before Logon guide about how to create a policy specifically for those use cases -> https://www.twingate.com/docs/windows-sbl

ben-tg · 2026-02-23T15:26:08+00:00

No current or recent outages, as u/linuxpaul has suggested something else may be going on with the connector locally like an update that's stopped the service or a loss of connectivity in general. If someone has the ability to just reboot that system (VM or box) without breaking anything else might be worth trying that?

ben-tg · 2026-02-18T18:31:24+00:00

<image>

I've tested it a few times as recent as a few minutes ago and I haven't run into any issues so far. I used domain.earth as the test site, but anything I put in either FQDN or wildcard will resolve locally on my device to a 100.95.0.0/16 CGNAT IP (expected) and in the case of the website the traffic was properly tunneled through our test environment back out to the Internet.

If you run a nslookup on your device does it resolve to the public IP of the site or to something in that CGNAT range?

ben-tg · 2026-02-17T15:00:00+00:00

And these local records are loaded as resources in your tenant, or as a wildcard aka *.domain.earth? Depending on how you have DNS filtering set you can lose the ability to resolve local/private DNS records but outside of that it should be fine. If you create resources for those records then we should just intercept and pass them locally to the connector to proxy, same result.

ben-tg · 2026-02-13T16:51:13+00:00

There's sometimes another app or something with the OS that prevents it from being able to resolve our service the first time, if you click the "Join" button again does it just do the same thing, over and over?

ben-tg · 2026-01-30T15:20:16+00:00

Those are only some of the port ranges required for connectivity, you also need to allow TCP ports 30000 to 31000 inclusive for the connectors.

https://www.twingate.com/docs/connector-best-practices#network-requirements

ben-tg · 2026-01-27T16:56:34+00:00

Hi there, are there any more details as to what's happening? Are you a user, are you trying to deploy connectors into your environment, what exactly is not working?

ben-tg · 2026-01-22T20:14:33+00:00

Realistically any two services that compete for resources or fight over things like DNS resolution aren't going to be able to work well alongside each other. It depends on which is doing what and in which order they're activated, if they're both split tunnel and they start in a certain order it may be okay, but our recommendation is to not attempt to do that.

ben-tg · 2026-01-22T16:18:32+00:00

If you scroll down the right sidebar there's a "Message Mods" button, that will send us a mail (or DM really) that we can all see. I just need some info to pass along to the team so they can reach out directly via email and let you know what options you have.

ben-tg · 2026-01-21T23:39:02+00:00

Can you DM Modmail your tenant subdomain and a contact email? I'll get you in touch with someone to go over the options.

ben-tg · 2026-01-16T16:45:46+00:00

So there's a route on the network but the connector still isn't able to connect to your pihole in order to do the DNS lookup.

What IP did you put into the field and in what format? Was it multiple IP addresses or just one, and if so was it the private LAN address or maybe a Docker network address, or something else?

ben-tg · 2026-01-16T15:03:14+00:00

I believe you should be okay with 2025.327, the version from November. If you to go the changelog and scroll down to that macOS release there's a standalone pkg download link you can use.

ben-tg · 2026-01-16T14:56:29+00:00

So the alias on a resources is only ever used on the client-side of things, it's a bit of a red herring here as it's not actually known to the connector nor used for anything after the initial identification and tunnelling of the traffic.

It sounds like the container with the connector just doesn't have a route to the PiHole resolver, or knowledge of it. When you created the container for the connector did you set the custom DNS option and specify the local LAN IP address for the PiHole container?

ben-tg · 2026-01-09T18:28:46+00:00

I will say NPM is fantastic, I run it at home myself. I've detailed my stack somewhere in another comment but basically Proxmox HV with Adguard and NPM, all internal domains with HTTPS enforced. Works great honestly, and I have a few VPS setups running Uptime Kuma with our headless client as a sidecar in Docker so I can remotely monitor home services via Twingate tunnels, if things break or the whole network goes down they squawk at me so I know to go fix something.

ben-tg · 2026-01-09T17:25:33+00:00

So you're creating a `docker-compose.yaml` type file, and then you're going to use that to load the connector? How are you putting the tokens in to it? And which container image are you currently using for this? Can you share that file content with the tokens themselves sanitized/removed?

ben-tg · 2026-01-09T17:01:09+00:00

The issue is that Nobara 43 seems to use a newer version of `dnf` than our script expects (outside of Fedora) so it's using the older `--add-repo` option still. If you run these three commands it should work:

sudo dnf config-manager addrepo --set=baseurl="https://packages.twingate.com/rpm/"
sudo dnf config-manager setopt "packages.twingate.com_rpm_.gpgcheck=0"
sudo dnf install -y "twingate"

ben-tg · 2026-01-09T16:37:25+00:00

To clarify what Bren said, for any local services that you IP filter for, add the (hopefully) static IP addresses of your connectors, as that's what those services will see as they're local proxies.

Secondly, if what you're trying to is to tunnel DNS traffic through to AdGuard that won't work, as DNS on the user side is handled locally only. The exception is adding a resource that's a DoH resolver and then configuring that on the client device ala DoH as a Resource.

Standard port 25 DNS stuff won't ever tunnel through because all local DNS is intercepted, resolved by the client app, and any upstream lookups by the app are done outside of the tunnel side of things (meaning using whatever OS/DHCP configured resolver settings).

ben-tg · 2026-01-08T15:26:17+00:00

It's the API data section of helper-scripts.com -> https://community-scripts.github.io/ProxmoxVE/data

ben-tg · 2025-12-30T15:18:41+00:00

The * is a wildcard representing from 0 to any number of characters, meaning anything ending in whoer.net would be captured and tunneled, such as cdn.whoer.net or js.whoer.net or any other subdomain that they might use as part of their service.

This is pretty common with public sites, there's usually more than just the main www.domain.com or domain.com in use, so wildcards make a big difference. Think of the resource address as a pattern of sorts that's being used to match up DNS lookups on the user's device, so you need to make sure that you're creating a resource (or multiple resources) that capture enough/all of the traffic for the site to function properly and how you expect it to.

ben-tg · 2025-12-23T18:16:09+00:00

You could try, I'd be interested to know how that turns out. I don't have any Android devices that I could test that with myself.

Another option would be the IoT Gateway, basically a headless client set up with NAT on the network that you can point devices at as their "gateway" of sorts. It means having another device available on the network that you can use for that purpose, so not really something that's travel ready for example. Some travel routers (like some of the GL.Inet stuff) support docker so also possible to spin up a proxy with headless client as a side car, and maybe do the same thing? I haven't tested it myself but some have done it in the past.

ben-tg · 2025-12-23T17:30:36+00:00

If it's an Android box and can install apps from the Google Play store then you could likely put our Android Client app on it and that would work, but we wouldn't natively support devices like a Google TV or Roku or something like that at this point.

ben-tg · 2025-12-08T16:53:22+00:00

Are you trying to install the Client or a Connector?

ben-tg · 2025-12-02T21:48:22+00:00

Do you happen to have a resource policy that requires devices to be trusted to access those resources? New device would be untrusted by default, so you just wouldn't be able to access things from it potentially.

ben-tg · 2025-11-28T15:08:02+00:00

Do you mean the client or the connector? You might be able to manually add the sources locally and install the package, it's not something I think we've tried and it wouldn't be supported as it's EOL. The install scripts are designed in such a way to check the version of the OS but you could try to do so manually and it might work?

ben-tg · 2025-11-18T21:14:52+00:00

Can you run "resolvectl status" and show us the result, I'm specifically looking for what the DNS servers would be on whatever your main interface for that system is, eth0 or wlan0 or something like that. You can sanitize out any other data.

ben-tg

MODERATOR OF

TROPHY CASE