Re: [Openvpn-users] (WSAECONNRESET) (code=10054) over UDP, packet dropped due to output saturation over TCP with TUN

[James Yonan <jim@xxxxxxxxx>]

Cameron Gocke wrote:
> On 2/2/06, Ben Scott <dragonhawk@xxxxxxxxx> wrote:
>   
> > On 2/2/06, Cameron Gocke <livedrive777@xxxxxxxxx> wrote:
> >     
> > > That is correct, the exact error taken from the log is this:
> > >
> > > Thu Feb 02 15:15:41 2006 read UDPv4: Connection reset by peer
> > > (WSAECONNRESET) (code=10054)
> > >
> > > So, no client information is included.
> > >       
> >  Bummer.  :)
> >
> >     
> > > I can try modifying my firewall to allow all traffic outbound from UDP
> > > 443 to any and see what happens.
> > >       
> >  Maybe this is a thinko, but: Unless you've changed the default,
> > OpenVPN 2.x uses UDP port 1194.  UDP port 443 is HTTPS (HTTP over
> > SSL).
> >
> >     
> > > Thanks for the help Ben ...
> > >       
> >  You're welcome.  Good luck!
> >
> > -- Ben
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> > for problems?  Stop!  Download the new AJAX search engine that makes
> > searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> > _______________________________________________
> > Openvpn-users mailing list
> > Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
> > https://lists.sourceforge.net/lists/listinfo/openvpn-users
> >
> >     
>
> OK, I have some more info on this that will hopefully (cross my
> fingers) shead some light here...
>
> Since I was getting nowhere with the WSAECONNRESET code=10054 error
> over my UDP connection I decided to put a couple of users onto a TCP
> connection to see if that helped keep a more consistant connection to
> the IP phones.  Well what I see in my server log now when their phone
> connection drops is this error:
>
> MULTI: packet dropped due to output saturation (multi_process_incoming_tun)
>
> I saw a single reference in the archives regarding too much broadcast
> traffic over bridged connections, but since I'm using a routed TUN
> connection that doesn't get me very far.
>
> Ideas?  Is there something about the IP phone traffic specifically
> that might be flooding something with traffic?  I'm hoping this new
> error is helpful because truthfully it raises more questions for me
> than answers.
>   
This error message basically means that data is coming in on the TUN/TAP 
interface faster than the outgoing network connection can support.

With TCP connections over the tunnel, this almost never occurs because 
TCP is smart about throttling the data rate to ensure that the network 
link can support it.  Thus OpenVPN will rarely be in a situation where 
it is getting data at a faster rate than it can send it.

However, with UDP traffic over OpenVPN tunnels (or over the open 
internet for that matter), the UDP sender needs to handle rate limiting 
by itself.

Now if you run OpenVPN over TCP, then run a UDP based IP phone service 
over OpenVPN then you basically have a UDP -> OpenVPN -> TCP 
connection.  Now since TCP is automatically rate limited but UDP is not, 
then if OpenVPN is getting data at X bytes per second via the UDP VoIP 
protocol but the underlying TCP connection to the other OpenVPN peer can 
handle less than X bytes per second, then you have a data overrun 
situation and OpenVPN has no choice but to drop the packets.   This is 
what the "MULTI: packet dropped due to output saturation message" means.

James

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