>> Isn't an SSL based tunnel all TCP? > Not in the case of OpenVPN. I'm not sure about the commercial > offerings.
Correct. My recollection is that OpenSSL uses TCP for the setup and management of the tunnel (e.g. authentication and key exchange) and uses UDP to carry the actual payload... each tunneled IP packet is wrapped in a UDP datagram. That way, the UDP transport "mimics" the basic characteristics of normal IP transport - it's best-efforts, order not guaranteed, and no built-in retries. The number of lost (or out-of-order) packets in such a tunneled connection shouldn't be significantly different than what you'd see if you weren't using a tunnel at all. There seems to be a good deal of feeling (and evidence) that trying to use TCP as the container for a tunnel is likely to cause more trouble than it solves. Yes, the TCP layer will make the tunnel "reliable" - but at the expense of adding unpredictable amounts of latency, due to TCP's built-in exponential-backoff retry timing. Things get *really* nasty if you try to wrap one TCP connection in another, because both connections will be independently retrying any lost or delayed packets - you'll end up retransmitting quite a bit more data than you would if you simply used TCP/IP (or TCP/IP wrapped in UDP/IP) and throughput will suffer. I've been using an OpenSSL tunnel to connect my Nokia N810 internet tablet to my Asterisk server, for about a year now. It works very nicely, eliminating NAT- related problems (no need to STUN) and allowing me to use VoIP from most WiFi networks I can log onto. _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2009 - October 13 - 15 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
