Twingate Local Router

Similar to Routing Traffic From Kubernetes Cluster Using the Twingate Client I’d like to set up twingate headless client on one machine, and use that machine as a router such that other machines on my local network can access my twingate resources without each one needing their own client, for example a raspberry pi.

I used the kubernetes article to set up ipv4 forwarding and configure ip tables for my local router, but I don’t know how to set up networking/static routes on my target devices (e.g., raspberry pi).

Hoping a twingate or networking guru can help me with the last step!

Hi IronRobin,

Unfortunately support for this is a bit outside the scope of what we can offer here in the discussion forums, and ultimately the configuration of static routes on your specific devices is going to vary from device to device so there is no one size fits all solution that I can provide.

What I can suggest is a bit of generic info to the RPi side of things which I believe should get you started and moving in the right direction.

If you look at this link: Configuring a Static IP and Static Routes on a Raspberry Pi running Raspbian Jessie using the CLI – Hospitable IT the important part is the “persistent static route” section.

For the sake of example, lets use the following pieces:

  1. TGRT - Your Twingate router/jump box/whatever you want to call it. This is the device that would be running the headless client. Lets say the IP of this box is 192.168.1.100
  2. TGCN - Your Twingate connector - this exists on your protected network and has access to all your Twingate protected resources. Lets say the local IP of this box is 172.16.1.123
  3. TGRS - A Twingate protected resource that is accessible by TGCN. Lets say the local IP of this box is 172.16.1.202
  4. RPi - your local device that isn’t directly connected to the Twingate Resource or the Twingate Connector and does not have a Twingate client, headless or otherwise, installed. Lets say the local IP of this box is 192.168.1.66

With things defined as such, while Twingate is disconnected, #1 and #4 are on the same network, and can talk to each other, and #2 and #3 are on the same network and can also talk to each other, but #1/#4 are isolated from #2/#3.

When the Twingate client on #1 is connected, #1 can now talk to #3, as when a request is made for #3’s IP (172.16.1.202), even though it is not on the same local network, the Twingate client will intercept the request and route it over our network to the connector, which will then route it to the resource and back.

However nothing is different with #4. It can still only talk to #1 because it has no idea how to talk to #2 or #3.

Using the information in the link above, we’re going to create a new Static Route on the RPi (#4), which will configure the RPi’s networking interface to take any request for #3s IP and route it via #1, rather than out over its normal network interface path. (This is fundamentally what the Twingate Client is doing to traffic that leaves #1, we’re just doing it on #4 without a client.)

To accomplish this, do the following:

Edit (or create it if it doesn’t already exist) the following file /lib/dhcpcd/dhcpcd-hooks/40-route

and add a line like this at the bottom:

ip route add 172.16.1.202/32 via 192.168.1.100
Then, save the file.

Once you’ve done that, when you attempt to communicate with 172.16.1.202, the RPi will route it through 192.168.1.100 (our Twingate jump box), and provided the Twingate headless client is connected and operating normally, the traffic will be routed to the Twingate protected resource.

That should accomplish exactly what you’re looking for.

Obviously, you would need to repeat these steps on every “client” device like the RPi you have and the directions may be slightly (or totally) different.

Alternatively, you may be able to configure a route just like this specifically on your hardware router, so that anything on your network attempting to access the specified ips gets routed through #1.

I hope this helps point you in the right direction and find a way to get things working the way you are wanting.

-arthur

2 Likes

It works well, I can now access protected resources via IP address from a raspberry pi. Now, how could I do this with DNS? I still for example get

> $ curl -L https://stage.acme.com                                      
curl: (6) Could not resolve host: stage.acme.com

The easiest way would be to edit your /etc/hosts file on the RPi and add a line like:
[IP of Resource] stage.acme.com

Then the lookup wouldn’t go to an external DNS server it would just resolve to the IP immediately and proceed as normal.

It kind of works, but is a bit cumbersome, especially if you have wildcard entries. There is no way for local router to share it’s DNS server?

I’m not certain it would work and don’t have an appropriate sandbox to test on handy (I have an RPi somewhere… but I have no idea where) - but you could theoretically add another routing rule so that anything that would go to whatever the DHCP defined DNS Server on your network got routed through the Twingate “router/jump box” and then it might end up being handled by the client.

If you do try that out, please let me know how the experience goes!

Got the IP address of my network DNS Server address which is 192.168.50.1

tried:
ip route add 192.168.50.1/32 via <ip_of_jumpbox>

This still left me with “Could not resolve host” errors when curling protected resources.

I am really looking forward to an aarch64 linux release, and I hope it’s on your roadmap so I don’t have to do these workarounds. If you have an insiders release I’d happily sign up for that. (Even if it’s just a tarball!)

We’re actually working on that very thing now - I can’t promise a specific release date but I can certainly let you know as soon as it’s ready to go!

1 Like

I am also wanting to an aarch64 Linux client