Hi, tried setting up twingate using docker on multiple different devices and networks.
1 - Deployed in Windows 11 using docker and try to access it from macOS and iPhones with different networks and the same network.
2 - Deployed in Windows 11 using Chocolaty using multipass to try to access it from macOS and iPhones with different networks and the same network.
3 - Deployed in Ubuntu using Docker to try to access it from macOS and iPhones with different networks and the same network.
4 - Deployed in Macos using Docker try to access it from Windows 11 with a different network and the same network.
All of the above tests were done on-premise remote network using CIDR (my public IP address in my network) and DNS options, every time I try to access it there is no response, also the logs after I check won’t show anything as if the host refuses the connection.
I tried to disable every firewall I find and along with the anti-virus and nothing.
I tried to deploy the remote network using AWS and Google and nothing.
I tried to ssh, open in the browser, and ping in every try and nothing works the host is refusing.
I tried to reach my remote network in all the tests above while I am in the same network and nothing works.
All the above testing without using any port restrictions and groups set for everyone.
I follow all the tutorial videos to deploy my remote network and nothing.
This is an example of the result I get every time I try to reach my remote network.
Based on your screenshot, it looks like your Connector isn’t able to reach the IP address specified in your Resource. The Connector performs DNS resolution on the Connector’s side of things, and in this case, whatever machine is running the Connector is unable to reach the IP you’ve provided.
When you said the Resource has your public IP address, do you mean the one you get from your ISP? If so, you may instead want to try the private IP address, e.g. 10.0.0.10, that the machine you want to connect to is running on.
If not, and you are already using the IP address assigned by your router, validate that you can reach that IP address from the Connector. Try ping or traceroute to make sure you can reach your target Resource.
Your issue is that the connector cannot reach the resource. You will need to troubleshoot the connectivity issue. Unfortunately, using the docker container for the connector does not give you the ability to troubleshoot basic connectivity. (No bash,curl,nslookup, etc)
I would recommend deploying the connector as a systemd service within a linux VM and then verify that the connector can SSH to your resource.
@slomr, I would also make sure the right ports are open (ex: 22 for ssh) and that there are no firewall rules on your endpoints preventing certain IPs from connecting to them.
You need to make sure that whatever port you’re trying to connect to is open and listening on your Resource as well. For example, your screenshot shows you trying to connect via port 80, is your machine running a web server on that port? Similarly for RDP, is RDP running on that machine and ready for someone to connect?
I tried to deploy the connector as a systemd service within a linux VM and try to access it from macOS using a different network with SSH and the connection failed again.
I have opened all ports in my device and the RD is ready for anyone to connect, even now the ping command is timing out the connector won’t say anything even when I deployed it in systemd.
What are you trying to do here? What are you using twingate for specifically. It might help understand what your problem is…
You should have console access to the Linux VM where you deployed the twingate connector. You should not be SSH’ing INTO the connector VM. In fact, the connector does not require ANY inbound access. If you cannot access the linux VM via SSH then this is not a twingate issue here.
You are making sure that the connector has outbound access to the resource and that your resource allows inbound access from the connector.
For example :
I have a NAS on my home network 192.168.86.1
I have a connector running in a linux VM running on the NAS
The connector can reach ANY IP in the 192.168.86.1/24 network
I have a PC that is using 192.168.86.5
There is NO FW rules between the connector and the PC as they are on the same network… And my PC allows inbound connectivity from the local network.
I can use the twingate client on my Macbook to RDP to my PC when I am outside of my local network. The RDP connection is proxied through the connector to the PC. In your case… this appears to be what’s not working.
From the screenshot you posted from the admin console we could see that your connector was up and able to reach the twingate controllers. Your client also connected to your network and your attempt to reach your resource was picked up from the client and proxied through our relays to your connector. From there your connector was unable to reach your resource. Your resource and connector should be on the same network.
1 - The main ISP IP address is 192.168.54.1
2 - I have a PC running on Windows 11 running a connector by using docker.
3 - The pc is having an IP address which is 192.168.54.79.
4 - The pc runs the connector and everything is right allowing the inbound access.
5 - The docker won’t show any issues right now.
6 - I create a new resource that has 192.168.54.79 as an IP address and allows all ports available.
7 - I have MacBookAir running on another network outside my of local network.
8 - Runs the client twingate and connected to my URL everything is fine.
9 - Trying to ping 192.168.54.79 timeout.
10 - try to ssh to 192.168.54.79 timeout.
11 - try to RDP 192.168.54.79 timeout.
For example, if your Windows host running the Connector container has the IP address 192.168.1.15, adding this IP address as a Resource in Twingate will not allow you to connect because of limitations in Docker. Instead, you must use the special Docker DNS name host.docker.internal if you wish to connect to services on the same host. More details are on the Docker website.
I would recommend picking up a cheap raspberry pi(64bit) and running the connector there if your intentions are to connect to your PC.
I wouldn’t be surprised if the same limitation happens when deploying via chocolaty. It’s still a containerized version of the connector running on the resource itself. There is NATs,internal routing ,hairpinning and is quite complex. Default configurations and basic network gear might not even support this. Advanced Users only!
Adding more difficulty for your situation is that there is no troubleshooting tools with the containerized version of the connector which is the only way to get it to run on windows. Twingate does not have a standalone windows client at this time.
Right now your flow is like:
Client ---- Relay ---- PC ---- Connector --X-- PC
The suggestion of raspberry pi would allow a cheap solution for a seperate device to run the connector. You can install Ubuntu on the pi and then install the connector as a systemd service. As it’s a linux system you can verify network connectivity to your resources with the various linux tools. This also gets you past having the connector running on a different network inside your resource which is the main issue here. The connector would be on the same network as the PC and your flow would look like.
I’m responding here as I’m having similar problems, many thanks for your input so far! I am slightly confused by the limitation you describe here. A YouTube tutorial filmed by Emrul about a year ago shows this exact scenario: Establishing a remote desktop connection from outside the network to a windows machine on which a connector is deployed using chocolatey.
Unless this is changed or I am misunderstanding, this is an entirely expected usecase, and one of the reasons that the chocolatey deployment exists in the first place! In any case I’m still having problems, my resource activity dashboard shows that the connector receives a request, and then fails to connect.
Hi pjb - if you are seeing a failure to connect in the Twingate logs when trying to access the resource, it typically means that there is something preventing the connection from occurring between the connector and the destination, not that there’s anything specifically wrong with Twingate in this case.
Looking in the back end logs I see that the connector does get the request from your RDP client to connect to the host, and is able to resolve that unqualified host to 127.0.1.1 and then attempts to connect to it, but that connection does not succeed.
What happens if you add the LAN IP of your Windows PC as a resource, and attempt to connect to that, rather than hostname?
