profile
viewpoint

Ask questionsForce routing over Tailscale (prefer Tailscale routes over LAN)

Is your feature request related to a problem? Please describe.

One of our use-cases is to set up a relay node in our AWS VPC and advertise the VPC CIDR through Tailscale, so that users can access internal services securely (kinda like a traditional "enterprise" VPN solution I guess).

Now, it just so happens that our VPC CIDR is 192.168.0.0/16, which is causing some issues since a lot of home internet providers default configuration is to use 192.168.0.0/24 or 192.168.1.0/24. This means that the 'local' route takes precedence, and the users are unable to access anything on the AWS side which happens to sit in the same range as their LAN.

The behaviour I have seen with other VPN solutions like Cisco Anyconnect is that once you connect to the VPN, everything goes through the tunnel and you lose direct access to things on your LAN. TBH I am not really sure how that is implemented, and obviously this would be a bad default behaviour for Tailscale, but it would be useful to have this as a configuration option.

This may also overlap slightly with the "route all traffic through tailscale" feature... Perhaps @danderson has some comments / thoughts around this? Perhaps when in this "route all the things" mode, we could also (optionally??) capture anything which would normally be on the local network as well?

Describe the solution you'd like

Option to prefer Tailscale tunnel over the LAN if an advertised route in Tailscale overlaps with the local network, perhaps as part of the default routing / capture all traffic feature.

Describe alternatives you've considered

  • Install tailscaled on things which people need to access which fall within 192.168.0.0/23 on AWS side, use tailscale internal addresses (bit of a pain seeing as we already have a relay node to this network, would cause traffic from those boxes to go out through tailscale to the relay node and back in to the same network again, and also many of these internal services are Kubernetes services exposed via a VPC internal load balancer so can't really install the daemon there easily)
  • Stop using 192.168.0.0/23 (or maybe 192.168.0.0/16 all together!) in AWS; could work, but is more a workaround/hack than really fixing the problem, since it is possible that someones home network would use something in one of the other RFC1918 ranges.

Additional context

🤷

tailscale/tailscale

Answer questions aaron-trout

Hmm my apologies, I shall triple check this and get back to you!

useful!
source:https://uonfu.com/
Github User Rank List