where an i find the most narrow/strict set of inbound/outbound firewall rules to allow ts to run?
on windows there are many moving parts.
tailscale.exe
tailscaled.exe
tailscale-ipn.exe
ts network adapter has an ip address and ip subnet
the underlying host network adapter has an ip address and ip subset
localhost
just a few examples
— outbound udp:12345
— outbound to known ports such as udp:1900 and udp:5351
and maybe it is me but i find this language confusing.
"Let your internal devices initiate UDP from:3478 to *:*"
as i find that ts is making outbound to *:3478
i have read the link and also quoted from it but it is a really lacking in detail.
imho, very strange from a network security product targeted to corporations?
so i guess the answer to my question is tailscale is not going to state for each component
a comprehensive set of narrow firewall rules and/or all ports used inbound/outbound
We recommend *:3478 and *:443 because those are sent to DERP servers, and we add servers over time. As a very recent example, we dealt with a support ticket recently about broken connectivity because they had configured their firewall to know that Tailscale had three DERP servers in Frankfurt. When we added a fourth server, their firewall had a 25% chance of blocking the connection until a linkchange resulted in moving to one of the three older Frankfurt DERP servers.
Though we could exhaustively list every DERP IP address in that doc, people set up their firewall rules once and never look again. The mere fact of listing them encourages people to set up their firewall rules in a way which will cause them pain later.
We recommend * for direct connections because nodes roam to public Wi-Fi networks and LTE carriers and IP addresses we cannot predict in advance.
Tailscale creates p2p connections between itself and other nodes on your network, which might be behind NATs, etc. NATs do port number remapping, so fundamentally if you want Tailscale to work well, you have to let it have access to do things on your network and on the Internet, and there’s no way to be sure in advance where those will be.
If you’re worried about Tailscale doing something malicious, then firewall rules aren’t really going to protect you; it’s running as administrator, after all, which means it even has permissions to change firewall rules.
If you want to restrict what traffic can do after arriving over the encrypted Tailscale link, you can apply whatever firewall rules you want to the Tailscale network interface. You can also uncheck the “Allow incoming connections” preference in the Tailscale UI to block all incoming requests (outgoing still works). Or you can use Tailscale ACLs to define more fine-grained security rules.
i am not asking for any public ip address at all, did not make mention of that.
i agree with your point
really, just asking for a complete list of inbound/outbound ports per component.
something that should be trivial to produce.
well, i made my point and i guess you cannot produce that simple list of inbound/outbound ports per component.
as with veaam, and any other product i use, i must know the exact set of ports and from that set of ports, to create an exact set of documented firewall rules, for security and HIPAA audits.
for what it is worth, i have been testing ts for a possible deployment.
so far, ts is clearly no stable enough yet, i have hit too many quirks and too many point releases.
and worst of all, no way to self-update.
no way i could present ts to be superiors without all of those basic items.
As we mentioned, Tailscale is an unusual product that needs to send packets to/from different ports all around the Internet. Also as mentioned above, the only component that needs to do this is the tailscaled.exe service. The purpose of Tailscale is to do all this in one place, so the other services on your machine don’t need to be trusted at all (they can be locked down to only use the Tailscale interface, if possible). This is a net increase in security, but the tradeoff is you’d have to trust the Tailscale service.
The reason Tailscale updates frequently is that we move fast and launch new features frequently, not because of stability problems. I can understand why it would feel like it’s a moving target though.
Sorry to hear you will not be proceeding with Tailscale. Please let us know if we can help more in the future.
Hi @asdffdsa1122, I would also be interested in such a list as I really like explicit and strict firewall rules. But to be honest, I’m not following you here.
Your device A wants to speak to device B somewhere on the internet, possibly behind NAT. But it is up to device B to choose a port, how can device A know that port number beforehand (without speaking to B)? Possibly you are controlling both devices so you could bind it to some specific port. But then, router on side B can remap that port to something totally different without even telling it to device B. Now device A needs to control that router or somehow predict if and how it’s going to do mapping. What is trivial about that?
Hi, just an idea:
I’m in control of two remote sites, everything including routers and devices inside. Instead of using traditional VPNs I want to use Tailscale. I’m sure I will not need the relaying functionality. I “just” want a really neat way of joining and flattening my networks with centrally managed ACLs, p2p encryption is a cool bonus.
Now, if I know a port number of control plane servers and if Tailscale allowed me to bind to some specific port (per device) and I make sure my router is behaving, then problem solved? Does it even make sense?
ᐧ