[Openvpn-users] TAP driver stalls on windows [too]?

[Luc Van der Veken <lucvdv@xxxxxxxx>]

Sorry for the length of this, but I wanted to be as complete as
possible.

In short: the problem is [apparently] a TAP device that stops working
(on one machine only, the others seem to be fine).

I'm still running 1.5 beta 6, just downloaded beta 8 but not installed
yet.

For testing, I try to keep two OpenVPN tunnels open 24/24 and 7/7
between Win2000 machines.  A third will be added in a week or so, and
a fourth is only used every now and then (between my home machine and
the office, XP to Win2000).

There's only little traffic through the tunnels: an e-mail, auto-sent
every 4 hours to verify that the tunnel is still there; and through
one (the one that fails) I also log on to Terminal Server and access a
SQL server from time to time (normally less than once per day), but
that doesn't seem to be related to the problem: it always occurred
when the tunnel was idle (just sending its keepalives).


One of the tunnels is established over a LAN, without any routers
between the two endpoints.  It uses the default MTU.
This one is still up after two weeks (I test it by sending e-mails to
the tunnel's TAP IP address instead of the machine's normal IP
address).  It's between Win2000 Pro (client side) and Win2000 Server.


The other connects a DSL client (fixed IP, server side of the tunnel)
with a cable internet client (dynamic IP, but it hasn't changed yet
for as long as the test runs).  This connects two Win2000 Servers.

There's a firewall at both ends: on the server side that's a
Watchguard Firebox II set up to NAT the OpenVPN port to the machine
where the server side is running; on the client side it's a cheap
consumer-type D-Link firewall set up to block all but the tunnel's
port.
This tunnel uses a lower MTU because that was the only way to get RDP
(terminal server) connections to work through it.  The funny thing is
that this is not necessary on a connection from my home machine,
through the same cable internet provider (differences: different type
of cable modem, different brand of firewall, and IP address in another
range).


This tunnel just won't stay up, and it looks like it's the TAP driver
that keeps going down.  OpenVPN is set to auto-restart when the tunnel
goes away: it restarts, but it fails to re-establish the tunnel.
Restarting the OpenVPN service doesn't help.

After disabling and re-enabling the TAP driver in device management
the tunnel is re-established immediately (it says so in the logs),
_but_ no traffic is possible through it: it requires a reboot before
that starts working again.


The longest this tunnel has stayed up was 8 days, but the second
longest was only 24 hours.  The last time it was restarted was
yesterday at 10:10, the logs show an attempted auto-restart (that
failed to re-establish the connection) at 16:54.


Q1: Is there a known issue with the TAP driver that's included with
1.5 beta 6 that could cause this?


Q2: has a timeframe been set for a non-beta release?
I'm not trying to press, but I'll be needing stable, reliable tunnels
before the end of the year, sooner if possible.
If that falls outside of the expected timeframe, I'll have to look for
another solution.


Some config details:

- TAP subnet 10.254.254.4/30 (server 10.254.254.5, client
10.254.254.6)
[the other tunnels currently in use are 10.254.254.0/30 and
10.254.254.8/30]

- ports used: high (above 50000), one per tunnel.

- a different keyfile per tunnel (adequately protected against prying
eyes, even on the local machine).

- MTU on the TAP adapter = 1052 (1024 + packet header)

- server and client sides are _both_ set to auto-restart and to send
keepalives.
Originally the server side didn't auto-restart, I added this after it
happened a number of times to get a log entry when the tunnel is
broken.  I set it to double the restart delay of the client side, so
they don't both restart at the same moment.

- both Win2000 servers run RRAS with static routes set to the other
side's LAN through the tunnel.
One network is 192.168.0.0/24, the other 10.13.9.0/24.
On the tunnel server side (192.168), packet filters are installed that
allow only the right incoming packets to keep the clients off of a
second local network they have no business on, and to keep them out of
each other's networks.  Allowed packets are: the LAN they have access
to, the tunnel's own subnet, and the server's address (/32) on the
network they have no access to (in case something on it ever tells a
client that's its IP address).


Config file, server side (comments stripped):
The resolv-retry entries do nothing, because of fixed IP addressing.

port 5xxxx
tun-mtu 1052
dev tap
dev-node OpenVPN-5xxxx
secret key-5xxxx.txt
ping-restart 120
ping-timer-rem
persist-tun
persist-key
resolv-retry 86400
ping 10
comp-lzo
verb 3
mute 10
up updownlog.cmd
down updownlog.cmd
up-restart

The config file on the client size is identical, except for:

remote x.y.z.a
ping-restart 60



____________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users