Home / server / Questions / 982166
Accepted
xperator
Asked: 2019-09-07 01:03:58 +0800 CST

tun0 errors when running a vpn server?

  • 772

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

  • OpenVPN
  • Shadowsocks
  • MTProto Proxy

My server config is:

  • Ubuntu 18.04 x64
  • 512Ram, 1vCPU
  • UFW firewall
  • Netdata monitoring
  • Nginx

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.

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 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.

ubuntu

1 Answers

  1. Best Answer

    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.

    Also if you happen to use UFW, you have to edit /etc/default/ufw and change DEFAULT_FORWARD_POLICYto accept.

    If you still keep getting udp errors you probably also need to tweak your networking settings.

    • 0