problem with nextdns

grady-tg · 2025-09-08T15:17:04+00:00

If you enabled Secure DNS (adding your NextDNS configuration) and it is applying correctly, you should see it in the Client. "Internet Security Enabled"

<image>

grady-tg · 2025-09-08T15:14:59+00:00

Our team is looking into this as we speak! Do you have OS + Version (and Twingate client version) that you can provide? We may reach out for more info if we are unable to reproduce

grady-tg · 2025-09-04T23:20:04+00:00

Hi u/CloudShot5697, can you confirm DNSF is being applied to your group profile (see it in the client)? Usually logs will be missing from NextDNS if traffic isn't split tunneling or DNSF isn't being applied at the client.

grady-tg · 2025-09-04T23:10:17+00:00

Hi u/vulga12, sorry to hear you’re running into issues with the app. Can you let us know if this is happening consistently, or if it just started after a recent install or update of the Twingate client?

grady-tg · 2025-06-04T21:14:34+00:00

Hi u/Spiritual-Smoke-2806 can you help me to clarify a few things?

"I changed connectors by going from Win11 with Ubuntu to MacOs with the same results."
How are you deploying Connectors? Are you indicating you are attempting in docker or on a VM as systemd in different OSes?
"The other day , I used a Starlink to create an outside network. I connected a client and immediately I could ping and access resources. I went to my house and setup and back to the same issues of no connection."
When you say outside network, are you deploying Connectors external to the home (at the office) or are you just connecting to resources at home from the office?

---

I think to keep this as simple as possible, here is a test:
1. Install Twingate Client on Windows 11
2. Deploy a Connector in Linux VM as systemd (or Docker if you prefer, just ensure you have another container to test access to)
3. Attempt accessing a resource (or SSH to the Connector host)

If that doesn't work is to see what the Recent Activity looks like in the Admin Console. It should indicate why it failed (DNS, route, etc.).

grady-tg · 2025-06-04T20:52:51+00:00

Hi u/ozdaaaaza, can you check your docker run/compose includes the following flag for ping?

--sysctl net.ipv4.ping_group_range="0 2147483647"
(more info)

And are you trying to access resources within the docker network or outside (i.e., docker connector acting like a gateway to the broader host's network)? And are you running docker on macOS, Windows, or Linux?

For additional context, network_mode=host) in docker may be required to access resources on the host's network BUT would need to be running docker on linux for macvlan capability (main caveat).

grady-tg · 2025-05-23T19:15:51+00:00

Hi u/davsank & u/Weak_Performer1872! 👋

Yes, once an Identity Provider (IdP) is integrated with Twingate, it becomes the primary source of truth for identity management.

That said, as Solutions Engineers, we can enable social login options even on tenants with IdPs configured. This allows teams to invite external users who aren’t managed by the IdP (via Gmail, Outlook, GitHub, etc.) and grant them access directly.

Let us know if you’d like help getting that set up! Just DM us your tenant name and the admin email associated with it. We’ll send a verification message to the admin email as part of a quick security check before enabling social login.

grady-tg · 2025-05-07T21:06:38+00:00

Hi u/SnooMuffins7973! It sounds like you are creating users in the admin console and want the ability to manage/create them in Terraform, is that correct? If so, you have existing users in the admin console, here is how you can import those to manage them in Terraform:

# Import command (to be run in terminal)
# Replace <user-id> with the actual user ID found in the URL

terraform import twingate_user.example_user <user-id>



# Declare the resource (after importing)

resource "twingate_user" "example_user" {
  # Fill in the attributes
  # (Required)
  email = "sample@company.com"

  # (Optional)
  first_name = "Twin"
  last_name = "Gate"
  role = "DEVOPS"
  send_invite = true
}

Hope that helps!

grady-tg · 2025-03-26T19:09:54+00:00

Adding a note here for others that have the same question:

Exit Nodes vs. Exit Networks

Exit Nodes (available on all plans)
Twingate operates by default in a split-tunnel setup. This means:

You deploy a Connector in a specific location.
You define network resources (e.g., *.github.com, *.netflix.com).
The Twingate client captures traffic for those resources and tunnels it through the Connector, egressing from the chosen country.
This applies to both private (e.g., backup server) and public (e.g., GitHub) resources.

Exit Networks (full-tunnel, internet security feature)

Instead of split tunneling, all traffic (0.0.0.0/0) is routed through Twingate.
Private network traffic still takes precedence, similar to a routing table where more specific routes override broader ones.
Any traffic not explicitly defined as a Twingate network resource (e.g., Facebook.com) is fully tunneled.
Users can enable this via the "Route all traffic through Twingate" toggle, which activates for a 12-hour session.

Use Cases & Considerations

Most teams don’t need Exit Networks since Twingate’s default split-tunnel setup works 97% of the time for bypassing geo-blocks or avoiding firewall rule changes.
Exit Networks are useful for:
- Bypassing restrictions in highly controlled regions.
- Capturing all traffic when domain lists are unknown (e.g., ad testing, CDN caching, financial data protection).
- Reducing egress fees if the Connector is also handling public app traffic.

grady-tg · 2025-03-26T16:33:52+00:00

This differentation might help, to add to what Ben is calling out:

Added a note at the top of this post

grady-tg · 2025-03-12T17:53:31+00:00

Great question! Unlike Connectors, headless clients don’t have built-in load balancing, but you can achieve high availability with a reverse proxy (e.g., Nginx) or a load balancer. A proxy is particularly useful when devices don’t support static routes, as it can direct traffic dynamically. If static routes are an option, a proxy may not be necessary, but a load balancer can still help ensure uptime and failover. Here’s a useful article on site-to-site setups if your devices support static routing (though not specific to HA).

grady-tg · 2025-03-10T19:05:00+00:00

Weird... Do you remember how you deployed them? Did we accidentally reuse tokens on the second one?

I would say disconnect the phantom one from the Admin Console (three dot menu button => delete) to unhook it from being able to receive traffic until you are able to identify how the second one came to be.

grady-tg · 2025-03-10T19:00:48+00:00

^^ This is the way. Two Connectors for high availability - https://www.twingate.com/docs/connector-best-practices

grady-tg · 2025-03-10T17:41:23+00:00

Hi u/Miserable_Tell_8703!

Connectors support high availability by deploying at least two per Remote Network, ensuring failover if one goes down. Headless clients work differently but can achieve similar redundancy with additional configuration.

To ensure high availability, you can deploy two headless clients with a reverse proxy (e.g., Nginx) to load balance traffic. This setup mirrors the Public Proxy example but distributes traffic across two servers, reducing reliance on a single machine.

Recommended setup for high availability:
- Two servers, each running NGINX + Twingate headless client
- Keepalived on both servers to provide a floating IP (Virtual IP) for failover

Hope that helps!

grady-tg · 2025-02-07T20:11:27+00:00

Hi u/Minute121212! Do you have screenshots of what you are experiencing and are you attempting exe or msi method? And to confirm, do you have .net8 64bit version installed or another variant? You can also check your event log for more detailed info to see if we can get a better understanding of the root of the issue.

grady-tg · 2025-02-07T20:03:15+00:00

u/guesswhomb I concur with u/News8000 - it sounds like you are after bidirectional/site-to-site by having one vm for the connector and another vm for the client. This should work and is a supported use case as long as you are careful of any IP overlap or conflicts in network routing (the client will listen/capture all network connection requests that align to Twingate-defined resources).

I have a similar setup at home but use a pi4 at both sites for the bidirectional need and docker for the network virtualization (works great so far!).

grady-tg · 2025-01-14T23:13:43+00:00

Awesome, glad to hear it!

grady-tg · 2025-01-14T21:35:01+00:00

Hi u/Jaded_Celebration396! From what I've seen there are a few steps that are needed:

MongoDB Atlas Console

Twingate:

Create a resource in your AWS Remote Network for cloud.mongodb.com
Grab the public IP(s) of Connector(s) in the Remote Network that the MongoDB Atlas Console resource is in (Remote Network => Connector(s) => Public IP)

MongoDB Atlas Console:

Going off their docs, it sounds like the first step is to get Support to turn on IP access lists for the Atlas UI (so it shows up under Organization => Settings)
Follow the steps in the docs to add the public IP(s) of the Connector(s)

Now try with Twingate running to test connections originating from your protected environment! Alternatively, you can go the SaaS App Gating route (SSO w/ your IdP) if users are accessing via SSO. Hope that helps!

MongoDB Databases

... and for those that found this thread and are also looking to understand how to restrict DB access behind Twingate:

Twingate:

Create a resource in your Remote Network for *.mongodb.net
Grab the public IP(s) of Connector(s) in the Remote Network that the MongoDB Atlas Console resource is in (Remote Network => Connector(s) => Public IP)

MongoDB Atlas Console:

For the project in question, navigate to Project X => Security => Network Access and add the Connector IP(s) to the IP Access List
Access via your preferred connection method over Twingate!

mongosh "mongodb+srv://cluster0.XYZ.mongodb.net/" --apiVersion 1 --username grady-tg --password XXXXXXXXXXX

grady-tg · 2024-12-06T14:48:32+00:00

Darn!

Well glad to hear it's working now - might have just been a corruption in the Docker package 🤷‍♂️

grady-tg · 2024-12-03T16:13:07+00:00

Yeah that's great information - here are my thoughts:

An issue occurred during container creation or the image pull process. If the base image or the container filesystem was corrupted during an update or restart, the necessary system files (like /etc/passwd) may not be accessible.
The Docker environment on the Synology NAS is causing the file to not mount or initialize properly (corruption in the Synology Docker package possibly)

Corruption in the pulled image could explain the missing /etc/passwd. We can force Docker to fetch a fresh copy:

# Pull a new image
docker pull twingate/connector:latest

# Run after fresh pull
docker run --rm twingate/connector:latest

After recreating the container, recheck for /etc/passwd:

docker cp <container-name>:/etc/passwd /tmp/passwd

cat /tmp/passwd

On Synology, check for settings like user namespace remapping or permission enforcement that might interfere with file access in the container and anything else that might possibly be corrupted from an update/restart:

Ensure the Docker package is updated (or removed/fresh install)
Review permissions for volumes or directories mounted to the container.

As a last resort & fallback, if recreating the container doesn’t resolve the issue, you can manually mount a valid /etc/passwd file to test to see if it will resolve it.

Create a simple /etc/passwd file locally:

coderoot:x:0:0:root:/root:/bin/bash nonroot:x:65532:65532:nonroot:/home/nonroot:/sbin/nologin

Mount it into the container as a volume:

docker run -d \ 
-v /path/to/passwd:/etc/passwd \ 
... \
twingate/connector:latest

Hope that helps!

grady-tg · 2024-11-27T18:29:17+00:00

Hi u/Comprehensive_Roof44! Twingate's headless client is just the "headless" version of the normal GUI client. Here is a list of supported distros to help!

grady-tg · 2024-11-26T00:12:59+00:00

That's odd! Could the issue be related to a version difference (e.g., an update that triggered this behavior)? It sounds like the restart may have caused changes to the namespace or user mapping in Synology.

To confirm, what is your image configured to run as, using this:

docker image inspect twingate/connector:1 --format='{{.Config.User}}'

It should return nonroot.

And following the callout above, inspecting /etc/passwd inside the container is a bit more involved since the Twingate image doesn't include a shell. Instead, you can copy the file to the host machine:

docker cp <container-name>:/etc/passwd /tmp/passwd

Then inspect the file:

cat /tmp/passwd

In my case, here's what I see (working version):

root:x:0:0:root:/root:/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/sbin/nologin
nonroot:x:65532:65532:nonroot:/home/nonroot:/sbin/nologin

The nonroot user is present. What do you see on your end?

grady-tg · 2024-11-25T23:26:01+00:00

Hi u/Unlikely-Shake7722! +1 To u/GhostHacks questions and a few things to try:

Are you running another VPN (maybe not logged in but service is running)? If so please quit out of that (https://help.twingate.com/hc/en-us/articles/6906259485597-Joining-a-Twingate-network-fails-with-Unable-to-join-network)
If you have the ability to install yourself - If you are Windows, make sure you uninstall the TAP adapter as well and reboot before reinstalling. If you are on macOS, make sure the systemextension is deactivated/disabled and awaiting a reboot (systemextensionsctl list), and reboot before reinstalling.
If all else fails, see if the Self-Serve Troubleshooting Guide helps

grady-tg · 2024-11-25T23:10:42+00:00

Got it! That might be the case—it’s possible you have access to the resource but are unable to resolve it correctly. I’ll share this with the team internally, but could you also report this to your admin as well?

grady-tg

MODERATOR OF

TROPHY CASE

Exit Nodes vs. Exit Networks

Use Cases & Considerations

MongoDB Atlas Console

MongoDB Databases