Hello, all
I am a new user of Tailscale and have installed it on Linux, Android, Synology, PIhole etc. using the suggested installation procedure. Ie. nothing advanced.
It seems to work ok except that I get masses of “Attempted User Privilege Gain” (ET INFO Session Traversal Utilities for NAT (STUN Binding Response)) on any device connected to the Tailscale network. Talking about hundreds per minute.
My network is on a sub-net to my ISP router.
As this is a threat and slows the network, Tailscale is shut down for now.
STUN is a protocol for a host behind NAT to ask a STUN server what its public IP address and port number are. tailscaled sends STUN packets to the Tailscale DERP servers, it is part of the NAT traversal implementation. STUN probes are sent fairly often: every few seconds is possible.
Where is this “Attempted User Privilege Gain” being signalled? The ISP’s router? Somewhere else?
Thank you for your reply.
The messages show up on a Synology router that is located behind the ISP router, ie the second network. The events are reported as HIGH severity and the packages are DROPPED.
Are these from other Tailscale users (ie not on my account) or are they my non-tailscale users (such as IOT devices) that are being kept alive?
Here are a few of IP’s that try to contact my Tailscale devices:
103.43.75.49 derp5-syd.tailscale.com Australia
68.183.90.120 derp6-blr.tailscale.com India
18.230.97.74 Amazon Data Services Brazil
-the are totally random to me and it seems a waste to have this being trafficked
Again, “tailscale down” totally stops this traffic
STUN asks the remote system “what IP address and port do you see?” So tailscaled sends the frame from its local LAN, say with LAN IP address 192.168.1.1 and port 50000. After passing through NAT, the DERP server sees the public IP address 12.34.56.78 and port 12345. The DERP server sends back 12.34.56.78 and port 12345 to tailscaled.
tailscaled uses this to work out what kind of NAT environment it sees. It is working out NAT traversal, how to get packets through NAT to allow direct connectivity.
Thanks for a great answer.
Still, the use of STUN, seem very chatty to me. I normally have between 0 and 10 threat events hitting my router, maximum 1000 events per day and a majority of them are classified as low and most of them are self-inflicted.
With Tailscale up, I receive 200.000 events classed as HIGH severity (rightfully or not) per hour. And this is with only a few devices logged into Tailscale. Not sure I want that kind of traffic hitting me for no reason at all since the sender is not a part of my network. If I were to connect between France where I am, and say India, surely it must be a better way than be on a constant ping with the whole world and all devices on the network? I was under the impression that the central Tailscale would handle certificates etc including locations - the attraction of the setup.
Having said that, I’m merely a home user and not an engineer. But for me, to create ignore rules on my router and accept a big performance hit on my already slow connection may be too much to ask for.
I will continue testing, by junking 99.99% of the inbound traffic and see if it’s workable.
For now, this conversation can be closed.
Again, thank you for your explanation.
-I do hope that I am proven totally wrong of my fears
That the router labels STUN as a high severity security incident is not something Tailscale can control. STUN is not harmful and should not be considered a security problem.
Ok, thank you. Still, it does not sing right to me. For those Synology router users out there, here is a chart of what you see when turning on Tailscale for a very short moment.
Apparently normal behaviour:
and Tailscale was only turned on in bursts.
And compared to other ‘vpn’s’ this is beyond understanding to me.
I’m sure you are right. Let’s just inform other Synology users and traffic monitors out there to expect a few hundred thousand packets per day if you use Tailscale for only a short while per day. I don’t know what would mean on a 24/7 basis with many devices. Let’s find out
I just had a similar experience with a Synology Router and Tailscale installed on two Synology NAS units. Things were quiet for days, but then I got a couple thousand intrusion detection alerts following a short internet outage.
Now that I see this thread, I have modified the intrusion detection rules to ignore NAT Transversal requests targeting the static IPs associated with those two devices.
As long as I know it is normal, I have no problem turning the alerts off.
OldReefer
Great that you can ignore the offending traffic and that you only have two hit devices.
How much traffic does these two generate per hour or per day? Are you happy with the blast of “pings” hitting you all the time? Are you not concerned about the traffic and potential issues?
Kind Regards ordinaryauto
I am was able to modify the rule in the Synology Intrusion Detection package to ignore STUN requests for IPs involved. I have been running it a few days now with no alerts. I agree that it is “chatty” , but at least it is no longer noisy.
Similar experience here. First time trying out Tailscale on a few devices and I noticed some devices in the home losing their WiFi connections to the Synology router (RT2600ac). I saw about 14350 entries over 52 minutes (or 275 a minute, 6 a second). When I got all the devices disconnected from Tailscale, things cleared right up. I’d expect the volume of inbound packets to go down if they weren’t all being dropped. I’m not sure I’m ready to lower the severity (so not to drop) or ignore the STUN packets in Synology’s Threat Protection quite yet. Maybe I’ll try lowering the severity to a particular IP address and see what happens to the inbound frequency.
what app are you using to show this information? I have a Synology NAS that has Tailscale on it that runs Tailscale 24/7. I am happy to check my stats, but I don’t know how to access what you are seeing.
The Malicious Events information comes from the Threat Prevention package on my Synology RT2600ac router. I’ve seen similar STUN packet “storms” from online meeting platforms like MS Teams and Webex. As my previous experience with the STUN issue was attributable to my and my wife’s work laptops, and I’m not the one to worry about securing laptops owned by other people, I excluded those machines from Threat Prevention monitoring.
A follow up on my Tailscale testing. I softened Threat Prevention’s action for the STUN packets from Drop to Alert as I was curious how much traffic would persist if packets could get through. The behavior did not change noticeably, seeing multiple packets per second. But this amount of logging by the router, being very persistent, severely impacts the performance of the router. I test this by running an hour of simultaneous pings at 5 second intervals to my router and to a common DNS server, like Google’s 8.8.8.8. Most pings respond in the 10-20 millisecond range (almost 600 of the 720), but around 125 pings took more than a second to respond. What happens is that traffic through the router effectively stops, the pings “pile up”, and when traffic starts again the responses flood through. No packets were lost, but you can see traffic gaps ranging from around 40 to about 170 seconds in the data below. That’s not good. For reference, there were two stretches of Tailscale being on in the data below.
Takeaway: if you have a Synology Router and use Threat Prevention, you need to change the Action for the Attempted User Privilege Gain rule from Drop [the packet] to No Action. This can be done either on a per destination basis or globally. I’m still thinking about how Tailscale fits my needs, but I will test the No Action setting and see if there is any router performance impact.
In regards to quantity per second, I think it’ll send out a STUN request per IP if you’re on ipv6 and/or quad gigabit with separate IPs that can add up fast.
If you stop dropping the STUN packets, then Tailscale will send less, as it will establish a NAT binding and only need to refresh it, as opposed to probing regularly.
I did modify the response in Threat Prevention from Drop to Alert and the traffic rate did not drop. Just logging the activity was causing problems. Things have changed since February. Threat Prevention changed its response to the STUN request, categorizing it now as “Misc activity” rather than “Attempted User Privilege Gain” and changing the response to Alert or Do Nothing (below). I did some testing this morning and didn’t encounter any issues.
As Alert creates log entries, how did I not have issues? The other thing I changed recently was where the RT2600ac stores its System Database (where the logs are). In February, it was on an SD card (class 10) formatted FAT. About a week ago I moved it to a USB2 stick formatted ext4. That format is recommended by Synology and a USB2 stick is about 6X faster than a class 10 SD card. I believe faster log storage was the reason why my testing this morning showed no issues.
