I had this weird problem where my svn would upload a few MB and then stall and timeout. At first I of course suspected a problem with either svn on the server, the apache, or tortoisesvn. I tried CPU affinity settings, Apache settings – nothing I did helped, including updating to latest patchlevel etc. After some trial and error, I found out that restarting my OpenVPN – which transports my svn traffic to ensure it is encrypted – seemed to help for a few moments.
After the timeouts, there were actually moments where I couldn’t connect to my server at all. Restarting the OpenVPN connection alleviated that problem.
So checking the log, I found that the openvpn reconnected when it timed out, and I saw this message:
Apr 3 01:14:15 corinth ovpn-server: MULTI: new connection by client ‘ghostwheel’ will cause previous active sessions by this client to be dropped. Remember to use the –duplicate-cn option if you want multiple clients using the same certificate or username to concurrently connect.
Aha! What IP was I coming in from?
Apr 3 01:14:15 corinth ovpn-server: MULTI: Learn: 172.16.0.6 -> ghostwheel/220.127.116.11:10654
And that resolves to an DTAG hostname:
# host 18.104.22.168
22.214.171.124.in-addr.arpa domain name pointer tmo-098-92.customers.d1-online.com.
So the solution of the problem was after all quite simple: Another machine was basically kicking me out of my VPN. And yes, I remembered that my girlfriend borrowed my Samsung NC 10 – and she probably left it running when she went to work. I hadn’t remembered that I had just copied the VPN config including certificate when I set up my home PC, but of course it was easy to fix.