openvpn-devel Mailing List for OpenVPN

On 9/30/05, Marcelo Toledo <ma...@ma...> wrote: > Em Ter, 2005-09-27 =E0s 21:58 -0400, Leonard Isham escreveu: > > On 9/27/05, Marcelo Toledo <ma...@ma...> wrote: > > > I have one OpenVPN server version 2.0.2 using TCP port 1194 with TLS > > > with about 400 clients connected to it. From time to time it's > > > impossible to ping the client from the server, but if you log into th= e > > > client and ping the server, the server now became able to ping the > > > client. I made a lot of tests removing the bridge and trying a older > > > versions of openvpn and the problem still hapenning with about 20% of > > > the clients connected to the vpn. > > > > > > here is the config of the client and server: > > > > > > # SERVER CONFIG > > > mode server > > > port 1194 > > > proto tcp-server > > > dev tap > > [snip] > > > > Observations: > > 1. 400 clients... 1 server only? > > Yes, 400 clients and only 1 server. What are the stats on the server? Are there any resource issues?=20 CPU, TCP. etc. > > 2. TAP means additional overhead full ethernet packet encapsulated in > > TCP/IP packet. Broadcasts, fragmented ethernet datagrams and for 400 > > clients.... > > We don't use TUN because from what I know it opens one connection per > port and also one configuration per client, which is insane for a 400 > clients and growing (we're going to reach 600 by the end of this year). OpenVPN 1.X was one port per connection TUN or TAP. OpenVPN 2.x supports the old setup, but was designed with a server mode for _both_ TUN and TAP. You can either dynamically hand out IP addresses or statically with either method. > > 3. TCP over TCP is not recommended. The internal congestion control > > can conflict with the external congestion control. > > We already used OpenVPN with UDP, but the oscillations were much higher > then today, that's why we migrated to TCP. This indicates that you are experiencing connectivity issues, outside of the tunnel. UDP is connection less, and OpenVPN will not retransmit. Broadcasts or connectionless and usually have no retransmission capacity. TCP is is connection oriented and will resend packets, even the broadcast packets as they are just payload to TCP. Connectivity problems can still cause TCP failures. To many failures and reconnection attempts will use up TCP sockets, an unintentional self inflicted DOS. > > 4. What is your full bandwidth and usable bandwidth at the server? > > We have 3MB and we're using half of it (1.5). What is the bandwidth at the client sites? > what do you think? Are these site-to-site or road warriors? Are the 20% always the same or random? Do the 20% have anything in common. Ant NAT devices or firewalls in between that may be having periodic resource issues? Have you considered setting up cacti or other system to monitor resources and provide graphs? Consider setting up a second server or OpenVPN instance and use TUN with UDP and migrate. Do you have any packet captures of the traffic out the TAP interface on the server and client that experiences the failures? I don't know your workload or any other details, but what about another person to take some of your workload so you can concentrate on this issue. Or a second set of eyes to work on this issue with you (I would look for someone with at least as much networking experience as you have). -- Leonard Isham, CISSP Ostendo non ostento. 

Em Ter, 2005-09-27 às 21:58 -0400, Leonard Isham escreveu: > On 9/27/05, Marcelo Toledo <ma...@ma...> wrote: > > I have one OpenVPN server version 2.0.2 using TCP port 1194 with TLS > > with about 400 clients connected to it. From time to time it's > > impossible to ping the client from the server, but if you log into the > > client and ping the server, the server now became able to ping the > > client. I made a lot of tests removing the bridge and trying a older > > versions of openvpn and the problem still hapenning with about 20% of > > the clients connected to the vpn. > > > > here is the config of the client and server: > > > > # SERVER CONFIG > > mode server > > port 1194 > > proto tcp-server > > dev tap > [snip] > > Observations: > 1. 400 clients... 1 server only? Yes, 400 clients and only 1 server. > 2. TAP means additional overhead full ethernet packet encapsulated in > TCP/IP packet. Broadcasts, fragmented ethernet datagrams and for 400 > clients.... We don't use TUN because from what I know it opens one connection per port and also one configuration per client, which is insane for a 400 clients and growing (we're going to reach 600 by the end of this year). > 3. TCP over TCP is not recommended. The internal congestion control > can conflict with the external congestion control. We already used OpenVPN with UDP, but the oscillations were much higher then today, that's why we migrated to TCP. > 4. What is your full bandwidth and usable bandwidth at the server? We have 3MB and we're using half of it (1.5). what do you think? -- Marcelo Toledo <ma...@ma...> 

Hello James, Is there anything missing from the PKCS#11 integration implementation that I should complete? Best Regards, Alon Bar-Lev. -------------------------------- From: Alon Bar-Lev <alon@gm...> RE: openvpn-2.0.2-pkcs11-20050916.patch 2005-09-19 11:05 James Yonan wrote: > Something that would integrate as a section in the current 2.0 HOWTO, such as "How to add dual-factor authentication to an OpenVPN > configuration using client-side smartcards". Updated. http://sourceforge.net/tracker/index.php?func=detail&aid=1293066&group_id=48 978&atid=454721 I hope you see the new version is on the right direction... Best Regards, Alon Bar-Lev. 

OpenVPN-devel is intended for those who are actively involved in working on OpenVPN's source code. Your issue is more appropriate for OpenVPN-users, as it discusses usage rather than development of OpenVPN. That said -- try disabling the tap-win32 adapter. If you still see the issue, you'll have ruled out OpenVPN as its cause. 

SSBzZXQgdXAgYSBWUE4gZm9yIGEgY2xpZW50IHdpdGggYSBzbWFsbCBvZmZpY2UgYmV0d2VlbiBh IGNvbXB1dGVyIGluIHRoZWlyCm9mZmljZSBhbmQgYSByb2FtaW5nIGxhcHRvcCwgYm90aCBydW5u aW5nIFhQLiBJbiB0aGUgcHJvY2VzcyBJIHdhcyB0cnlpbmcgdG8KcG9ydC1mb3J3YXJkIGEgaG9s ZSB0aHJvdWdoIHRoZWlyIGxpbmtzeXMgcm91dGVyIGZpcmV3YWxsLCBhbmQga2VwdCBnZXR0aW5n CjQwNCBlcnJvcnMuIFNvIEkgdXBncmFkZWQgdGhlIGxpbmtzeXMgdG8gdGhlIGxhdGVzdCBmaXJt d2FyZS4gKEkgd2lzaCBJCmNvdWxkIHNheSBwcmVjaXNlbHkgd2hhdCBtb2RlbCBpdCB3YXMsIGJ1 dCBJIGRvbid0IHJlY2FsbC4gSSB0aGluayBpdCB3YXMKbm90IGEgd3J0NTRnIGFsdGhvdWdoIHRo ZSBtZW51cyBsb29rIHRoZSBzYW1lIGFzIGEgd3J0NTRnKQogVGhlIDQwNCBlcnJvcnMgd2VudCBh d2F5LCBidXQgdGhlIG5leHQgZGF5IHRoZSBYUCBib3ggaW4gdGhlIG9mZmljZSBkaWRuJ3QKZ2V0 IGEgREhDUCBhZGRyZXNzLiBUaGVuIHRoZSBsYXB0b3Agd2FzIGJyb3VnaHQgaW4gYSBmZXcgZGF5 cyBsYXRlciBhbmQgYWxzbwp3b3VsZCBub3QgZ2V0IGEgREhDUCBhZGRyZXNzLiBPdGhlciBYUCBi b3hlcyBpbiB0aGUgb2ZmaWNlIHN0aWxsIGdldCBESENQCmZyb20gdGhlIGxpbmtzeXMganVzdCBm aW5lLiBTdGF0aWMgYWRkcmVzc2VzIHdvcmsgZmluZSwgc28gY29ubmVjdGl2aXR5Cmlzbid0IGFu IGlzc3VlIC0gdGhleSBqdXN0IHdvbid0IGdldCBhIGRoY3AgYWRkcmVzcyBmcm9tIHRoZSBsaW5r c3lzLiBUaGlzCmlzIHJlZ3VsYXIgd2lyZWQgZXRoZXJuZXQsIHRoZSB3b3Jrc3RhdGlvbi9zZXJ2 ZXIgaXMgYSBEZWxsIGFuZCBJIHRoaW5rIHRoZQpsYXB0b3AgaXMgYW4gSFAuCiBJcyB0aGVyZSBh bnkgcmVhc29uIHdoeSB0aGlzIG1pZ2h0IGJlIGhhcHBlbmluZyB0aGF0IGNvdWxkIGJlIHJlbGF0 ZWQgdG8KT3BlblZQTj8gVGhhdCBpcyB0aGUgb25seSB0aGluZyBfSV8gY2FuIHRoaW5rIG9mIChh c2lkZSBmcm9tIGhhcHB5CmNvaW5jaWRlbmNlKSB0aGF0IHRob3NlIHR3byBjb21wdXRlcnMgaGF2 ZSBpbiBjb21tb24gdGhhdCB0aGUgb3RoZXIgWFAKY29tcHV0ZXJzIGluIHRoZSBvZmZpY2UgZG9u J3QuCgotLQpIYW5zIEZ1Z2FsCkZ1Z2FsIENvbXB1dGluZwo=

Hi all, I've been trying to compile openvpn 2.0.2 with lzo-1.08, and openssl-0.9.7d installed (corresponding dev-packages also). While compiling I get the following error: gcc -O2 -g -march=i586 -mcpu=i686 -fmessage-length=0 -o openvpn base64.o buffer.o crypto.o error.o event.o fdmisc.o forward.o fragment.o gremlin.o helper.o init.o interval.o list.o lzo.o manage.o mbuf.o misc.o mroute.o mss.o mtcp.o mtu.o mudp.o multi.o ntlm.o occ.o openvpn.o options.o otime.o packet_id.o perf.o ping.o plugin.o pool.o proto.o proxy.o push.o reliable.o route.o schedule.o session_id.o shaper.o sig.o socket.o socks.o ssl.o status.o thread.o tun.o -lssl -lcrypto -llzo -ldl lzo.o(.text+0x7cd): In function `lzo_compress_init': /usr/src/packages/BUILD/openvpn-2.0.2/lzo.c:112: undefined reference to `__lzo_init_v2' collect2: ld returned 1 exit status make[1]: *** [openvpn] Fehler 1 make[1]: Leaving directory `/usr/src/packages/BUILD/openvpn-2.0.2' make: *** [all] Fehler 2 error: Bad exit status from /var/tmp/rpm-tmp.10360 (%build) Any hints THX in advance 

On Wed, 28 Sep 2005, Matthias Andree wrote: > I have worked quite a bit with Berkeley DB (which SVN set off with as > its database backend) in bogofilter, and while lots of things are to be > said about BDB robustness and corruptions, the most important point of > criticism is that one needs to take BDB by the hand and guide it, and it > doesn't tolerate application bugs that cause BDB to be used improperly. > If used properly, it's fast and solid - but then you've entered the > realm of transactions, and they're as awful to hack as GTK+ or assembly > language - it's all raw and low-level. True, but SVN supports different repository formats, and BDB is just one option (and rather deprecated at this point). I'm using an FSFS repository, which gets away from nearly all of the disadvantages of BDB. James 

On 9/27/05, Marcelo Toledo <ma...@ma...> wrote: > I have one OpenVPN server version 2.0.2 using TCP port 1194 with TLS > with about 400 clients connected to it. From time to time it's > impossible to ping the client from the server, but if you log into the > client and ping the server, the server now became able to ping the > client. I made a lot of tests removing the bridge and trying a older > versions of openvpn and the problem still hapenning with about 20% of > the clients connected to the vpn. > > here is the config of the client and server: > > # SERVER CONFIG > mode server > port 1194 > proto tcp-server > dev tap [snip] Observations: 1. 400 clients... 1 server only? 2. TAP means additional overhead full ethernet packet encapsulated in TCP/IP packet. Broadcasts, fragmented ethernet datagrams and for 400 clients.... 3. TCP over TCP is not recommended. The internal congestion control can conflict with the external congestion control. 4. What is your full bandwidth and usable bandwidth at the server? Troubleshooting: Do packet captures on the real interfaces that the VPN tunnel is using (there the TCP 1194 traffic is), the TAP interfaces. Look for TCP issues. Recommendations: 1. switch to UDP 2. switch to TUN even if this requires additional configuration. to rely on broadcasts over a VPN is problematic. 3. Bandwidth may be a major bottleneck. suggestions 1 & 2 will help, but it may not be enough. 4. Server look for bottlenecks, may require upgrade(s). Removing one bottleneck may reveal the next bottleneck... -- Leonard Isham, CISSP Ostendo non ostento. 

On Tue, 27 Sep 2005, Charles Duffy wrote: > I'm not particularly fond of svn -- I think it's not nearly ambitious > enough[1] and have had DB corruption issues in the past -- but it's > certainly a big step up from CVS, and history stored in SVN can be far > less ambiguously retrieved. I have worked quite a bit with Berkeley DB (which SVN set off with as its database backend) in bogofilter, and while lots of things are to be said about BDB robustness and corruptions, the most important point of criticism is that one needs to take BDB by the hand and guide it, and it doesn't tolerate application bugs that cause BDB to be used improperly. If used properly, it's fast and solid - but then you've entered the realm of transactions, and they're as awful to hack as GTK+ or assembly language - it's all raw and low-level. SVN has its shortcomings, and it's a huge beast, code-wise, but switching programmers from CVS to SVN is easy. > [1] [about competitors] > though most of them do have downsides: Arch, for instance, is difficult > to learn and has poor win32 support, while Darcs is easy to learn and > portable but has serious scalability issues, and several of the others > are behind Arch or Darcs in terms of providing the above-mentioned > design features and functionality -- though there are some very new > systems (such as Git and Mercurial) which have impressive performance > characteristics, despite (as before) not having all the functionality > (or, in many cases, a design which allows straightforward implementation > of all the functionality) of the best-designed distributed SCMs. I think that SCM systems are interesting to watch and to see what comes out of it. After long years with everyone being happy between RCS and CVS, some still on SCCS, some trying BitKeeper for a change, a lot of projects have started, some have forked, and it's interesting to watch some of them taking a second attempt before the first one had even completely finished - SCMs are certainly a field where a lot of development will take place in the near future. For a maintainer however, he needs to get a job done. Trying the SCM of the week will distract him from the real work, pull him into the depths of meta data export, and in the end the situation might be worse than it used to be even with CVS's serious shortcomings. > [2] - Distributed operation is IMHO a killer feature doing open source > development: It means that 3rd parties working on their own patches have > revision control tools assisting them both in building the patch and > keeping it up-to-date with the maintainer's tools, and providing the > same level of support (ie. history of specific changes that went into > their patch/branch) that projects done by the maintainer receive. Having > worked on a few OSS projects using distributed revision control systems, > I find it quite hard to go back. While they all have their advantages, they, too, need proper handling, and you can also just import the upstream branch in your local SCM of the day, clone the code and hack away, and then merge back. It gets, of course, harder if you do a lot of work, but it's certainly OK for the "occasional" patch - and lots of work in the OSS communities is that someone sends a short patch, it's merged, and at that point, the local separate branch becomes obsolete -- it was a single merge point, perhaps two or three, and that's it. I think if the SCM zoo has stabilized in two years, we hackers (I'm not speaking for the OpenVPN project now) will have some more tools that a maintainer can rely on, that are widespread and work well. Those that caught my eye, and are open source, are listed in <http://home.pages.de/~mandree/version-control-links.html> - chances are there's a new promising contestant out that I've missed in the past quarter or someone that used to be centralized has now gone distributed. -- Matthias Andree 

On Tue, 27 Sep 2005, Charles Duffy wrote: > Feel free to ignore the below rant. Revision control is (or at least was > for quite some time) one of my pet topics, and I occasionally feel > compelled to bore people at parties (or on mailing lists) with a > discussion of the subject. I certainly don't mean to compell anyone to > switch RCSs a *second* time within a short period, though if a public > request for comments would have been made, I might have argued hard for > something different. > > James Yonan wrote: > > I used the cvs2svn tool to convert the repository, so all the previous cvs > > metadata such as branch tags are still there. > > Heh. > > As former maintainer of cscvs (a tool which was most often used to > import CVS history into GNU Arch), I'm more than a bit interested in > just how effective cvs2svn's changeset-generation turns out to be, > particularly in corner-cases (temporally overlapping commits or single > commits split by a conflict partway through; commits made from systems > with incorrect clocks [CVS uses the client's time, rather than the > server's]; commits with comments quoting "cvs log" output (rlog doesn't > quote user-provided data, so this can make parsing extremely hairy -- > though this isn't such an issue if one works off the ,v files, those > aren't always available); files implicitly created by CVS on the trunk > due to a new addition to a branch; or the many other corner cases > exposed by branching which I no longer have a good recollection of. > > I'm not particularly fond of svn -- I think it's not nearly ambitious > enough[1] and have had DB corruption issues in the past -- but it's > certainly a big step up from CVS, and history stored in SVN can be far > less ambiguously retrieved. > > > [1] - Consider that competing next-generation revision control systems > offer distributed operation (allowing 3rd parties to start their own > branches hosted on their own servers, and allowing easy merging between > these various branches[2]); that competing systems offer > "cherry-picking", which allows detailed tracking of which specific > changesets/patches have been applied on which branches and thus prevents > spurious merge attempts; that competing systems, being changeset- rather > than snapshot-based, can offer more intelligent merge algorithms... > though most of them do have downsides: Arch, for instance, is difficult > to learn and has poor win32 support, while Darcs is easy to learn and > portable but has serious scalability issues, and several of the others > are behind Arch or Darcs in terms of providing the above-mentioned > design features and functionality -- though there are some very new > systems (such as Git and Mercurial) which have impressive performance > characteristics, despite (as before) not having all the functionality > (or, in many cases, a design which allows straightforward implementation > of all the functionality) of the best-designed distributed SCMs. > > [2] - Distributed operation is IMHO a killer feature doing open source > development: It means that 3rd parties working on their own patches have > revision control tools assisting them both in building the patch and > keeping it up-to-date with the maintainer's tools, and providing the > same level of support (ie. history of specific changes that went into > their patch/branch) that projects done by the maintainer receive. Having > worked on a few OSS projects using distributed revision control systems, > I find it quite hard to go back. Charles, You make good points, and I completely agree with you that long-term, distributed SCMs are the way to go. My main inclination in choosing SVN right now is that it's mature, well-documented, fast, and is a (mostly) drop-in replacement for CVS which we were using before. SVN does a good job of accomplishing what it tries to do, based on the collective experience of many years using CVS, and the way that that experience helped us to construct a well-fashioned understanding of just what an ideal CVS would like like (without jumping out of the CVS model into the distributed SCM realm). In many respects, SVN is simply the latest release of CVS. The distributed SCMs on the other hand are trying to tackle a much more challenging problem. To a certain extent, even an agreed-upon, canonical articulation of the distributed SCMs feature space is elusive at this point. There's certainly a lot of great development occurring right now, but the tools are going to be a moving target for some time. So yes -- I'd love to switch to a distributed SCM, and I'd switch in a heartbeat if there was an open source alternative, say, of the same caliber as BK. I'm sure that will happen in the next few years, but until then I don't feel that the OpenVPN project has scaled up in development activity so much that the choice of SCM is holding it back. James 

I have one OpenVPN server version 2.0.2 using TCP port 1194 with TLS with about 400 clients connected to it. From time to time it's impossible to ping the client from the server, but if you log into the client and ping the server, the server now became able to ping the client. I made a lot of tests removing the bridge and trying a older versions of openvpn and the problem still hapenning with about 20% of the clients connected to the vpn. here is the config of the client and server: # SERVER CONFIG mode server port 1194 proto tcp-server dev tap tls-server ca keys/ca.crt cert keys/sauron.crt key keys/sauron.key dh keys/dh1024.pem #tls-auth keys/ta.key 0 #ifconfig 10.100.0.2 255.255.0.0 #ifconfig-pool 10.100.99.50 10.100.99.100 255.255.0.0 server-bridge 10.100.0.10 255.255.0.0 10.100.99.100 10.100.255.254 push "dhcp-option DNS 200.160.255.85" push "dhcp-option DNS 200.160.255.84" push "ping 10" push "ping-restart 60" client-config-dir config client-to-client keepalive 10 120 comp-lzo max-clients 1024 persist-key persist-tun status openvpn-status.log log openvpn.log verb 2 ########## # CLIENT CONFIG client tls-client dev tap proto tcp-client #remote-random remote 200.160.255.100 #remote vpn1.vexbr.com.br #remote vpn2.vexbr.com.br rport 1194 lport 9000 resolv-retry infinite persist-key persist-tun mute-replay-warnings float ping 10 ping-restart 60 comp-lzo verb 4 ca keys/ca.crt up ./vexbr.up cert keys/escritorio-claro.crt key keys/escritorio-claro.key ############# -- Marcelo Toledo <ma...@ma...> 

Feel free to ignore the below rant. Revision control is (or at least was for quite some time) one of my pet topics, and I occasionally feel compelled to bore people at parties (or on mailing lists) with a discussion of the subject. I certainly don't mean to compell anyone to switch RCSs a *second* time within a short period, though if a public request for comments would have been made, I might have argued hard for something different. James Yonan wrote: > I used the cvs2svn tool to convert the repository, so all the previous cvs > metadata such as branch tags are still there. Heh. As former maintainer of cscvs (a tool which was most often used to import CVS history into GNU Arch), I'm more than a bit interested in just how effective cvs2svn's changeset-generation turns out to be, particularly in corner-cases (temporally overlapping commits or single commits split by a conflict partway through; commits made from systems with incorrect clocks [CVS uses the client's time, rather than the server's]; commits with comments quoting "cvs log" output (rlog doesn't quote user-provided data, so this can make parsing extremely hairy -- though this isn't such an issue if one works off the ,v files, those aren't always available); files implicitly created by CVS on the trunk due to a new addition to a branch; or the many other corner cases exposed by branching which I no longer have a good recollection of. I'm not particularly fond of svn -- I think it's not nearly ambitious enough[1] and have had DB corruption issues in the past -- but it's certainly a big step up from CVS, and history stored in SVN can be far less ambiguously retrieved. [1] - Consider that competing next-generation revision control systems offer distributed operation (allowing 3rd parties to start their own branches hosted on their own servers, and allowing easy merging between these various branches[2]); that competing systems offer "cherry-picking", which allows detailed tracking of which specific changesets/patches have been applied on which branches and thus prevents spurious merge attempts; that competing systems, being changeset- rather than snapshot-based, can offer more intelligent merge algorithms... though most of them do have downsides: Arch, for instance, is difficult to learn and has poor win32 support, while Darcs is easy to learn and portable but has serious scalability issues, and several of the others are behind Arch or Darcs in terms of providing the above-mentioned design features and functionality -- though there are some very new systems (such as Git and Mercurial) which have impressive performance characteristics, despite (as before) not having all the functionality (or, in many cases, a design which allows straightforward implementation of all the functionality) of the best-designed distributed SCMs. [2] - Distributed operation is IMHO a killer feature doing open source development: It means that 3rd parties working on their own patches have revision control tools assisting them both in building the patch and keeping it up-to-date with the maintainer's tools, and providing the same level of support (ie. history of specific changes that went into their patch/branch) that projects done by the maintainer receive. Having worked on a few OSS projects using distributed revision control systems, I find it quite hard to go back. 

On Mon, 26 Sep 2005, James Yonan wrote: > I've migrated the OpenVPN source repository from CVS to subversion. > > Read-only access is available at svn://openvpn.net/openvpn > > Examples: > > Check out the stable branch: > svn checkout svn://openvpn.net/openvpn/trunk openvpn Hum, it has trunk/CVSROOT trunk/openvpn Probably the CVSROOT is not too useful to other people, so to checkout: svn checkout svn://openvpn.net/openvpn/trunk/openvpn openvpn -------- Should give more of what is expected to start work. Best viewed with a nonproportional font :) -- Matthias Andree 

I've migrated the OpenVPN source repository from CVS to subversion. Read-only access is available at svn://openvpn.net/openvpn Examples: Check out the stable branch: svn checkout svn://openvpn.net/openvpn/trunk openvpn Check out the BETA21 branch (has the new topology subnet and non-admin TAP-Win32 features): checkout svn://openvpn.net/openvpn/branches/BETA21 openvpn Check out the BETA25 branch (very experimental): checkout svn://openvpn.net/openvpn/branches/BETA25 openvpn I used the cvs2svn tool to convert the repository, so all the previous cvs metadata such as branch tags are still there. James 

On Mon, 26 Sep 2005, Juergen Hennerich wrote: > Hi, > > I'm currently building a Windows installer for a debian/coLinux based > embedded toolchain. > > For internet access I'm using the slirp daemon which is a zero > configuration solution and is working great. But for local access I have > to use a tap device. > > My problem is, while I can install the driver without a problem, I have > no idea how to configure the network interface. I need to find an unused > private subnet and set the IP address of the tap device. Since Windows > enumerates the devices in a way, I haven't seen through yet, I can't do > this with netsh. > > Is there an easy way to install the tuntap driver and set up the > interface address with openvpn? > > Or is there another way to reliably get a local connection configured? > (XP and Win2k). > > Is it also possible to automatically configure bridging? See the tun.c code in OpenVPN, look for the #ifdef WIN32 code -- it will show you how OpenVPN sets up the TUN/TAP interface network settings using DeviceIoControl calls to the driver. James 

Hello, I'm using hibernate on my openvpn server (tcp-server) and on every 2 or 3 resumes it crashs. The network icon shows up in the tray and it says getting network adress (in german "Netzwerkadresse beziehen"). If this occurs I can't connect to the server until I restart the OpenVPN-Server. greetings Carsten 

Hi, I'm currently building a Windows installer for a debian/coLinux based embedded toolchain. For internet access I'm using the slirp daemon which is a zero configuration solution and is working great. But for local access I have to use a tap device. My problem is, while I can install the driver without a problem, I have no idea how to configure the network interface. I need to find an unused private subnet and set the IP address of the tap device. Since Windows enumerates the devices in a way, I haven't seen through yet, I can't do this with netsh. Is there an easy way to install the tuntap driver and set up the interface address with openvpn? Or is there another way to reliably get a local connection configured? (XP and Win2k). Is it also possible to automatically configure bridging? Thanks in advance Juergen Hennerich 

On Sat, 24 Sep 2005, Mathias Sundman wrote: > On Sat, 24 Sep 2005, James Yonan wrote: > > > One of the interesting ramifications of this feature, is that it sets the > > stage for non-admin accounts to be able to run OpenVPN directly, without > > using the service wrapper. > > > > With OpenVPN 2.0, this couldn't happen for two reasons: (a) opening the > > TAP-Win32 device object required administrative privileges, and (b) if the > > server pushed routes, the client couldn't add them because adding routes > > on Windows requires privilege. > > > > This new release addresses (a). (b) is still an issue if the server is > > pushing routes. However (b) is less of an issue now since the "topology > > subnet" feature was added, because it allows a tun-based tunnel to operate > > without requiring any mandatory route pushes in order to function. Of > > course, if you are pushing custom routes, or are pushing > > "redirect-gateway" to clients, then those routes cannot be added if the > > user lacks administrative privileges (is there a finer-grained > > privilege that allows route modification without full admin privileges?). > > You're awesome! How did you solve it? Last time it was discussed on the > list I remember there was another way to open the TAP driver but it was a > non supported way and would probably not pass WHQL Driver tests so you > didn't want to use that method. Did you come up with an other solution, or > did you chose this way after all? Well as it goes, trying to solve intractable windows driver problems usually starts with the requisite tearing out of hair, followed by the transmission of a distress signal to microsoft.public.development.device.drivers: http://groups.google.com/group/microsoft.public.development.device.drivers/browse_thread/thread/f5baddd33208d68e/ff903d776234414c That gave me some ideas, such as using the ZwSetSecurityObject call on the device object after it has already been created with admin-only permissions. While the code for this seems reasonable, the ZwSetSecurityObject kernel call is not officially documented in the DDK, though I believe it's documented in another MS toolkit. I think the bottom line is that MS didn't really think this through, and we're going to have to wait until NDIS 6.0 (vista) to get an elegant solution. So while I'm not sure that using ZwSetSecurityObject would pass muster with the WHQL fashion police, my current sense is that it's a stable workaround. > Could we perhaps solve (b) in the TAP driver as well. I mean implement an > interface between userspace and the TAP driver that allows us to tell the > TAP driver to add/delete routes? That's tricky -- I'm sure that kernel space has some kind of API for route manipulation, I'm just not sure that it's documented. > Or do you still think the final solution is to run the whole openvpn > process via a service wrapper? > > The good thing with using the TAP driver also for adding routes is that > openvpn could continue running as a non-admin userspace application and > give us all the benefits of a potential security voulnerability found in > the openvpn code only beeing executed as non-admin. > > Of cource the same thing could be implemented in a seperate service module > only used for route additions and perhaps script execution. Right -- one could have a sort of "route" service. But when you start talking about script execution, then there's going to be a lot of security concerns, and I think you would end up with something that looks more like sudo. > The tricky part of cource would be how to control that only the openvpn > process is able to control the TAP driver or service module so we don't > allow normal users to execute arbitrary code as admin. I think making the TAP device object accessible from non-admin is reasonable from a security perspective. In fact, would argue that it actually improves security, in the same way that user/group nobody on *nix does. James 

On Sat, 24 Sep 2005, James Yonan wrote: > One of the interesting ramifications of this feature, is that it sets the > stage for non-admin accounts to be able to run OpenVPN directly, without > using the service wrapper. > > With OpenVPN 2.0, this couldn't happen for two reasons: (a) opening the > TAP-Win32 device object required administrative privileges, and (b) if the > server pushed routes, the client couldn't add them because adding routes > on Windows requires privilege. > > This new release addresses (a). (b) is still an issue if the server is > pushing routes. However (b) is less of an issue now since the "topology > subnet" feature was added, because it allows a tun-based tunnel to operate > without requiring any mandatory route pushes in order to function. Of > course, if you are pushing custom routes, or are pushing > "redirect-gateway" to clients, then those routes cannot be added if the > user lacks administrative privileges (is there a finer-grained > privilege that allows route modification without full admin privileges?). You're awesome! How did you solve it? Last time it was discussed on the list I remember there was another way to open the TAP driver but it was a non supported way and would probably not pass WHQL Driver tests so you didn't want to use that method. Did you come up with an other solution, or did you chose this way after all? Could we perhaps solve (b) in the TAP driver as well. I mean implement an interface between userspace and the TAP driver that allows us to tell the TAP driver to add/delete routes? Or do you still think the final solution is to run the whole openvpn process via a service wrapper? The good thing with using the TAP driver also for adding routes is that openvpn could continue running as a non-admin userspace application and give us all the benefits of a potential security voulnerability found in the openvpn code only beeing executed as non-admin. Of cource the same thing could be implemented in a seperate service module only used for route additions and perhaps script execution. The tricky part of cource would be how to control that only the openvpn process is able to control the TAP driver or service module so we don't allow normal users to execute arbitrary code as admin. Cheers - Mathias PS: Testing will come as well as a GUI version installation package! -- _____________________________________________________________ Mathias Sundman (^) ASCII Ribbon Campaign OpenVPN GUI for Windows X NO HTML/RTF in e-mail http://openvpn.se/ / \ NO Word docs in e-mail 

This release is the latest in the topology branch which was first discussed here: http://openvpn.net/archive/openvpn-users/2005-09/msg00079.html Included in the Windows version of this release is a long-sought-after feature: The ability for OpenVPN to open the TAP-Win32 adapter from accounts other than administrator. Two methods of setting non-admin access are provided. The first method is implemented in the TAP-Win32 driver itself. By default, non-admin access is now allowed, however this can be turned off in the adapter advanced properties dialog, or in the OemWin2k.inf file. The second method configures non-admin access from userspace, using the new --allow-nonadmin standalone flag to the openvpn command. This method was more of a proof-of-concept, before I ported the code to the TAP-Win32 driver. I need people to test this new TAP-Win32 driver on as many Windows versions as possible (it is included in the pre-built Windows installer for this release). Of course, you should treat it as an early beta release, and not use it in production yet. I've tested the driver on XP SP2 only, and more testing is needed on Win2K and Server 2003. One of the interesting ramifications of this feature, is that it sets the stage for non-admin accounts to be able to run OpenVPN directly, without using the service wrapper. With OpenVPN 2.0, this couldn't happen for two reasons: (a) opening the TAP-Win32 device object required administrative privileges, and (b) if the server pushed routes, the client couldn't add them because adding routes on Windows requires privilege. This new release addresses (a). (b) is still an issue if the server is pushing routes. However (b) is less of an issue now since the "topology subnet" feature was added, because it allows a tun-based tunnel to operate without requiring any mandatory route pushes in order to function. Of course, if you are pushing custom routes, or are pushing "redirect-gateway" to clients, then those routes cannot be added if the user lacks administrative privileges (is there a finer-grained privilege that allows route modification without full admin privileges?). Testing is quite easy. Simply add this line to your "dev tun" based server config: topology subnet Download: http://openvpn.net/beta/to/ Change Log: 2005.09.23 -- Version 2.0.2-TO4 * Added feature to TAP-Win32 adapter to allow it to be opened from non-administrator mode. This feature is enabled by default, and can be enabled/disabled in the adapter advanced properties dialog. * Added --allow-nonadmin standalone option for Windows to set TAP adapter to allow non-admin access. This is a user-mode version of the code, and duplicates the same feature as the above entry. * Added fix that attempts to solve corner case of tunnel not forwarding packets when system clock is reset to an earlier time. * Added --redirect-gateway bypass-dns option. (Developers: To add bypass-dhcp or bypass-dns support to other OSes, add a get_bypass_addresses function to route.c for your OS.) * Added OPENVPN_PLUGIN_CLIENT_CONNECT_V2 plugin callback, which allows a client-connect plugin to return configuration text in memory, rather than via a file. * Fixed a bug where --mode server --proto tcp-server --cipher none operation could cause tunnel packet truncation. * openvpn --version will show [LZO1] or [LZO2], depending on version that was linked. James 

Hi, I downloaded & installed the tun kernel extension in my Mac 10.4 Build 8A428. Before I assign IP to tun interface ifconfig tun0 as follows tun0: flags=8850<POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1500 closed I ran my application(To open driver handle) & I tried to assign an IP to tun0 interface using ifconfig tun0 172.16.100.28 1.2.3.9 After I assign IP to tun interface ifconfig tun0 tun0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet 172.16.100.28 --> 1.2.3.9 netmask 0xffff0000 open (pid 253) I expected the assigned IP will allow me to ping. But not allowing me to ping. Is there anything I need enable in the driver to come out of this problem. Is there anything I missed out please advice me. Also attached netstat -rn & ifconfig dump of Mac 10.4 PC. Regards, Jothi netstat -rn is as follows iMac:~ root# netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 172.16.2.1 UGSc 6 10 en0 1.2.3.9 172.16.100.28 UH 0 0 tun0 127 127.0.0.1 UCS 0 0 lo0 127.0.0.1 127.0.0.1 UH 11 1322 lo0 169.254 link#4 UCS 0 0 en0 172.16 link#4 UCS 4 0 en0 172.16.2.1 0:9:f:30:61:8a UHLW 3 0 en0 1180 172.16.2.104 0:8:a1:45:d6:22 UHLW 0 1 en0 913 172.16.100.20 0:d0:b7:9c:8d:fb UHLW 1 30 en0 982 172.16.100.61 127.0.0.1 UHS 0 0 lo0 172.16.255.255 link#4 UHLWb 4 49 en0 ifconfig is as follows iMac:~ root# ifconfig lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280 stf0: flags=0<> mtu 1280 en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet6 fe80::211:24ff:fecd:4f3c%en0 prefixlen 64 scopeid 0x4 inet 172.16.100.61 netmask 0xffff0000 broadcast 172.16.255.255 ether 00:11:24:cd:4f:3c media: autoselect (100baseTX <full-duplex>) status: active supported media: none autoselect 10baseT/UTP <half-duplex> 10baseT/UTP <full-duplex> 10baseT/UTP <full-duplex,hw-loopback> 100baseTX <half-duplex> 100baseTX <full-duplex> 100baseTX <full-duplex,hw-loopback> 1000baseT <full-duplex> 1000baseT <full-duplex,hw-loopback> 1000baseT <full-duplex,flow-control> 1000baseT <full-duplex,flow-control,hw-loopback> en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether 00:11:24:c0:4d:04 media: autoselect (<unknown type>) status: inactive supported media: autoselect fw0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 4078 lladdr 00:11:24:ff:fe:cd:4f:3c media: autoselect <full-duplex> status: inactive supported media: autoselect <full-duplex> tun0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet 172.16.100.28 --> 1.2.3.9 netmask 0xffff0000 open (pid 253) tun1: flags=8850<POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1500 closed 

Mathias Sundman wrote: > As promised in the thread "use pkcs12 certificates or not" on openvpn-users list, here is a patch that enables the use of --ca together with --pkcs12. Thanks! Now I can also make use the PKC#12 feature :) Best Regards, Alon Bar-Lev. 

As promised in the thread "use pkcs12 certificates or not" on openvpn-users list, here is a patch that enables the use of --ca together with --pkcs12. If --ca is used at the same time as --pkcs12 the CA certificate is loaded from the file specified by --ca regardless if the pkcs12 file contain a CA cert or not. Tested on windows with both a seperate CA file and with the CA file bundled in the pkcs12 archive. The patch is also available here: http://openvpn.se/files/patches/openvpn-2.0.2-pkcs12_seperate_ca.patch -- _____________________________________________________________ Mathias Sundman (^) ASCII Ribbon Campaign OpenVPN GUI for Windows X NO HTML/RTF in e-mail http://openvpn.se/ / \ NO Word docs in e-mail

James Yonan wrote: > Something that would integrate as a section in the current 2.0 HOWTO, such as "How to add dual-factor authentication to an OpenVPN > configuration using client-side smartcards". Updated. http://sourceforge.net/tracker/index.php?func=detail&aid=1293066&group_id=48 978&atid=454721 I hope you see the new version is on the right direction... Best Regards, Alon Bar-Lev. 

On Sun, 18 Sep 2005, Alon Bar-Lev wrote: > Update: > > The patch was tested on Windows (Base, no GUI). > > HOWTO was written, can be found on: > > http://sourceforge.net/tracker/index.php?func=detail&aid=1293066&group_id=48978&atid=454721 > > Please feel free to correct my English. Thanks, though I was thinking about a document which would contain a full sequence of steps for taking a sample OpenVPN configuration and turning it into a dual-factor setup, using a smartcard. Something that would integrate as a section in the current 2.0 HOWTO, such as "How to add dual-factor authentication to an OpenVPN configuration using client-side smartcards". It would answer questions such as: (1) some discussion about why the smart-cards improve security (2) which smart-card products are PKCS11-compatible or links to the same (3) system requirements, such as minimum version of OpenSSL (4) how to configure the cards (5) how to modify OpenVPN client and/or server configuration to make use of the cards (6) While this goes beyond the PKCS11 discussion, some people are going to be interested/confused by the differences between the PKCS11 functionality you've added and the existing Windows Crypto API support, as a means for using smartcards with OpenVPN. > I am waiting for reply regarding your request to merge external include > files into root. I think it's reasonable to keep the external include files in their own directory if you think it makes the source file organization cleaner. Just make sure that it doesn't break anything, such as "make dist" to build tarballs, and the Windows build environment. James