6

I know TCP encapsulated over TCP is a terrible idea in general, but I can deal with the occasional decreased performance and MTU issues, and the snowball effect TCP within TCP provides where error control kicks in on both layers.

The latest OpenVPN client on Windows 7 x64 has terrible latency issues, where pinging a host inside the tunnel results in a >500ms ping time, and abysmal performance overall. Throughput seems good, it really is just latency.

However, on the same computer, the OpenVPN client on Linux 64 bits (ubuntu 10.04, same OpenVPN versions, same OpenVPN Configuration, no different settings) runs flawlessly. ~30ms, everything is very usable.

On the same switch, the same OpenVPN client version, same config file, on Mac OS X 10.5 (PowerPC) also works flawlessly.

I cannot explain this at all. I have tried various things, such as decreasing the MTU value for the virtual adapter to 1400 (since the terrible-ever-since-commercial-switch documentation mentions this not being dynamically set on windows, and recommends such an action), I have tried disabling ECN, chimney and CTCP in the global TCP settings, turning lzo compression on and off, sacrificing a goat, nothing makes it better.

Any ideas? At first I thought the lack of PMTU support in OpenVPN on Windows was responsible for this, but I tried with Windows XP and it works flawlessly as well. I got reports from users that it also works flawlessly on Windows 7 32 bits. Also the doc seems to say that the MTU settings are worthless for TCP connections, and are intended for UDP.

tl;dr: OpenVPN over TCP is slow but only in windows 7 x64, everything else works fine. What gives?

Great many thanks, if someone could answer this I would be forever in debt for getting my sleep back.

5 Answers 5

1

Are you 100% sure that you are on the newest version (2.1.1)? we've actually had some linux clients experience this same problem, and what we found was that they had older versions of the client software installed.

Also noticed that if you had an old version installed, and just installed the latest version to upgrade the installer did NOT upgrade it to the latest, and still showed the old version numbers when doing "openvpn --version" from the command line after the update.

To really get the new version in we had to fully uninstall ovpn and then install the latest.

Good luck, if this doesn't help i hope you find the issue!

4
  • This was a clean install, and I always remove the previous client(s) if any. Version is: OpenVPN 2.1.1 i686-pc-mingw32 [SSL] [LZO2] [PKCS11] built on Dec 11 2009 Which, as far as I know, is the latest :(
    – mr_daemon
    Jul 2, 2010 at 22:38
  • My OpenVPN client on win7x64 is 2.1.3. You say you are on 2.1.1? Sep 18, 2010 at 18:23
  • At the time of the original question 2.1.3 was not released yet. I did upgrade, cleanly (remove, wipe TAP adapters, install new version) but the problem still persists. :(
    – mr_daemon
    Sep 19, 2010 at 20:20
  • Oh, I also tried 2.2-Beta3. No dice :(
    – mr_daemon
    Sep 19, 2010 at 20:20
1

Well, that windows install kicked the bucket, and I reinstalled it earlier this week. Now somehow, I no longer have that issue.

Go figure. I wish I still had a snapshot of the system so I could pinpoint the differences :(

Thanks for the help, everyone.

1

I had a similar issue (Win7, x64, gui1.0.3, openvpn2.1.4, lenovo t500 - intel 82567LM) - terrible latency (ping usually not below 500ms, rather >1000+ (sometimes close to 2s) and very fluctuating values (600,1800,550,1400 etc.). I have disabled IPv6 for LAN card and TAP adapter as well (only one device off didn't solve the issue) and everything seem to be ok for now.

0

Wild guess:

Your antivirus or too-smart firewall tries to examine traffic (tries to buffer without forwarding in hope to see a virus, then times out and sends what it has buffered).

1
  • The only layer 7 firewall on my network is the gateway, the Cisco PIX. But as I previously mentioned in the original question it works fine on other machines, and other Operating Systems on the same machine. I did try disabling nod32, but nothing changed. Still >500ms.
    – mr_daemon
    Sep 19, 2010 at 20:19
0

Another wild guess:

Win7's dual stack IP4/IP6 does prefer IP6 more often. Perhaps you're hitting an issue with that. Presumably you're running IP4, does it make any difference when you disable IP6?

2
  • Sadly, the endpoint doesn't speak ipv4 at all, although I did for good measure disable it on both the transport layer and the TAP adapter. No change :(
    – mr_daemon
    Sep 21, 2010 at 20:12
  • 1
    lets play "whats the difference": any possibility to run wireshark both on XP and Win7 to see whether the packets are treated differently? Think of strange fragmentation etc. pp.
    – knitti
    Sep 21, 2010 at 21:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .