How to change IP of Windows connector instance

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 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?

Hey Mike,

Just to clarify, is the WINDOWS machine being forced to the subnet or just the connector?

If it’s the connector, it will default to the 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, 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.

choco uninstall twingate-connector
choco install twingate-connector

And see if things work out of the box for round 2. If not let me know and we can investigate further.



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 (

The connector (“myconn”) is running on a Win 11 host at I created a resource in twingate console for this same address - “my.resource”.

When I go to another device (, nslookup my.resource returns a twingate (100.96.x.x) address, so obviously the the client is recognizing the resource.

Pinging my.resource from gets no response. Looking at the twingate console, under the “my.resource”, it shows that 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 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 subnet, and I have no problem using that connector to access resources in that subnet. The Twingate console reports ‘myconn’ to be in the subnet, which makes me think that’s why Twingate isn’t trying to use ‘myconn’ to get to resources.]

Hey Mike,

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.

Hope this is clear but if not please let me know.


That’s so simple when you explain it, I can’t believe I missed that in all the documentation I’ve read.

Won’t have a chance to try it until tomorrow, but that definitely sounds like the solution.

Thanks for your help!