We have TwinGate installed successfully and colleagues able to access remote resources. It’s fantastic to be able to easily lock connections to specific ports.
I’m still unclear however, about:
How to protect all ‘other’ traffic of a user when a user is remote, particularly when they are on insecure wifi connections i.e. should they continue to use a VPN client even if DoH is enabled - there seems to be a lot of contradictory information on the web about this.
When turning on a VPN client whilst connected to TwinGate e.g. NordLayer, we then lose access to organisational resources via TwinGate
The VPN connection seems to push all traffic down its tunnel and TwinGate rules are ignored… How can this be avoided?
Do I always get given the same IP when connecting to Twingate? e.g. 172.16.x.y
Is one solution to add a static route on each local device to always push a request for an organisational resource through the Twingate gateway with something like:
sudo route -n add -net resource1.com 172.16.x.y
I have (for the time being - until it runs into a problem) solved this for our scenario.
Trick to get this to work:
- Do not allow VPN software to auto-connect on start up
- Establish the TwinGate connection first
- Grab the temporary IPs assigned to organisational resources
- Rewrite the /etc/hosts/ file to ensure that requests for organisational resources go to the newly established IPs
- Make a connection to one of the resources (even just a https request is enough)
- Start the VPN software (we’re using Nord)
This seems to result in the Twingate tunnels remaining sticky rather than being swallowed up by the VPN client, whilst everything else gets pushed through the VPN.
I’m currently running the below script on start up via a short cut on MacOS.
# Wait until Twingate is authenticated
until [[ $(dig +short 220.127.116.11) = "18.104.22.168" ]] ; do
# Once Twingate is authenticated, get the Twingate IPs that
# have been assigned to each organisational resource
# Add/remove variables below as required
res1=$(dig +short res1.internaldomain.org)
res2=$(dig +short res2.internaldomain.org)
res3=$(dig +short res3.internaldomain.org)
# Replace the /etc/hosts file with the new routes to organisational resources
# Host Database
# localhost is used to configure the loopback interface
# when the system is booting. Do not change this entry.
#Twingate organisational resources
$res3 res3.internaldomain.org" > /etc/hosts
Here’s how the shortcuts are set up:
Hope this is useful.