asterisk users - Sep 2009 - New thread - SIP over VPN

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

On Sat, 2009-09-26 at 22:47 -0700, Dave Platt wrote:
>  >> Isn't an SSL based tunnel all TCP?
> 
> 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.
> 
That is the main reason why the widespread of (TCP) SSH-tunnels is
discouraged: as you get an TCP-protocol encapsulated in another
TCP-layer.
Missing frames will be corrected by the outermost TCP-protocal-suite,
however as soon as you got a bad-connection (Often wifi) and are
confronted with timeouts, re-transmissions will on make things worse.
and end-up with a snowball-effect.

So i would opt for ipsec-tunnel or openvpn with UDP.
If you have a rock-solid connection you could even use an openSSH-vpn
tunnel.

hw