Clients in any VirtualServer from any location were having disconnects while others hadn't. When those that lost their connection, whenever they tried reconnecting, the server was not available. But I knew the server was up, people were on it and I was able to connect to the server its SSH. It was very strange. I started browsing around on the forums and saw that there were alot of people describing the same issue I was having but did not find a solution.

The reason for the disconnect is actually not the teamspeak server but rather the client in combination with a thing that might be easily overlooked by sysops.

I was trying to install Teamspeak on a clean, fresh installed ubuntu. Did my basic configurating aswell as setting up my second IPaddress into the interfaces. And that is where the problem lies.

I remembered that ever since I had that second IP, I needed to start the script with an extra parameter infile="ts3.ini"

However I just made a small error: i started with ./startscript start ini="ts3.ini"
However there was no feedback that that was not a valid command or anything. I also know and recalled from experience that if you just set up multiple ips on 1 nic that if you do not use the ini file the server will start but in the logs it will show it had bind on and thus serving nothing. So I found it weird that eventhough my syntax was wrong the server was reachable.

However and this is the essence of the problem. If you do not have that ini file and managed to get the server started and have multiple ips, then this might be the reason.

In my particular case x.x.x.196 was the IP that I wanted the server to listen to. x.x.x.195 is an IP that is used for different resources and should not be in any way affiliated with the TS3 IP.

Now during those disconnects I started looking in the client logs and it seems there is an error there that will say HChandler expected package on UDP from x.x.x.196: instead received from x.x.x.195.
That message made me check all server settings again and found out I had used the wrong syntax. But that didn't explain why I wasn't able to reconnect again. I then started looking into my router and eventhough all firewalls are deactivated, my router spotted that as suspicious activity because of the errors it was creating periodicaly en consistently.

I'm posting this message because it might be wise to adapt the startup script so that a wrong syntax on the extra parameters could be spotted and the script aborted with an appropriate message. It's also interesting to wonder why teamspeak itself would use a different IP to send packets to users who connected through another ip.

I hope it might shed some insight for some admins having the same problems.