Hullo there, A colleague of mine is having problems using rsync to the server I run that he accesses over an openvpn connection, since he made some changes at his end. I've asked him to type out the problem so I can ask on this list. He says:
<startnick> While trying to rsync using openvpn and the Vonage supplied Linksys RT31P2 router, the file transfer stalls.
This is true whether rsyncing via ssh, rsync server or nfs mounted volume. Using rsync without openvpn or without that router and all is well.
No other app seems to have the same problem though I haven't tried many but ssh seems fine for example.
Openvpn (v 1.6 I think) only uses udp packets AFAIK so shouldn't need GRE or any other sneaky protocol passthrough.
The rsync stall seems to happen after the initial preamble of authorisation and making file lists. Some directories are created but no files are sent.
Any clues most welcome.
My problem is that I want the Vonage router to be close to the main feed so that its QoS can optimise its VoIP channel.
Nick <endnick>
Thanks, Jenny
On Tue, Sep 05, 2006 at 04:01:43PM +0100, Jenny Hopkins wrote:
A colleague of mine is having problems using rsync to the server I run that he accesses over an openvpn connection, since he made some changes at his end. I've asked him to type out the problem so I can ask on this list. He says:
<startnick> While trying to rsync using openvpn and the Vonage supplied Linksys RT31P2 router, the file transfer stalls.
This is true whether rsyncing via ssh, rsync server or nfs mounted volume. Using rsync without openvpn or without that router and all is well.
No other app seems to have the same problem though I haven't tried many but ssh seems fine for example.
Openvpn (v 1.6 I think) only uses udp packets AFAIK so shouldn't need GRE or any other sneaky protocol passthrough.
The rsync stall seems to happen after the initial preamble of authorisation and making file lists. Some directories are created but no files are sent.
I'd be checking MTUs everywhere, especially if he's on ADSL. Can he do other large transfers over the OpenVPN link to the same server?
J.
On 05/09/06, Jonathan McDowell noodles@earth.li wrote:
I'd be checking MTUs everywhere, especially if he's on ADSL. Can he do other large transfers over the OpenVPN link to the same server?
He says (this is going to be awkward!) on our irc channel:
nickb I assumed that MTUs would affect throughput a lot but not the fact of it arriving. nickb Is this because of udp? nickb tcp will break up and reassemble packets
Thanks, Jen (mediator extraordinaire)
On Tue, Sep 05, 2006 at 04:35:37PM +0100, Jenny Hopkins wrote:
On 05/09/06, Jonathan McDowell noodles@earth.li wrote:
I'd be checking MTUs everywhere, especially if he's on ADSL. Can he do other large transfers over the OpenVPN link to the same server?
He says (this is going to be awkward!) on our irc channel:
nickb I assumed that MTUs would affect throughput a lot but not the fact of it arriving. nickb Is this because of udp? nickb tcp will break up and reassemble packets
UDP doesn't garantee packets arriving, or the order of the packets, so if one of them repeatedly disappears from the stream (MTU wrong), then it's possible that rsync will never recover from it.
(just a thought)
On Tue, Sep 05, 2006 at 04:35:37PM +0100, Jenny Hopkins wrote:
On 05/09/06, Jonathan McDowell noodles@earth.li wrote:
I'd be checking MTUs everywhere, especially if he's on ADSL. Can he do other large transfers over the OpenVPN link to the same server?
He says (this is going to be awkward!) on our irc channel:
nickb I assumed that MTUs would affect throughput a lot but not the fact of it arriving. nickb Is this because of udp? nickb tcp will break up and reassemble packets
Yes, I'm well aware of that.
But.
You're layering OpenVPN on top of a UDP based network and there can be issues with the lower layer telling the OpenVPN wrapped layer that there is a need to fragment.
You didn't answer if you can do other large transfers to the same server. What about without OpenVPN involved (using eg ssh as the transport instead)?
J.
On 05/09/06, Jonathan McDowell noodles@earth.li wrote:
On Tue, Sep 05, 2006 at 04:35:37PM +0100, Jenny Hopkins wrote:
On 05/09/06, Jonathan McDowell noodles@earth.li wrote:
I'd be checking MTUs everywhere, especially if he's on ADSL. Can he do other large transfers over the OpenVPN link to the same server?
He says (this is going to be awkward!) on our irc channel:
nickb I assumed that MTUs would affect throughput a lot but not the fact of it arriving. nickb Is this because of udp? nickb tcp will break up and reassemble packets
Yes, I'm well aware of that.
But.
You're layering OpenVPN on top of a UDP based network and there can be issues with the lower layer telling the OpenVPN wrapped layer that there is a need to fragment.
You didn't answer if you can do other large transfers to the same server. What about without OpenVPN involved (using eg ssh as the transport instead)?
Thanks for the replies - I'm madly posting them back and forward. Did i mention yet that that rsync over the openvpn was working just fine until Nick did this telephone/router thing? This: <snip>My problem is that I want the Vonage router to be close to the main feed so that its QoS can optimise its VoIP channel.</snip> Sorry if this is getting garbled.
Jen
On Tue, 2006-09-05 at 16:35 +0100, Jenny Hopkins wrote:
On 05/09/06, Jonathan McDowell noodles@earth.li wrote:
I'd be checking MTUs everywhere, especially if he's on ADSL. Can he do other large transfers over the OpenVPN link to the same server?
He says (this is going to be awkward!) on our irc channel:
nickb I assumed that MTUs would affect throughput a lot but not the fact of it arriving. nickb Is this because of udp? nickb tcp will break up and reassemble packets
OpenVPN supports Path MTU Discovery which *should* find the maximum packet size which can be supported, "--mtu-disc yes" I decided I'd rather set a conservative Maximum Segment Size (-mss-fix 1250) to ensure that TCP running through the tunnel always worked.
Ideally you find the maximum packet size and make sure all packets are <= that value.
The packet header:data ratio is higher with smaller MTU's, but it is true that MTU can effect delivery or non-delivery. Not every place in a network will want to spend time fragmenting packets and may elect to drop a packet bigger than it's locally configured mtu.
Adam
On 05/09/06, Mr. Adam ALLEN adam@dynamicinteraction.co.uk wrote:
OpenVPN supports Path MTU Discovery which *should* find the maximum packet size which can be supported, "--mtu-disc yes" I decided I'd rather set a conservative Maximum Segment Size (-mss-fix 1250) to ensure that TCP running through the tunnel always worked.
Ideally you find the maximum packet size and make sure all packets are <= that value.
The packet header:data ratio is higher with smaller MTU's, but it is true that MTU can effect delivery or non-delivery. Not every place in a network will want to spend time fragmenting packets and may elect to drop a packet bigger than it's locally configured mtu.
Adam
Many thanks for this and all other replies. The problem was indeed down to MTU issues: exactly what the fix was in the end I'm not sure. I'll ask Nick tomorrow when he's not being a vet then let you know.
Thanks, Jenny
On 06/09/06, Jenny Hopkins hopkins.jenny@gmail.com wrote:
Many thanks for this and all other replies. The problem was indeed down to MTU issues: exactly what the fix was in the end I'm not sure. I'll ask Nick tomorrow when he's not being a vet then let you know.
Nick said: <quote>
The problem was adding a Linksys RT31P2 router using NAT as supplied by vonage into a system where large file transmits were being done using openvpn.
It seems that forcing fragmentation of full openvpn packets (mtu 1500) by degrading the mtu in the router (mtu 149x) solved the "waiting for ever" problem. I suspect that the waiting-for-ever was due to udp packet loss that went unrecognised by openvpn for some reason.
There is no satisfactory full "deep" explanation as yet.
Nick </quote>
Thanks, Jenny
-
Brett Parker -
Jenny Hopkins -
Jonathan McDowell -
Mr. Adam ALLEN