NEW Tailscale: A New & Better iPBX VPN Solution

[wardmundy]

For a low overhead, point-to-point VPN that requires no centralized server, install Tailscale. Then whitelist the Tailscale range of IP addresses on all of your servers with the following command: /root/add-ip tailscale 100.64.0.0/10

 

[ostridge]

added to Incredible wiki pages of interest

 

[pbxnerd]

For a low overhead, point-to-point VPN that requires no centralized server, install Tailscale. Then whitelist the Tailscale range of IP addresses on all of your servers with the following command: /root/add-ip tailscale 100.64.0.0/10

The link doesn’t work.

 

[wardmundy]

1. Tailnet IP Range (Internal VPN Traffic)​

The IP addresses assigned to all devices within your private Tailscale network (your Tailnet) come from a specific, reserved range.1

• Standard Tailscale IPv4 Range:
  $$\text{100.64.0.0/10}$$
  (This range goes from 2$100.64.0.0$ to 3$100.127.255.255$)4

This is a special-use Carrier-Grade NAT (CGNAT) address space reserved by RFC6598, which is not routed on the public internet.5
When to whitelist this range:
You should whitelist 100.64.0.0/10 on the local firewall of your servers or devices connected to Tailscale if you want them to accept incoming connections from other devices on your Tailnet.

• For example, if you want your Tailscale device to accept SSH on its Tailscale IP (e.g., $100.x.y.z$), you would add a firewall rule to allow incoming connections on port 22 (or your SSH port) from the source IP range 100.64.0.0/10.

2. Public IP Ranges (External Firewalls)​

If you are configuring an external network firewall (like a corporate gateway, cloud VPC security group, or an ISP firewall) to ensure Tailscale connectivity, you need to allow access to the Tailscale Control Plane and DERP Relays.
Tailscale strongly recommends whitelisting by domain name rather than IP address, as the IP addresses of their relay servers (DERP) can and do change over time.6

Recommended Whitelisting (Domain Names)​

If possible, use these domains in your firewall rules:

Component	Purpose	Domains to Whitelist
Control Plane	Authentication, key exchange, configuration.	*.tailscale.com, *.ts.net
DERP Relays	Traffic relay when direct peer-to-peer connection fails.	*.tailscale.com, *.ts.net

IP Whitelisting (If Required)​

If your external firewall absolutely requires whitelisting by static IP address, Tailscale's control plane IPs are more stable than the DERP relays.
Tailscale documents a few static IP ranges associated with their infrastructure.7 However, this list may change, and relying on it is inherently less reliable than using domain names.
As of the latest documentation, the static IP ranges registered to Tailscale (e.g., for the control plane and some backend services) include:

• IPv4: 192.200.0.0/24, 199.165.136.0/24
• IPv6: 2606:B740:49::/48, 2606:B740:1::/48

You must also allow traffic to and from the unpredictable IP addresses of the DERP relays.

---

Required Ports​

Regardless of the IP address, you must ensure the following ports are open for outbound traffic (from your devices) to the internet:

Protocol	Port	Destination	Purpose
UDP	41641	$\text{*}$	WireGuard Peer-to-Peer: Recommended port for direct connections.
TCP	443	$\text{*}$	Control Plane & DERP Relays: Used for configuration and relayed traffic (HTTPS).
UDP	3478	$\text{*}$	STUN: Used by DERP servers for NAT traversal.

In summary, for most scenarios:

• On your local device firewall: Whitelist 100.64.0.0/10 to allow traffic from other Tailscale devices.
• On your network/corporate firewall: Allow outbound connections on UDP 41641 and TCP 443 to all destinations, or to the domains *.tailscale.com and *.ts.net.

 

[Halea]

For a low overhead, point-to-point VPN that requires no centralized server, install Tailscale. Then whitelist the Tailscale range of IP addresses on all of your servers with the following command: /root/add-ip tailscale 100.64.0.0/10

Tailscale is indeed an interesting infrastructure when it comes to quick and easy private VPN setup. But it does rely on third party as it uses coordination servers, route finders, etc. And equally importantly if point to point doesn't work it defaults to through-centralized-server approach.
This is not to say that it's any worse than anything else out there in terms of safety/security and privacy, but it's not much better either. But it's easy for sure. And I guess the risks are the price to pay for the convenience.
I would use it as a discovery and exploration tool. I am not sure that I would ever use it in actual operations, especially if the application requires high level of privacy and security.
Now, one might argue that with end to end encryption on top of Tailscale the risks may be mitigated. That's true, but the metadata about the Tailscale traffic is substantial. That alone actually makes me wonder ...

 

[islandtech]

So far, I haven't had to setup any whitelist or port forwarding on my Tailnet devices.

My Tailnet has 18 machines:
2 machines is used as a subnet router and exit nodes
2 mobile routers used as subnet routers
14 machines as members of the Tailnet

Through the advertised subnets I can access most any device (web and ssh)
Through the exit node outbound traffic has the external address of that network.
Exit node enables me to service a hosted system from anywhere using the address that the system configured from.

For devices on a hosted system and on premise servers, I use my routers remote access vpn to those sites

My use and understanding of Tailscale, is whitelisting, opening ports etc is not needed.
Once Tailscale is installed configured as a subnet router or as an exit node or both, it just works.

 

[phonebuff]

Tailscale is indeed an interesting infrastructure when it comes to quick and easy private VPN setup. But it does rely on third party as it uses coordination servers, route finders, etc. And equally importantly if point to point doesn't work it defaults to through-centralized-server approach.
This is not to say that it's any worse than anything else out there in terms of safety/security and privacy, but it's not much better either. But it's easy for sure. And I guess the risks are the price to pay for the convenience.
I would use it as a discovery and exploration tool. I am not sure that I would ever use it in actual operations, especially if the application requires high level of privacy and security.
Now, one might argue that with end to end encryption on top of Tailscale the risks may be mitigated. That's true, but the metadata about the Tailscale traffic is substantial. That alone actually makes me wonder ...

Not sure if it's any better or worse than a Stun Server, and the VoIP industry has been using those for years.

But I have found it able to solve issues with significantly fewer headaches and support overhead than other solutions out there. Additionally, you can always build your own ACLs inside Tailscale, or use your own self-hosted, Headscale, or base WireGuard connections for Classified-level security.

 

[hecatae]

Tailscale is indeed an interesting infrastructure when it comes to quick and easy private VPN setup. But it does rely on third party as it uses coordination servers, route finders, etc. And equally importantly if point to point doesn't work it defaults to through-centralized-server approach.
This is not to say that it's any worse than anything else out there in terms of safety/security and privacy, but it's not much better either. But it's easy for sure. And I guess the risks are the price to pay for the convenience.
I would use it as a discovery and exploration tool. I am not sure that I would ever use it in actual operations, especially if the application requires high level of privacy and security.
Now, one might argue that with end to end encryption on top of Tailscale the risks may be mitigated. That's true, but the metadata about the Tailscale traffic is substantial. That alone actually makes me wonder ...

There's nothing to stop you running your own headscale control server:

Headscale

An open source, self-hosted implementation of the Tailscale control server.

headscale.net