While setting up a new OpenVPN, I got this message:
Sep 23 21:05:25 ascalon openvpn[18770]: krynn/aaa.bbb.ccc.ddd:xxxxx IP packet with unknown IP version=3 seen
The cause was that I had set my OpenVPN server to “dev tun”, while setting my Windows client to “dev tap” in the configuration. Changing the client to also be “dev tun” fixed the issue.
Yeah this had me puzzled for a while. Basically, I configured the OpenVPN client correctly (I thought so anyway). When I attempted to connect to my server, both the in-App log window and the log of my server remained empty: From what I could tell, OpenVPN didn’t even try!
Well, it turns out that as of early December 2013, OpenVPN Connect does not work on 64bit architecture on an iPad or an iPhone. The developers expect an update in mid-2013 to fix this. So until then there is nothing that we can do about it. Too bad.
Update: Problem has been fixed in current versions of OpenVPN Connect.
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[1050]: 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[1050]: MULTI: Learn: 172.16.0.6 -> ghostwheel/80.187.98.92:10654
And that resolves to an DTAG hostname:
# host 80.187.98.92
92.98.187.80.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.