I have a Twingate user case that would be helpful for our company.
Is it possible to use Twingate to allow a network switch on a remote location to access a radius server on our server running a Twingate client
The remote location does not have a local DNS server.
Would it work to use the Radius Server CGNAT IP as its source IP and add a static route at the remote location to forward traffic via the Twingate connector on the remote network.
In short what is the mechanism for network resources (Network Switches) access other resources on another network (Radius Server) when the remote resource doesn’t have a Twingate client installed (cannot install on network switch)
If this is possible it would be a great way for us to secure access to network resources using our on-prem radius server.
I just want to make sure I understand the particular setup you mention in your example.
You have a REMOTE Switch (We’ll call this REM) on Network 1 (N1)
You have a Central Radius Server (We’ll call this RAD) on Network 2 (N2)
You Have a Twingate Connector (We’ll call this TC)
Is TC on N1 or N2 in the example?
The way I’m understanding it (assuming I’m correct) is that you have REM on N1, and you also have TC on N1, and you’d like to be able to have REM communicate through the TC on N1 with the RAD on N2?
If this is the case, we wouldn’t currently support this flow, as we don’t have a mechanism for the Resource (REM) to initiate a conversation with the Client (RAD) via the connector independent of the normal flow from Client to Resource first.
As well, the CGNAT IPs that are assigned to Twingate resources are not guaranteed to be Static and can vary from connection to connection/day to day, so routing would be inconsistent at best.
You could, potentially, deploy a connector on N2 with the RAD, and then set up a device with a headless client on N1 that you could use as a “gateway”, and route traffic from the remote switch into that gateway, which could reach out to the RAD on N1 over Twingate.
Clear as mud? Did I totally misunderstand your description?
Thanks for your reply, to provide some background we are an IT company and have been trialling TG for our primary method of accessing our remove sites as opposed to a VPN.
The area we would like to plug is adding radius authentication on the login to remote network devices, switches routers etc.
We could do this with a on-prem radius server but for us a centralised radius server at our workshop would work best.
We will have a TC installed at our workshop (N2) and our remote sites (N1). Currently we connect to resources (Switches (SSH) on (N1) via TG via our service laptops which works a treat.
Both TC on (N2) and (N1) are on RPis.
I understand the issue with CGNAT in our scenario (makes sense)
With our setup how would we utilise the “headless gateway” setup ?
While this isn’t something we’ve specifically documented - the short answer would be something akin to a mini PC with two NICs behaving sort of like a router.
This device would run a headless Twingate client and a proxy server, and then the switch would need to be pointed at the device as its gateway or proxy - which would then theoretically route all traffic out of the switch to the remote radius server.
This is largely theoretical as we’ve never come across this use case before, but there are a number of scenarios related to IoT type devices where something similar to this is in use successfully.
Is it possible to setup a RPi in headless mode to act as a gateway, and Radius server being accessible via the “Service Account” mechanism.
I did notice there is a documented example using Ubuntu as a gateway which looks like it might work for our user case; however having a RPi acting as a gateway would be better for our user case.
Specifically using the RPi as a gateway isn’t something we’ve previously tried but it… may be possible? Unfortunately the only RPi I have near me is about a decade old so it’s not exactly the best test case for this - but if you can get the client installed on the device you should be able to forward the traffic more or less the same as the Ubuntu instructions.
I’ll ask around and see if anyone has a newer Pi they can try this on in the meantime, but feel free to give it a whirl and let me know how it goes.
I’ve setup a RPi3 in headless mode using the instruction for the Linux install, created the service and successful setup the connection passing in the service key etc…
from the systemctl journal it looks like the client is online but I cannot verify via the Twingate Console" is there a way to verify if at least the headless client is operational.
I’ve created a resource on a remote subnet 10.0.254.0 that is reachable from a traditional windows twingate client, should this resource be reachable via the RPi console running headless mode?
What would be the mechanism for testing headless service install and access to resources?
Thanks in advance for the handholding!
Kind Regards
Warren,
###UPDATE###
I can see from the journal the service is online, and can ping the resource from the cli so all good!
