[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Google
 
Web openvpn.net

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


  • Subject: Re: [Openvpn-users] (WSAECONNRESET) (code=10054) over UDP, packet dropped due to output saturation over TCP with TUN
  • From: James Yonan <jim@xxxxxxxxx>
  • Date: Tue, 07 Feb 2006 20:10:17 -0700

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