[Openvpn-devel] incomplete system routing table
Hi,
on a Windows 2000 system, I'm facing troubles with setting the default
gateway. The problem is that openvpn reports only two routing table
entries in its log file:
SYSTEM ROUTING TABLE
127.0.0.0 255.0.0.0 127.0.0.1 p=0 i=1 t=0 pr=2 a=0 h=0 m=1/1/1/1/1
127.0.0.1 255.255.255.255 127.0.0.1 p=0 i=1 t=0 pr=2 a=0 h=0 m=1/1/1/1/1
SYSTEM ADAPTER LIST
TAP-Win32 Adapter V8
Index = 2
GUID = {62B7CB49-88A5-43EB-B7ED-63647CCE3A20}
IP = XXX.XXX.XXX.36/255.255.255.0
MAC = 00:ff:62:b7:cb:49
GATEWAY =
DHCP SERV = XXX.XXX.XXX.3
DHCP LEASE OBTAINED = Sun Sep 12 21:14:10 2004
DHCP LEASE EXPIRES = Sun Sep 12 22:14:10 2004
Realtek RTL8139/810x Family Fast Ethernet NIC
Index = 16777220
GUID = {890D661C-E523-41A5-969A-C88B9A8467AA}
IP = 192.168.0.100/255.255.255.0
MAC = 00:e0:7d:8c:df:0f
GATEWAY = 192.168.0.1/0.0.0.0
DHCP SERV = 192.168.0.1
DHCP LEASE OBTAINED = Sun Sep 12 21:11:59 2004
DHCP LEASE EXPIRES = Sun Sep 12 21:21:59 2004
"route print" gives me this list:
0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.100
127.0.0.0255.0.0.0127.0.0.1 127.0.0.1
192.168.0.0255.255.255.0192.168.0.100 192.168.0.100
192.168.0.100 255.255.255.255127.0.0.1 127.0.0.1
192.168.0.255 255.255.255.255192.168.0.100 192.168.0.100
224.0.0.0224.0.0.0192.168.0.100 192.168.0.100
255.255.255.255 255.255.255.255192.168.0.100 2
default gateway: 192.168.0.1
I also tried the route_method switch, but then I discovered that this
only applies to add/delete operations. Is GetIpForwardTable() also known
to make troubles? Are there alternative ways to obtain the routing
entries - beside parsing the "route print" output?
Jan
smime.p7s
Description: S/MIME Cryptographic Signature
[Openvpn-devel] Re: Interface with GUI agent
James Yonan wrote: I'm not sure that we really need a wrapper for unix, because most unix users will control OpenVPN by: (1) editing config files and starting from /etc/init.d, or (2) using some sort of GUI-based admin tool such as YaST and both of these methods are traditionally done as root. You consider the typical openvpn user in a client scenario under unix as a command line freak - might be still true for the moment, but certainly not in the future. An increasing number of gui-oriented users are switching over to unix, in particular linux. And what would be better for a smooth switch-over than finding a similar gui on both platforms? Command line freaks already have anything the need with what openvpn now provides, so this is not the audience we should target. ... Yes, this will work. But I'm afraid - maybe I'm wrong - that the GUI will then have to be implemented quite differently on Windows and Unix. On Windows, we would open a socket and both send the commands over it and receive the status. On Unix, we would first start the process and then connect to a socket for status information (BTW, which socket would then be used when multiple instances of openvpn are running?). Should the unix GUI be written for generic X, or should we develop admin modules for specific distros such as YaST? I would go for the latter, because it will make the interface fit more seamlessly into a distribution's existing admin infrastructure. I would not think about an admin gui at the moment. Maybe this will never be needed as configuration files are much easier to handle. I'm personally not looking for gui dialogs where I can select and combine graphically any option the openvpn service provides - in case this is the impression you got of my feature request. If SuSE, any other distributor, or projects like webmin are interested in providing some gui for creating the config file, let them do this. But we should first concentrate on an interface for *using* openvpn in daily work! Jan smime.p7s Description: S/MIME Cryptographic Signature
Re: [Openvpn-devel] Re: Interface with GUI agent
Denis Vlasenko wrote: 1. On Windows, if the the service wrapper has started some openvpn processes before our gui agent is started, how should find out about those processes? I can think of the following ways: 1a. Ask the service wrapper via the socket interface that I'm working on right now. This will require the service wrapper not only start the processes, but keep a table over running processes. I think it's an important point worth some discussion on whether to (a) put all the "intelligence" in the GUI applet and have the service wrapper just be a basic proxy to an admin-privileged CreateProcess, or (b) write a portable service wrapper that's designed to run on all the OSes which OpenVPN currently supports, and which would do all the "under-the-hood" work in starting/stopping/managing of different OpenVPN processes, and the GUI applet would do nothing more than export the control interface of the portable service wrapper to a platform-specific, lightweight GUI. (b) already exists. It's daemontools. (Does not exist on NT, though). Daemontools' license is not open enough, but there is a opensource clone at http://smarden.org/runit/. I actually don't see why we should add this external dependency to openvpn or its graphical frontend. The daemontools are just another layer which would just take us half the way to a gui, we would then still need to control the daemontools itself (starting/stopping openvpn via the respective command or grabbing the status from the tools). Basically, the only feature we really need is to start or stop some privileged process, that's all. Coding this into a service wrapper for openvpn takes as much effort as handling something like daemontools itself - both with respect to development time (a few hours up to a day) and to code size. Handling the status information of openvpn is so specific in any way, that daemontools cannot help us here. But hey, I guess you will never need that wrapper anyhow, because its only purpose will be to enable running the gui. There will be likely no impact on the openvpn core itself besides an extended status interface (probably via stdout only). Jan smime.p7s Description: S/MIME Cryptographic Signature
Re: [Openvpn-devel] Re: Interface with GUI agent
Mathias Sundman wrote: ... One more thing to consider... Should we consider a system running this service manager an open system where all locally logged on users is allowed to fully manage openvpn connections, which includes: * Start/Stop openvpn processes As a first step, I think we should allow all users to access this service. Later on, one may consider some authorisation mechanism to access specific configurations. This could be some additional parameter in a config file or some meta config file for the wrapping service. * Create new openvpn configs * delete openvpn configs (Hereby not said that creating/deleting configs should be done via the service manager. I just want to discuss whether a normal user should be able to do this or not) As just said in my reply to an earlier mail, I don't think that modifying the configurations shall become part of the gui. This would be feature overloading, especially on a unix system where you typically configure using a text editor. Jan smime.p7s Description: S/MIME Cryptographic Signature
[Openvpn-devel] Re: Interface with GUI agent
Mathias Sundman wrote: On Tue, 6 Jul 2004, Jan Kiszka wrote: James Yonan wrote: ... If it's not a windows specific problem, then I suppost it's best to add the functionallity in the openvpn binary so we get the portability. I don't think the openvpn binary needs to know about this. But the service wrapper probably needs a second mode of operation, where instead of getting its config files by scanning a directory, it listens on a local socket for a command from the GUI to start an openvpn.exe instance. Then don't forget that we will need a similar wrapper for unix as well... Why do we need a wrapper in unix? Can't the openvpn binary be run as a normal user in unix? If we need root-privs, what's wrong with installing openvpn as suid root and have it drop its privs after start-up? Yes, this will work. But I'm afraid - maybe I'm wrong - that the GUI will then have to be implemented quite differently on Windows and Unix. On Windows, we would open a socket and both send the commands over it and receive the status. On Unix, we would first start the process and then connect to a socket for status information (BTW, which socket would then be used when multiple instances of openvpn are running?). We still need the management interface in openvpn though for all platforms so we can check the status of the connection from a gui, but that's another issue. Don't think so. We should first find a concept for both topics so that we can be sure that nothing interfers later. Jan smime.p7s Description: S/MIME Cryptographic Signature
[Openvpn-devel] Re: Interface with GUI agent
James Yonan wrote: ... If it's not a windows specific problem, then I suppost it's best to add the functionallity in the openvpn binary so we get the portability. I don't think the openvpn binary needs to know about this. But the service wrapper probably needs a second mode of operation, where instead of getting its config files by scanning a directory, it listens on a local socket for a command from the GUI to start an openvpn.exe instance. Then don't forget that we will need a similar wrapper for unix as well... Jan smime.p7s Description: S/MIME Cryptographic Signature
Re: Interface with GUI agent, was: Re: [Openvpn-devel] [Patch] revoke scripts were broken
James Yonan wrote: ... Possible client -> server commands: (1) send auth credentials (2) get status (as in SIGUSR2) (3) send signal (SIGHUP, SIGUSR1, or SIGUSR2, SIGTERM) And server -> client commands: (1) need auth credentials -- GUI should query the user then return them to the daemon via a "send auth credentials" command The basic mechanism of operation to enable the management interface would be to pass an option like this in the config file: management 127.0.0.1 20001 I would like to have some mechanism to fork an openvpn instance and let the new process use a specific configuration file. This would allow to start only certain VPN tunnels depending on what the user selects in the GUI. Jan smime.p7s Description: S/MIME Cryptographic Signature
Re: Interface with GUI agent, was: Re: [Openvpn-devel] [Patch] revoke scripts were broken
Denis Vlasenko wrote: On Saturday 03 July 2004 23:01, James Yonan wrote: management 127.0.0.1 20001 This will cause OpenVPN to listen on 127.0.0.1:20001 as its management interface port. It's important, of course, that the management port always be local, since we are using it to potentially pass passwords and other sensitive data that should never actually touch a real network interface. Thinking ahead, the challenge/response sequence for passing authentication info should be open-ended to provide for future implementation of alternative authentication methods such as Radius, LDAP, NT Auth, etc. Please don't do too much of that. I've seen this auth featuritis creeping in ntp and ups tools(!). Results ain't pretty... Reconfiguration of openvpn can always be done by editing config file and restarting openvpn daemon. Simple. Elegant. No additional coding - no risk of introducing bugs. This can be done via systray app, too. I can understand your concerns, and mostly you are right. However, there is one quite important scenario - at least as I see it - where you need the core daemon and the GUI running in different accounts: whenever the key or secret has to be looked away from the user while it shall still be possible for her/him to start/stop VPN connections. One reason for this may be that the key is bound to the device and not the user. The other one is security. Through this separation, malicious programs running in the context of the user can not so easily access the secret. And for those who don't trust this new interface (which will surely need a careful implementation): what about adding a configure switch and putting the respective code in some #ifdefs? Jan smime.p7s Description: S/MIME Cryptographic Signature
Re: Interface with GUI agent, was: Re: [Openvpn-devel] [Patch] revoke scripts were broken
Mathias Sundman wrote: ... No, I'm not used to OO languages, unfortunally. The reasons why I started to write this in C was: 1) I only know how to code in C, VisualBasic and Assembler. Assembler is out of the question, and I'm tired of VBs dependency for a bunch of DLLs. I like beeing able to compile just one compact exe file and not need to create an installation package just to get the application working on another machine. Ok, as far as I remember, you need one additional library for wxWindows. MFC, on the other hand, already comes with Windows. The binaries of both approaches will be very compact, while you may create larger programs when hacking all the standard work (messsage processing etc.) on your own. 2) The egoistic one! I've though of learning to develop windows gui applications in C for a long time, but never really got to it. Now I saw an opportunity to write something useful and learn something I've wanted to learn at the same time. 3) OpenVPN is written in traditional C, so if I for any reason would like to integrate the gui into the openvpn binary, that would be very easy if the gui itself was written in C. I personally think that using different languages for different tasks in a project should be no problem, especially as C++ fits better to GUI modules. But I'm not the project manager :). 4) I like traditional C, and dislike object oriented languages! Don't ask me why, it's just my personal taste, and I can fully understand that other prefer OO languages... I'm also hacking most of my software in C - because it's kernel code or command line tools. But for GUI stuff, OO is definitely better suited and more efficient (due to re-use of components). I do agree with you though that makeing it portable would have been prefered, but just like you, I don't got that much spare time, so I'm not sure that I want to spend it learning yet another development environment. Before discouraging you from doing anything at all, I would suggest that you start with a basic GUI tool (and feel a bit of the effort ;) ). If the interface to the OpenVPN core is specified and stable, extending the GUI capabilities can be done later as well - if required. Jan smime.p7s Description: S/MIME Cryptographic Signature
Re: [Openvpn-devel] [Patch] revoke scripts were broken
Mathias Sundman wrote: On Tue, 29 Jun 2004, Jan Kiszka wrote: PS: Has anyone ever thought about some small GUI (taskbar icon with some dialogs) for Windows, KDE, etc. to make the handling of multiple configurations and the status display easier in a roadwarrior scenario? Just a thought, I'm not saying I have the time for doing it - unfortunately. [If you reply, please add a CC, I'm not on the list] I just started working on such an application last night. I'm kinda new to C programming in Windows so I ran into a little annoying problem right away though! I don't want to bother this list with basic C programming issues though, but if someone is used to classic C programming and message handeling in windows, please contact me offlist if you got a spare minute. A pointer to a good mailing-list for discussion about classic C programming in windows would be appreciated too. While considering a similar interface for some other project, I once took a closer look at wxWindows (http://www.wxwindows.org). Before you start hacking your own message handling routines in C or switching over to the Windows-only MFC library, this project may be worth some thoughts because A) it capsulates most of the annoying GUI work, and B) it opens to possiblity to port your work later to Linux as well! I think not only Windows users would appreciate a simple management interface for OpenVPN clients very much... The only problem so far: You have to consider writing your program object-oriented, i.e. in C++. Did you ever worked with some OO languages (Java e.g.)? I would furthermore suggest to discuss the required interface between the GUI and the OpenVPN daemon on this list. Starting and stopping would be possibly by just running the main binary, but I think a more sophisticated status and diagnosis interface requires some other mechanism (e.g. a local socket). Such an interface could furthermore prevent that the actual user who switches some configuration or just checks the status must own superuser privileges to start/stop a OpenVPN service and - even worse - read the secret key files. Comments are welcome! Jan
[Openvpn-devel] [Patch] revoke scripts were broken
Hi all, here is a tiny patch to make revoke-crt and make-crl work seamlessly within the easy-rsa environment. Seems that no one used it before ;) Jan PS: Has anyone ever thought about some small GUI (taskbar icon with some dialogs) for Windows, KDE, etc. to make the handling of multiple configurations and the status display easier in a roadwarrior scenario? Just a thought, I'm not saying I have the time for doing it - unfortunately. [If you reply, please add a CC, I'm not on the list] diff -Nur /tmp/openvpn-2.0_beta6/easy-rsa/make-crl openvpn-2.0_beta6/easy-rsa/make-crl --- /tmp/openvpn-2.0_beta6/easy-rsa/make-crl2004-06-15 02:01:13.0 +0200 +++ openvpn-2.0_beta6/easy-rsa/make-crl 2004-06-29 16:50:09.836098144 +0200 @@ -12,7 +12,7 @@ if test $KEY_DIR; then cd $KEY_DIR && \ - openssl ca -gencrl -out $1 + openssl ca -gencrl -out $1 -config $KEY_CONFIG else echo you must define KEY_DIR fi diff -Nur /tmp/openvpn-2.0_beta6/easy-rsa/revoke-crt openvpn-2.0_beta6/easy-rsa/revoke-crt --- /tmp/openvpn-2.0_beta6/easy-rsa/revoke-crt 2004-06-15 02:01:13.0 +0200 +++ openvpn-2.0_beta6/easy-rsa/revoke-crt 2004-06-29 16:50:21.703294056 +0200 @@ -12,7 +12,7 @@ if test $KEY_DIR; then cd $KEY_DIR && \ - openssl ca -revoke $1 + openssl ca -revoke $1 -config $KEY_CONFIG else echo you must define KEY_DIR fi
