[Openvpn-devel] Release candidate for 1.4.0

[James Yonan]

We're on the final stretch for 1.4.0, so if possible, please give this release
a spin.

http://openvpn.sourceforge.net/beta/openvpn-1.3.2.24.tar.gz

I plan to release 1.4.0 shortly if there are no problems.

James

Re: [Openvpn-devel] TCP-over-TCP (was: Multi-channel VPN)

[James Yonan]

Matthias Andree  said:

> On Sat, 19 Apr 2003, Aaron Sethman wrote:
> 
> > I'm not necessarly sure it belongs in OpenVPN, but then again, I can see
> > the advantages to automatically failover to other links.  Perhaps
> > abstracting things out in the code a bit that it would be possible to have
> > multiple methods of sending data out to the world, perhaps even non-ip
> > methods.  Or even implementing something as tunnelling over TCP(I do know
> > the reasons why you don't want to do this, but in some cases you don't
> > have a choice, and are willing to eat the performance loss).
> 
> TCP-over-TCP tunnelling isn't necessarily a performance loss, but it
> also exhibits excessive retransmit behaviour -- which isn't too bad if
> you have congested links and need to take a bigger share than the others
> ;-) I've always found vpnd (tcp-over-tcp) to be more stable than vtund
> (over udp in my configurations) across congested links, but I haven't
> compared vpnd to openvpn. (And I've found vtund to be fragile, a single
> ping -f into a tunnel usually let the tunnel collapse on Linux. OpenVPN
> is solid in these circumstances.)

I wonder if one could build a better tcp-over-tcp by doing some intelligent
packet filtering on the higher level tcp connection, such as filtering out
retransmits and fudging return ACKs -- essentially removing those elements of
the TCP protocol which are designed to make TCP work over an unreliable link.

James

[Openvpn-devel] TCP-over-TCP (was: Multi-channel VPN)

[Matthias Andree]

On Sat, 19 Apr 2003, Aaron Sethman wrote:

> I'm not necessarly sure it belongs in OpenVPN, but then again, I can see
> the advantages to automatically failover to other links.  Perhaps
> abstracting things out in the code a bit that it would be possible to have
> multiple methods of sending data out to the world, perhaps even non-ip
> methods.  Or even implementing something as tunnelling over TCP(I do know
> the reasons why you don't want to do this, but in some cases you don't
> have a choice, and are willing to eat the performance loss).

TCP-over-TCP tunnelling isn't necessarily a performance loss, but it
also exhibits excessive retransmit behaviour -- which isn't too bad if
you have congested links and need to take a bigger share than the others
;-) I've always found vpnd (tcp-over-tcp) to be more stable than vtund
(over udp in my configurations) across congested links, but I haven't
compared vpnd to openvpn. (And I've found vtund to be fragile, a single
ping -f into a tunnel usually let the tunnel collapse on Linux. OpenVPN
is solid in these circumstances.)

-- 
Matthias Andree