Attempted User Privilege Gain

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.

Any ideas?

Thank you

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

Thanks

tailscaled sends STUN packets to its own DERP servers.

103.43.75.49 derp5-syd.tailscale.com Australia (Sydney)
68.183.90.120 derp6-blr.tailscale.com India (Bangalore)
18.230.97.74 Amazon Data Services Brazil (São Paulo)

That last one is derp11.

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

Kind Regards

Thank you for the feedback.

The performance impact is two packets per second.

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:

-note, it was turned on for short bursts during the testing period/days. Not turned on continuously

also, as you can see, the mathematics of 2 packets per second does not add up.

The chart shows roughly 2.5, say 3 days
That would mean = 3(days) * 24(hours) * 3600(sec/hour) * 2(per second)= 518400 events.

I’ve got over 707.000 in less than 3 days.

and Tailscale was only turned on in bursts.

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.

Thanks for the great thread

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

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.