I’ve successfully created connectors in Azure and their IPs are on the Azure subnet.
I’m now trying to create a connector on a Windows machine, but it forces a DHCP connection on the 172.0.0.0/16 subnet, which is not the subnet for the local resources.
I found instructions for adding an additional adapter to the multipass instance, and I am able to ping the local resources from the connector Shell, but Twingate isn’t listing the additional interface for the corresponding connector, so (presumably) it doesn’t know to use that connector for the resources with IPs on the local LAN.
How do I get the Windows connector onto the correct subnet?
Just to clarify, is the WINDOWS machine being forced to the 172.0.0.0/16 subnet or just the connector?
If it’s the connector, it will default to the 172.0.0.0/16 subnet as part of the normal setup process with Multipass and VMs, but the connection should be automatically bridged so that the VM/connector can reach any resource accessible from the host machine.
As an example, I just went through the process on my local Windows machine which is on the 192.168.x.x subnet, and when the connector VM was created, it had an IP of
172.24.178.220, but was able to connect to any resource I had defined on the 192.168.x.x subnet (including the host machine running the connector, via it’s 192.168.x.x IP)
If you’re not seeing similar behaviour, my first suggestion would be to tear down and re-install the connector.
I uninstalled a re-installed the twingate-connector, didn’t do anything ‘extra’ after installing.
Opening the multipass Shell for the connector, I AM able to ping local resources (192.168.1.0/24).
The connector (“myconn”) is running on a Win 11 host at 192.168.1.100. I created a resource in twingate console for this same address - “my.resource”.
When I go to another device (192.168.1.10), nslookup my.resource returns a twingate (100.96.x.x) address, so obviously the the client is recognizing the resource.
Pinging my.resource from 192.168.1.10 gets no response. Looking at the twingate console, under the “my.resource”, it shows that 192.168.1.10 failed to connect. Under details, it shows it is trying to use “another.random” connector instead of the appropriate “myconn”. my.resource is not accessible from “another.random” connector. (“another.random” is an Azure connector in my 10.0.0.0/8 Azure vNet)
How do I get twingate to use the correct connector, “myconn”, to access the resource?
[Side note: the Twingate console reports another.random connector’s IP to be in the 10.0.0.0/8 subnet, and I have no problem using that connector to access resources in that subnet. The Twingate console reports ‘myconn’ to be in the 172.0.0.0/8 subnet, which makes me think that’s why Twingate isn’t trying to use ‘myconn’ to get to 192.168.1.0/24 resources.]
Taking a look at the configuration you’ve got set up, right now you only have one single remote network defined and all four active connectors are in that single remote network.
This means that when you access (ping or otherwise) a resource attached to that network, it could go through any one of those 4 connectors, and that can change from request to request depending on load, etc.
So there is a chance an attempt to access a resource connected to your Azure connector could be routed through your personal Chocolatey connector, and that would also fail.
Ideally you’d want to have multiple remote networks.
ie: one for Azure with all your azure specific resources in there.
and then one for home/office/whatever.
Then you’d have one or two connectors in each network, and when you access a home resource it will only route through the home connectors, and vice versa.