Re: [Openvpn-users] Connection resetting on very large file transfers

[James Yonan <jim@xxxxxxxxx>]

On Wed, 1 Sep 2004, Sean Patrick wrote:

>  --- 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? 

Not a good idea.  Replay protection is considered to be a fairly essential
part of modern cryptosystems.

> 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.

Keep in mind that calibrating replay-window won't help if you have 
problems with duplicated packets (WiFi networks often produce large 
numbers of duplicate packets).  Here the fix is simply to silence the 
warning, without affecting the actual security functionality.

> > > 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>

Yes, I know, there's gotta be a simpler way to explain mssfix and 
fragment.  How about this:

mssfix   -- fragments TCP (efficient)
fragment -- fragments everything else (less efficient)

Use them both for the best of both worlds.

> 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?

This is an interesting idea.  The problem is one of security.  You are
allowing the server to generate a complete config file and send it to the
client.  This goes far beyond the more restrictive semantics of
--push/--pull and creates a scenario where a compromised server would have
no problem "owning" a connecting client's machine.  Since OpenVPN config 
files can execute shell commands, there's an obvious danger in allowing 
them to be imported.

Of course the other side of the equation is that allowing the server to 
update the client side config file is a powerful usability feature, and 
one that might make sense in some environments.  I can still see other 
problems though:

(1) What if you push a bad config file update to the client, and now it 
can't reconnect?

(2) What if you push a config file update to the client which changes a 
connection parameter such as the cipher type.  Now you have to orchestrate 
the switchover so that the client will try to reconnect with another 
server which also uses the same cipher type.  Essentially it is a 
switchover/bootstrap problem akin to changing the configuration on-the-fly 
of a live, distributed system.

James

____________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users