I have a connector in my home network and I have setup a resource with name “home1” and IP address 192.168.1.99.
When I connect the Twingate App on my Android phone, I can get an IP address for “home1” which is different, i.e. 100.127.1.99. I can ping that address and I can connect to home1. No issue, this is expected.
Now, if I do the exact same on windows client, I only can get the original IP addresss for home1, which is 192.168.1.99. Ping won’t work from my PC, since I am on another network. There is actually a route added in the routing table to 100.127.1.99.
So, why is the windows client not giving me back the address 100.127.1.99, but instead gives me the original address of 192.168.1.99?
Do I understand something wrong?
Have I configured something the wrong way?
I can’t find your tenant to confirm how you have the resource configured, so I need to ask a couple clarifying questions.
Do you have this ONLY defined as the IP with just a Label of “home1”, or did you configure home1 as an alias for the IP as well?
Do you have an actual machine with the hostname “home1” on the network your connector is running on?
If you have only defined the IP as a resource, then from your windows machine you would still just connect to 192.168.1.99, but Twingate would intercept and route that traffic for you over our network via the CGNAT IP you see in the routing table.
There is also a good chance you would see a different CGNAT IP on your Android device versus your WIndows device, or even on the same devices depending on the last access of the resource, etc.
Though you are unable to ping from the Windows machine, are you able to connect to 192.168.1.99 via whatever services are running (RDP/FTP/SSH/Whatever) or does it fail to do so?
Hello Arthur,
I was trying to mask my information since I do not know how sensitive that is.
Is it safe to communicate the network name (xy.twingate.com) and real IP addresses here ein the forum (which is public…)?
Dan
I experimented a bit further. Well, I guess I would find the inner workings in a documentation if I would RTFM, right?
Starting the twingate client on windows will get my pc an additional IP 100.127.255.220 and a DNS server 100.95.0.251.
nslookup shows me that the above DNS server is asked.
entering “home1” in nslookup would not give back any answer. (perhaps I messed up)
What exactly is supposed to come back come back if it’d work?
192.168.1.99 or the address 100.95.0.251 for which I have encountered a route (route print -4)
I would presume 100.95.0.251, since there is no route to 192.168.1.x in the routing table.
Would also make no sense, since many local subnets are still on 192.168.1.0/24.
More information.
I deleted all resources and re-added a new resource “ds.local” with IP 192.168.1.66
This time I do see the routing entries, so I guess I did overlook them before. From IP routing point of view, all looks good.
Remains the issue of
nslookup does not resolve “ds.local” to 192.168.1.66, and
ping 192.168.1.66 would not work, connect to port 5000 with a browser does work, though (this is a synology diskstation)… I am confused…
(ping from the android deviced does work, btw.)
I did add the local DNS server in the remote network configuration.
The local DNS server does resolve “ds.local” correctly.
The “label” of a resource is just a label, it has no bearing on DNS or hostname at all. If you wanted to be able to access ds.local and have it route to the IP you’ve defined, you would need to also add an alias for ds.local as in the below screenshot:
Or, if the DNS server of your home network knows how to resolve ds.local you could simply add it as a hostname resource like follows:
