|
|
Luc Van der Veken <lucvdv@xxxxxxxx> said: > 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. You might try beta8 (or beta9 which will be released shortly with new OpenSSL 0.9.7c DLLS in response to the security advisory). A great deal of cleanup & stability work has gone into the driver between beta7 and beta8. There's also better diagnostics, e.g. if you run beta8 or higher from a console window, F2 will print a driver status line which contains information that would be useful in troubleshooting possible driver bugs. > 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? It's quite possible. I would try to test on beta9 (will be released shortly). I will certainly work with you to track down bugs. > 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. My threshold for releasing 1.5 is that a beta or release candidate has been out for 2 or 3 weeks and shows all of the qualities of stability of OpenVPN 1.4.3 running on non-Windows platforms. While it's hard to say exactly when that will happen, I would expect that it's probably more than one month away but less than four. One thing that I could use right now to accelerate the process is direct access to a Win2K machine. I rarely hear of problems running the TAP-Win32 driver on XP -- because that's what my development laptop is running, and I test on XP fairly extensively before I release stuff. The problem is that Win2K is different enough from XP that a lot of things that work fine on XP (such as ethernet bridging) simply don't work on Win2K. So when there are problems, I tend to only hear about them by email, and I can tell you that debugging by email is at least 10 times slower than debugging when you have direct access to a machine. > 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 > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Openvpn-users mailing list > Openvpn-users@xxxxxxxxxxxxxxxxxxxxx > https://lists.sourceforge.net/lists/listinfo/openvpn-users > -- ____________________________________________ Openvpn-users mailing list Openvpn-users@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/openvpn-users |