Been beating this up for too long and need some ideas. This is the second Twingate I have setup and the first one worked flawlessly So I know it works. This latest instance acts like it can’t get to the DCs at the office to resolve anything. I can hit everything by IP to include those same DCs with DNS on them. The connectors are on the same LAN as the DCs. I even added the recommended resource entries for AD. Resources are there for the DCs both by ip and FQDN. Nothing tried will allow you to ping a device or trace it by name. It worked amazing at the first location and still does. I even brought them up side by side and made sure there were no obvious difference in the setups. Any ideas are greatly appriciated.
Hey Greg,
How do you have the connectors deployed? Are they docker containers or are they VM’s or something else.
I’m not sure which site in particular is having the issue, but I do see that it looks like you may be using [hostname].local as your domain, which can cause some issues, as per RFC 6762.
There’s potential workarounds that can be employed depending on the Connector Deployment method (we’re working on a knowledge base article as we speak) - so if you can let me know how the connectors are deployed in this network, or if I’m totally off base and it isn’t the [hostname].local network, and we can go from tehre!
Thanks,
-arthur
The westernflyer.local (wfx.twingate.com) one is the one without problems. It is iwx.twingate.com that has the issues. The internal domain is iwxmf.com . The 2 connectors are both RPs and connected on the same physical network as the DCs. The latest attempt I have disable all connectors but and * and one that has 0.0.00/0 to just force everything down the tunnel. Still no go.
I will say with just those 2 entries in there the connections to everything by IP went from 50-60ms down to 20-30ms.
Looking at the analytics, I don’t see any connections at all to *.iwxmf.com prior to you adding * as a resource – did you have both *.iwxmf.com and iwxmf.com in there prior to the change?
With the * resource, I do see connections to a bunch of AD related hostnames for iwxmf.com , but you say it’s still not working at all?
*.iwxmf.com was but iwxmf.com was not. That is correct. I can’t ping to any device name and get a response. Just times out. I can however ping every one of them by IP and they all respond.
Can you tell me what your Twingate tenant name is for this account? I don’t see it under your email address.
As well, I just want to make sure, in your example there you’re pinging iwx-do03 NOT iwx-dc03 - does iwx-do03 exist as a machine?
iwx.twingate.com it is under wfxaadmin@iwxmf.com. The 3 devices pictured are the same device. Showing both ways of pinging by name as well as by IP.
Looking at the analytics, I see the connector attempting to lookup iwx-do03 and iwx-do03.iwxmf.com and getting DNS failures.
I also don’t see any resources defined specifically for those names. I do however see iwx-dc03 and iwx-dc03.iwxmf.com (note the use of DC rather than DO which is what host you’re trying to ping in your screenshot).
If you try pinging iwx-dc03.iwxmf.com does it work?
DO was just a typo. Pinging iwx-dc03.iwxmf.com get request timeout. I can however ping it’s IP which is 10.10.15.240.
Greg Weides
VP of Information Technology
XCEED Management Group
Direct (405) 948-8797 Internal 10101
4050 West I‑40 Service Road, Building A
Oklahoma City, OK 73108
I do see all of the dns errors for anything internal yet it’s resolving external fine. Also interesting to see that all traffic seems to be going to connector SPR02 and none to SPR01. Both show active and both are on the same network.
Greg Weides
VP of Information Technology
XCEED Management Group
Direct (405) 948-8797 Internal 10101
4050 West I‑40 Service Road, Building A
Oklahoma City, OK 73108
So looking at the logs this morning, I now see some “successful” lookups of iwx-dc03.iwxmf.com but the connector is getting an ip of 10.10.15.236, NOT 240. Is that expected?
As well, can you access it at all (with something other than ping? ie a http server or SMB share or something hosted there?
Spent a bunch of time messing with it last night. We purchased this company a few months ago and whomever set the stuff up in the beginning gave them 10.10.0.0/16. The PIs were pulling IPs in the 10.10.12.x area of that scope. The servers were static with 10.10.15.x IPs…still in that scope. So they were still on the same network and could ping each other by IP. The only thing that wasn’t working was name resolution. Just for giggles I ssh into the PIs and static them in the 10.10.15.x area of the range where the servers are. Boom its started resolving them. Makes zero sense why that would make any difference with them being on the same subnetted network. It’s like the connectors can only talk to things that are within a /24 network range.