|
|
--- James Yonan <jim@xxxxxxxxx> wrote: > > > On Wed, 1 Sep 2004, Sean Patrick wrote: > > > Hi list, > > > > Thanks to your help, I have been able to get > OpenVPN > > 1.4.0b10 setup between our servers and remote > client > > That version number doesn't look right. My mistake. It's actually 2.0b10. So many programs, so many versions! > > > sites. Getting the mssfix 1437 value fixed a lot > of > > problems between the client sites it seems. > > > > There is now an issue where rsync is running a > backup > > across OpenVPN between a windows machine (on > cygwin), > > and the Linux backup server. > > > > Large files of about 2GB appear to be hanging the > > connection. Rsync looks to time out, and OpenVPN > > appears to be resetting at about the same time. > I'm > > not sure where the problem may be, but any help > would > > be appreciated. > > > > There are also messages from OpenVPN about > anti-replay > > which sometimes occur around the same time as the > > reconnects. > > > > A few questions for the list: > > Is there a "safe" setting for anti-replay, and can > it > > be pushed to clients? > > Yes, take a look at --mute-replay-warnings in the > man page. How much is security reduced by setting "no-replay" to shut off replay protection completely? I will try using the suggested verb 4 setting and see if I can catch any "Replay-window backtrack occurred [x]" warnings and calibrate the "replay-window n [t]" setting. > > > Will using fragment in the config files with > mssfix > > provide a noticable stability increase, or just > reduce > > performance? > > --fragment will only really help when you are > tunneling a UDP application > protocol, where the UDP datagrams become too large > for the transport MTU > after the encryption/authentication related overhead > is added to the > packet. <glazed eyes> So most traffic won't need the fragment setting, unless it is UDP with large datagrams. Ping I'm guessing sends very small datagrams, and rsync 873/tcp should be unaffected by this settings. It seems to make sense to leave this setting out until other options are exhaused. > > --mssfix reduces the TCP MSS size. This only works > for TCP connections > running over the tunnel. Okay, rsync running on tcp port 873 fits here. I have already managed to change the mssfix value and get the connections working initially. This is good. Now for the big files to transfer... > > Using --fragment and --mssfix together is usually a > good idea. > Performance will only be reduced if --mssfix is not > able to do its job and > the packet needs to be internally fragmented. Okay. Now the issue will be getting the client side configurations all changed to include the "fragment x" option. How are people managing client side configurations? The push option is really excellent, and I understand some options have to be present before the link is established. Updating large numbers of client nodes is often time consuming, and often impossible to update quickly when we don't own the client machines :/ Would it be possible to push an entire config, and have the client just reconnect to use the settings? > > > Should the mssfix/fragment values be set lower > than > > the mtu-test returned value to be safe? > > Yes, this won't hurt anything. With the performance comment above, and having seen many notes about maximizing mss values to get the best performance, is there any testing people have done to see the effects of changing to lower mssfix/fragment values? Is there a recommended way to test? eg. just time ftp or rsync transfers, and compare? With just a few clients a few kb of lost speed is not an issue, but expanding beyond that could see large overall reductions in performance. We want to try keeping the speeds up as much as possible to keep the clients smiling. Brian ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca |