Trouble with openvpn and /dev/tun

[Dmitri Nikulin]

Dirk Liebke wrote:

>Hi all,
>
>after upgrading from dfly 1.1 to HEAD as of 2005/07/0 i am having some
>problems with openvpn. Openvpn (1.5) is configured to run udp and uses
>/dev/tun to connect my dfly-box to FreeBSD-4.11. Both ends of the link
>connect properly and the tunnel is established.
>
>Now to the problem:
>If i try to open a telnet/ssh session over my secure link it takes
>a few minutes to establish and is practically unusable because of high
>latency. Next i tried to ping the freebsd-box from my dfly-box. The ping
>stalls for about 30s and then receivs a storm of replys with decreasing
>round trip times from around 30000ms to 120ms. Packet loss is about 10%.
>
>If i do the reverse thing and ping from freebsd i get round trips from
>about 120ms and no packet loss. A fresh port of openvpn-2 shows the same
>asymmetrical behaviour.
>
>
>- Dirk
>
I have no problems with OpenVPN (after applying manual ifconfig/route -
somebody needs to teach OpenVPN to use DFly tools) on DFly.

DFly OVPN: 2.0rc1 from pkgsrc (when will that be updated?!!), on
1.3-PREVIEW as of around 24 hours ago
Linux OVPN: 2.0-r1 from Gentoo Portage, on 2.6.12-gentoo-r3

It sounds strange and may just be a problem with -HEAD. If you can, try
-PREVIEW, and if that fails, no idea. I was about to suggest it was
related to the recent TCP anti-exploit adjustments, but this has nothing
to do with TCP.

Don't suppose you have an altq/dummynet setup that creates one-way
packet loss and you forgot about it? :)

I've never heard of this kind of behavior, but I have had corker
problems with some particular users on my Windows-centric OpenVPN -
though mostly because of disastrous internet connections that drop every
few minutes. OpenVPN eventually catches up with all the packets as it
should, though it gives that kind of extreme latency behavior that would
definitely kill a TCP state.

-Dmitri Nikulin