AWS relay node not working?

Linux (2 x Ubuntu 20.04 + 1 Amazon Linux 2) nodes running 1.4.2
Windows10 node running 1.4.0.

Inspired by the “AWS EC2 with subnet routes” instructions I have a cloudformation template that deploys 2 ubuntu nodes in AWS with tailscale installed automatically using pre-authkeys. (See github.com/dazzag24/tailscale-aws). I have also deployed a third node in the private subnet with Amazon Linux 2 installed, which does not have tailscale installed.

I then reviewed and accepted the advertised routes in the admin page:
image

The setup initially allows incoming SSH connections to the NAT security group and using the following ssh config:

# The public IP of the NAT server
Host ts-nat-public
	HostName x.x.x.x

# The Tailscale IP of the NAT server once configured
Host ts-nat
	HostName y.y.y.y

# The private IP of the node in the private subnet
Host ts-node-private
    HostName 10.0.1.106
    ProxyJump ts-nat

# A 2nd node (Amazon Linux) in the private subnet that DOES NOT have tailscale installed
Host ts-test-node-private
    User ec2-user
    Hostname 10.0.1.100
    ProxyJump ts-nat

# The Tailscale IP of the node in the private subnet
Host ts-node
    HostName z.z.z.z

Host *
    User ubuntu
    IdentityFile ~/.ssh/tailscale.pem

I can successfully SSH to all nodes using either public or tailscale IP addresses.:

~ ssh ts-nat-public uname -a                                                                        
Linux ip-10-0-0-212 5.4.0-1035-aws #37-Ubuntu SMP Wed Jan 6 21:01:57 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
 ~ ssh ts-nat uname -a                                                                                    
Linux ip-10-0-0-212 5.4.0-1035-aws #37-Ubuntu SMP Wed Jan 6 21:01:57 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
 ~ ssh ts-node-private uname -a                                                                           
Linux ip-10-0-1-106 5.4.0-1035-aws #37-Ubuntu SMP Wed Jan 6 21:01:57 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
 ~ ssh ts-node uname -a                                                                                   
Linux ip-10-0-1-106 5.4.0-1035-aws #37-Ubuntu SMP Wed Jan 6 21:01:57 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
 ~ ssh ts-test-node-private uname -a                                                                      
Linux ip-10-0-1-100.eu-west-2.compute.internal 4.14.214-160.339.amzn2.x86_64 #1 SMP Sun Jan 10 05:53:05 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

However, after I remove the incoming SSH rule in the security group (see step 7 in the instructions AWS EC2 with subnet routes - Tailscale) I can no longer ssh into the node in the private subnet that does not have tailscale installed. SSH to the NAT node using the public IP address also fails, but this is expected.

 ~ ssh ts-nat-public uname -a                                                                             
ssh: connect to host 18.135.159.39 port 22: Connection timed out
 ~ ssh ts-nat uname -a                                                                          
Linux ip-10-0-0-212 5.4.0-1035-aws #37-Ubuntu SMP Wed Jan 6 21:01:57 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
 ~  ssh ts-node-private uname -a                                                                           
Linux ip-10-0-1-106 5.4.0-1035-aws #37-Ubuntu SMP Wed Jan 6 21:01:57 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
 ~ ssh ts-node uname -a                                                                                   
Linux ip-10-0-1-106 5.4.0-1035-aws #37-Ubuntu SMP Wed Jan 6 21:01:57 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
 ~  ssh ts-test-node-private uname -a                                                                     
channel 0: open failed: connect failed: Connection timed out
stdio forwarding failed
kex_exchange_identification: Connection closed by remote host

The routing table on the windows host that I performed these tests on is:

❯ route PRINT
<snip>

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.1.1    192.168.1.173     35
         10.0.0.0    255.255.255.0   100.101.YYY.XX   100.101.YYY.XX      5
         10.0.1.0    255.255.255.0   100.101.YYY.XX   100.101.YYY.XX      5
         <REDACTED>
    100.101.102.103  255.255.255.255   100.101.YYY.XX   100.101.YYY.XX      5
       <REDACTED>
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    331
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    331
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    331

So I can see that the routes are being advertised correctly to my windows client?

My aim is the achieve what is described here: /kb/1019/subnets so that any machine in the private subnet is accessible without having to install tailscale on every node that i want to access.

Does the tailscale node (10.0.1.106) in the private subnet also need to be passed the --accept-routes flag?
or is this only required on nodes outside of the AWS setup?

Many thanks

Darren

Hello,

Clients on Windows, macOS, iOS, and Android will automatically pick up your new subnet routes.

For Linux clients, only those using --accept-routes flag will discover the new routes since the default is to use only the Tailscale 100.x addresses. Enable this by running:

sudo tailscale up --accept-routes

For more details, please visit: https://tailscale.com/kb/1019/subnets

Thank you,

Thanks for the reply. I think were my confusion is coming from is that I am trying to combine 2 approaches:

  1. AWS EC2 with subnet routes AWS EC2 with subnet routes - Tailscale
    and
  2. Subnet routes and relay nodes Subnet routes and relay nodes - Tailscale

However the AWS article makes no mention of --accept-routes.

Can you please confirm if the linux node in the private subnet needs to use this flag?

I am having problems reaching any node in private subnet 10.0.1.0/24 unless it has tailscale installed from my windows laptop.

Thanks

Hello,

AWS relay node does not require to run ‘–accept-route,’ but other Linux clients on AWS who wanted to access the advertised networks need to accept those routes, so we need to run ‘tailscale up --accept-routes’ in those.

Let me know if you need any further information.

Thank you,