I spend much time on this problem and it is not simple question of configuration to be discussed on users forum. I've tried all sort combinations of MTU sizes from extremally small to very big all settings regarding MSS, RWIN, mssfix and so on... I'm not accuseing anyone because of incompetency but many people disvovering this kind of problems was left without a help or told only to use UDP protocol. When i switch to UDP everything works fine byt it is not a solution. I understand problems with tunneling TCP traffic through TCP tunnel but it doesn't answer why it multiplies my ping 50 times. And why packets of exact size of MTU are transmitted flawless? Maybe there is a way to wrap all incomplete packet to match MTU size an push it faster? Of course you can always say that UDP is better but so weak performance of TCP is very hard to bare.
My config client and server is same i'm not using comp-lzo to exclude all external factors. We are using Windows XP / Vista. client dev tun proto tcp-client remote ... ca cert key verb 5 route-method exe route-delay 2 tun-mtu 1500 simple as it is.. and really it is not a problem of MTU or mss. Best regards Ucho > Could this be related to this? > > <http://sites.inka.de/~bigred/devel/tcp-tcp.html> > > And in the moment you exceed the MTU size (1500) in your ping requests, > you will produce more TCP packets. You might even hit some issues with > the Nagle algorithm as well? (have you tried with --socket-flags > TCP_NODELAY ?) ... As you have a strict firewall policy, could it be > that this causes some issues? > > Or it might be that you need some tuning on the --link-mtu, --tun-mtu or > - --tun-mtu-extra? Have you tried running an OpenVPN client with > --mtu-test? > > Providing more information about your configuration and what you have > tried so far would also be helpful, and not just a rather nasty > accusation. In many cases, what you complain about here are often > connected to configuration issues. Even though, TCP will never ever be > as efficient as UDP. > > You also don't state if you are using TUN or TAP mode (again, > configuration file would help), where TUN is known for having better > performance and less overhead than TAP. > > So, to sum it up ... you don't provide much information for us to work > on ... and to be frankly, this discussion sounds to more belong to the > openvpn-us...@lists.sourceforge.net list and not the development list, > at this point. > > > kind regards, > > David Sommerseth
