Command line: Connect/disconnect

VPN
1

I recognize connecting requires auth etc, but I would still like the ability to up/down twingate from the command line on a non-headless machine easily. C.f I have the following function in my ~/etc/powershell.rc

```
Function Set-VPN {
Param ([String] $VPN, [Switch] $Online)
if ($VPN -eq “openvpn”) { set-openvpn -online:$online }
…
}
```

and I was hoping it would be as easy as

```
Function Set-TwingateVPN {
Param ([Switch] $Online, [String] $VpnExe = “C:/Program Files/Twingate/Twingate.exe”)
$state = if ($Online) { “connect” } else { “disconnect” }
Start-Process -FilePath $VpnExe -Argumentlist ($state)
}
```

2

Hi there,

perhaps this will help you a bit, I have a couple of Powershell functions that you can play with.

The following function will return OK or NOT_OK depending on whether the OS is able to resolve a FQDN that is only available behind Twingate (the logic being that if you can resolve a private FQDN, the Client must be up and running):

$PrivDNSResource = "privatehost.int"

function Check-TG-Client-status {

    param (
        $DNSPrivateResource
    )

    try{
        $dnsRecord = Resolve-DNSName -Name $DNSPrivateResource -ErrorAction Stop
        $Status = 'OK'
    }
    catch {
        $Status = 'NOT_OK'
    }
   return $Status

}

The following function can be used to kill the Twingate Client (by killing the underlying process):

function Kill-TG-Client {
    Get-Process | Where-Object { $_.Name -eq "Twingate" } | Select-Object -First 1 | Stop-Process
}

The following function can be used to start the Client (but not authenticate since that needs to be done manually):

EDIT: the current path on Windows is probably “C:\Program Files\Twingate” nowadays (as you pointed out in your own example actually, so you might need to change it in the snippet below for the code to work)

$TGClientPath = "C:\Program Files (x86)\Twingate" # path to the Twingate Client on Windows

function Start-TG-Client {

    param (
        $TGClientPath
    )
    cd $TGClientPath
    .\Twingate.exe
}
3

This doesn’t appear to cause it to connect, unfortunately, and our FQDNs are still in transit from being internal addresses with public visibility, although what I can do is try resolving one of them and testing if the address begins with `100.

```pwsh
$OnlinePrefix = “100\.”
$IsConnected = (Resolve-DNSName $DNSPrivateResource | Where-Object { $_.QueryType -eq ‘A’ } | Select-Object -ExpandProperty IPAddress) -match “^${OnlinePrefix}”)
```

Specifically I want to be able to control the connect/disconnect as you can with vpn solutions.

4

are you trying to automate the auth process as well? Is your goal to have workstations automatically connect to Twingate at boot and authenticate without requiring ANY user intervention?

EDIT: if so, you should probably look at implementing Service Accounts and the headless client as opposed to the “regular” Client since the regular client will always ask for user auth.

5

Auth: No, we’re using an sso auth (jumpcloud), so while I’m actively working with browser sessions open, the auth is already dealt with.

Does the headless version provide something that will allow a different or non-service account (e.g part of a ci or build script or a part of a test run) to up/down the twingate connection?

6

sorry, not sure I understand, what do you mean by “a different or non-service account”? just to make sure we are on the same page, I was talking about those service accounts: https://www.twingate.com/docs/service-accounts-guide, they are primarily used in the context of CICD pipelines and for “system to system” secure connections (vs user to system).

7

If I want to be able to use the same script on my workstation - e.g from vscode/studio, that won’t work.

Maybe I’m using 'nix terminology in a windows context or something, but it seems like there ought to be some other way to tell twingate I want it to perform the logout & disconnect and login actions, such as from powershell. If that’s on my workstation, then the auth may pop up vs if it’s on a service account on a ci machine it happens automatically - those are both perfectly fine, in contrast to having to execute additional steps every time I want to run one of these state changes.

8

I don’t think I understand the use case you are trying to achieve but basically:

Client install in “regular mode”:

  • you can kill it using powershell by killing the client process
  • you can open the client using powershell as well
  • you cannot trigger the authentication prompt using powershell

Client install in headless mode:

  • you can both start and stop the client using commands
  • since headless mode clients are tied to service accounts and not identities, there is no auth prompt at all
9

This answers my question, Twingate lacks the ability to trigger an auth from the command line (and thus scripting) without using a service account. I think that’s a windows-vs-nix mindset; same logic that means there’s no “sudo” command on Windows yet, but a case where the nix mindset might be better.

All the other auth-requiring tools we currently integrate into our pipeline/workflows provide the ability for us to trigger a login auth event, which typically requires manual user interaction, but less than “please do another thing and then come back here and click ok”. Even perforce allows “p4 login” which will trigger the manual auth procedure if its required, opening a browser or prompting for a bio action/yubi touch etc.

10

got it!

I don’t think it would be hugely difficult for our team to add it to the Windows Client and I’d like to open a Feature Request for it. Can you DM me your tenant name / URL to your admin console? I’ll tag the FR to your account.