Traffic to Public resource using a SaaS FQDN not going trhough Twingate Connectors

I’ve set up a public resource using a SaaS FQDN, for example, abc.domain.com. However, when I try to access the site, my traffic doesn’t seem to be routed through the Twingate connector. As a result, the destination receives my original IP address instead of the connector’s IP address. I’ve tried configurations with abc. and *.domain.com, but none seem to work. Additionally, I don’t see any logs related to my attempts to access domain.com in the Twingate Client Logs.

I also tried turning on and off Secure DNS in the Twingate using Cloudflare. But didn’t work either.
I have personal nextdns configured in my windows and chrome browser.

Can anyone help me understand why my traffic isn’t being routed through Twingate?

*Edited message including Secure DNS setup info.

Hi Andre,

One way to make sure things are being intercepted as you expect is to do a nslookup abc.domain.com from your command line and see what IP you get back. If you see a 100.x.x.x CGNAT IP, that means Twingate is intercepting things, if you get back the “normal” public IP, either Twingate is not intercepting it or it is, but something else is overriding it.

As well, your browser DoH could be intercepting the system DoH, so you may need to try disabling that within Chrome and see if you experience any different behaviour.

If you have any 3rd party EDR/MDM/DNS Filtering software running on your machine, this can also cause problems.

Let me know if this helps or if you have any additional questions.

Thanks,

-arthur

Great, Arthur! Thanks, your advice was immensely helpful and it resolved the issue. However, we’ve encountered another challenge now :frowning:.

Regarding the traffic that wasn’t being intercepted by Twingate, we identified the culprits:

  • The browser’s DNS setup and Firewall (Portmaster) were overriding Twingate.
  • The Windows DNS setup and EDR weren’t interfering with Twingate.

After we turned off Portmaster and disabled the browser’s DNS setup, it started to work.

Now, the challenge lies in deploying this fix to our team. Given the varied scenarios and the fact that many of our team members might not have the technical knowledge to make these adjustments, we need a streamlined solution. Moreover, disabling these settings may leave the computer less protected if the Twingate client fails to run for some reason.

One idea we had was to somehow force traffic through Twingate. Even if it means instructing our team to access a different domain rather than the original one. I’ve seen solutions, like Cloudflare, where they present a page listing services. Users can then click on the service they want to access. This approach probably ensures the traffic routes through their VPN.

Another ideia was to setup browser DNS to something related to twingate and setup nextdns on twingate. Once all of our resources would be domain access by the browser or IP (which doesn’t have any problem) this would be an easy solution to implement (we can force DNS setup through Google Workspace) and the would make sure everything works and is protected. Is it possible?

Does anyone have any suggestions or ideas on this?

*Edited message to add second possible solution