Skip to main content

tun0 errors when running a vpn server? [Resolved]

I'm running a simple, personal vpn server with these softwares:

  • OpenVPN
  • Shadowsocks
  • MTProto Proxy

My server config is:

  • Ubuntu 18.04 x64
  • 512Ram, 1vCPU
  • UFW firewall
  • Netdata monitoring
  • Nginx (only for Netdata web interface)

It's been only few days since I started running the server. Problem is Netdata keeps sending me these 3 type of errors every few hours.

  • "server needs attention, ipv4.udperrors (udp), 1m ipv4 udp receive buffer errors = 12 errors"
  • "server needs attention, net_drops.tun0 (tun0), outbound packets dropped = 34 packets"
  • "server needs attention, net_packets.tun0 (tun0), outbound packets dropped ratio = 0.33%"

I thought it's not that of a big deal so I ignored them.

But about 1 hour ago, my server went inaccessible. I couldn't ping, ssh, or even access it using web console. I had to force a reboot from my provider's web interface. I can't figure out what the problem was, or which log file to look for.

netdata's report on tun0 interface Here is a photo of netdata's report on tun0 interface right before server went unreachable.

I'm not sure if this is a firewall issue, a system bottleneck, or one of the 3 mentioned vpn softwares are not performing well.

I don't even have that many users, Maybe they're like 3-4 users (max) connected to those vpn softwares.

This is the sudo ufw status verbose output:

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), deny (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
ssh                        ALLOW IN    Anywhere
2045/tcp                   ALLOW IN    Anywhere
4000                       ALLOW IN    Anywhere
80/tcp                     ALLOW IN    Anywhere
ssh (v6)                   ALLOW IN    Anywhere (v6)
2045/tcp (v6)              ALLOW IN    Anywhere (v6)
4000 (v6)                  ALLOW IN    Anywhere (v6)
80/tcp (v6)                ALLOW IN    Anywhere (v6)

the port 2045 is for shadowsocks and 4000 is for openvpn. and port 80 is for nginx ofcourse, just to access netdata web app. I'm not sure but I think the openvpn package had set iptables rules on it's own during install, so I added an allow rule on ufw just to be safe.

I looked into almost every log file in /var/log but I couldn't find any error or problem before server went unreachable. I'm not sure if the server froze, or crashed. cause there is no log after a certain point. not until we did force a reboot.

Update: I applied this "network tuning" conf to sysctl but the problem still persist:

net.ipv4.tcp_rmem="4096 87380 4194304"
net.ipv4.tcp_wmem="4096 65536 4194304"

Question Credit: xperator
Question Reference
Asked September 10, 2019
Posted Under: Network
1 Answers

I found out the problem. It was openvpn related. I looked at /var/log/syslog and apparently openvpn had an issue doing TLS handshake with the client. And it kept logging these errors:

TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
TLS handshake failed

The reason was the reneg-sec parameter which had the default values of 3600. Here is a quote from openvpn's official docs:

–reneg-sec n

Renegotiate data channel key after n seconds (default=3600).When using dual-factor authentication, note that this default value may cause the end user to be challenged to reauthorize once per hour.

Also, keep in mind that this option can be used on both the client and server, and whichever uses the lower value will be the one to trigger the renegotiation. A common mistake is to set –reneg-sec to a higher value on either the client or server, while the other side of the connection is still using the default value of 3600 seconds, meaning that the renegotiation will still occur once per 3600 seconds. The solution is to increase –reneg-sec on both the client and server, or set it to 0 on one side of the connection (to disable), and to your chosen value on the other side.

This parameter makes sure the client has to renegotiate their key every hour.

So if you left the openvpn on (client side) for a long time, and if for whatever reason one of the handshakes fails It would cause an endless supply of failed negotiations. I guess that caused the dropped packets and stuff.

Not to mention the "tun0" interface was made by openvpn in the first place, which I didn't know.

Anyway the solution is to change the reneg-sec to either a higher value, or just set it to zero and disable it. I decided to just go with the disable option and put reneg-sec 0 in server.conf and client .opvn profiles.

credit: xperator
Answered September 10, 2019
Your Answer