Re: [network-manager-openvpn] Problem adding vpn file from my provider FrootVPN.
On Thu, Oct 27, 2016 at 08:15:20PM +0200, Vicente Herrera Cobo wrote: > Regards to all, > > by adding a specified ovpn file from my provider get the following > error: "Error: configuration error: unsupported blob/xml element (line > 104)." > > Line 104: "" Hi, at the moment the openvpn plugin doesn't support profiles. I've filed a bug [1] to track this issue and hopefully it will be implemented soon (patches are always welcome!). Beniamino [1] https://bugzilla.gnome.org/show_bug.cgi?id=773623 signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: network-manager-openvpn
On Wed, 2009-12-16 at 14:33 -0500, Matt Wilks wrote: > > On Wed, 2009-12-16 at 12:43 PM, Dan Williams wrote: > >> On Tue, 2009-12-15 at 11:08 -0500, Matt Wilks wrote: > >> What prompted my initial query was the lack of support for, > >> and directives (supported in OpenVPN since 2.1-beta7, Nov > >> 2005). They allow you to specify the key files directly in the > >> configuration file, making it a self-contained configuration for a > >> connection using keys to authenticate. NetworkManager also seemed to > >> miss the fact that my config required both keys and a password; not > >> hard to manually set but it wasn't caught by the import. > > > > I do believe those have been in the NM openvpn configuration for a > > long time. What specific version of NM-openvpn are you using? I'm > > certainly using a CA certificate right now to write this mail. If you > > pick "Certificates (TLS)" or "Passwords with Certificates" from the > > dropdown you should be able to use the certificates and keys of your > > choice. This has been the case for at least a year and a half, since > > before NM 0.7.x was released. > > Keys are supported, but you have to specify them in the NetworkManager > config through a file browser dialog. The , etc directives I'm > talking about go in the config file and you include the actual text of > the key, something like: > > > -BEGIN CERTIFICATE- > asdlgkyladkhajf;lkawur;iolw789uafjdslkafjsd;fkj > dflkajsdlfkaylkxcjfasmjelasjruklasfdjflkasdjrlk > fasdlfka;wo347;afalk4nasdlfksaydlkaihf3a94rsldj > -END CERTIFICATE- > > > and so on with and . I have NM (and NM-openvpn) version 0.8 > on Ubuntu Karmic and it didn't work for me. Aha, yes that is not yet supported; it wouldn't be too hard to grab the data out of there and stuff it into its own file in ~/.pki or such; you don't really want to be storing certificate data in GConf or elsewhere. In the end, we need a certificate store like Windows or Mac OS X has, but for now we'll need to use files I guess. One caveat is to ensure that the user's private key is written out in encrypted form if it's not already encrypted in the config. Dan > > The whitelisting is for security. As a user, if you download a > > configuration file and want to use it, what's to say it doesn't include > > some options that make things less-secure or are malicious? Depending > > on the plugin you could send a config option for "run this script after > > connection" and since the VPN plugins currently run as root, that script > > gets run as root. The configuration data cannot /necessarily/ be > > trusted especially if it comes from the user session. At the same time, > > you don't want to /necessarily/ lock users out completely (that's the > > discretion of the sysadmin if there is one). > > Ah, this security concern settles it for me. The reason that other > clients can offer the config file management paradigm is that you must > have admin privileges to run the program in the first place. Not so > with NM. > > Thanks again for your time. Much appreciated. > ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: network-manager-openvpn
On Wed, 2009-12-16 at 12:43 PM, Dan Williams wrote: On Tue, 2009-12-15 at 11:08 -0500, Matt Wilks wrote: What prompted my initial query was the lack of support for, and directives (supported in OpenVPN since 2.1-beta7, Nov 2005). They allow you to specify the key files directly in the configuration file, making it a self-contained configuration for a connection using keys to authenticate. NetworkManager also seemed to miss the fact that my config required both keys and a password; not hard to manually set but it wasn't caught by the import. I do believe those have been in the NM openvpn configuration for a long time. What specific version of NM-openvpn are you using? I'm certainly using a CA certificate right now to write this mail. If you pick "Certificates (TLS)" or "Passwords with Certificates" from the dropdown you should be able to use the certificates and keys of your choice. This has been the case for at least a year and a half, since before NM 0.7.x was released. Keys are supported, but you have to specify them in the NetworkManager config through a file browser dialog. The , etc directives I'm talking about go in the config file and you include the actual text of the key, something like: -BEGIN CERTIFICATE- asdlgkyladkhajf;lkawur;iolw789uafjdslkafjsd;fkj dflkajsdlfkaylkxcjfasmjelasjruklasfdjflkasdjrlk fasdlfka;wo347;afalk4nasdlfksaydlkaihf3a94rsldj -END CERTIFICATE- and so on with and . I have NM (and NM-openvpn) version 0.8 on Ubuntu Karmic and it didn't work for me. The whitelisting is for security. As a user, if you download a configuration file and want to use it, what's to say it doesn't include some options that make things less-secure or are malicious? Depending on the plugin you could send a config option for "run this script after connection" and since the VPN plugins currently run as root, that script gets run as root. The configuration data cannot /necessarily/ be trusted especially if it comes from the user session. At the same time, you don't want to /necessarily/ lock users out completely (that's the discretion of the sysadmin if there is one). Ah, this security concern settles it for me. The reason that other clients can offer the config file management paradigm is that you must have admin privileges to run the program in the first place. Not so with NM. Thanks again for your time. Much appreciated. -- Matt Wilks Colossians 2:6-7 University of TorontoInformation Security, I+TS (416) 978-3328 m...@madhaus.cns.utoronto.ca 4 Bancroft Ave., Rm. 102 Toronto, ON M5S 1C1 ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: network-manager-openvpn
On Tue, 2009-12-15 at 11:08 -0500, Matt Wilks wrote: > On 09-12-14 06:09 PM, Dan Williams wrote: > > On Mon, 2009-12-14 at 09:24 -0500, Matt Wilks wrote: > >> This must have been discussed before on this list, but I'm curious the > >> reasoning behind making network-manager-openvpn have its own GUI for > >> configuration in the first place. Why not offer functionality similar > >> to the Windows/Mac clients that simply manage your connections via > >> configuration files? You'd get all the flexibility of OpenVPN with none > >> of the overhead of constantly having to write patches to support / > >> debate the inclusion of individual options. > > > > For a number of reasons; > > Thanks for your response Dan, I appreciate you taking the time to do so. > Allow me to make a few comments. > > > 1) not everyone wants to use configuration files, > > 2) not everyone is aware of (or cares about) the intricacies of > > configuration options, some cannot be used with others, some require > > others to be turned on, > > Granted. However, I would think that anyone who is attempting to > connect to a work/school VPN is more likely to have a configuration file > handed to them then a set of OpenVPN parameters. That is how we do it > with the VPN I am responsible for. Again, the config file can be imported into NM, so the process you have still works exactly the same way. > > 3) GUI interfaces are often more approachable and do not preclude > > advanced users from using config files anyway, and > > I think you are making an incorrect distinction here between advanced > and beginner users. Using a config file does not necessarily mean that > a user is advanced. In our case, we distribute a config file precisely > because so many of our users are not advanced and we don't want them > having to fiddle around with options on various clients. > > > 4) handling random config files is often problematic, > > I'm not sure I understand why. Using the model of OpenVPN-GUI or > Tunnelblick (Windows and Mac GUIs respectively) however, you would just > have NetworkManager monitor a directory for config files. Could be a > directory in the user's home (ala Tunnelblick) or a system directory > (ala OpenVPN-GUI). Even if the user were able to specify arbitrary > configuration file locations, how is this any more problematic then the > dialogs to specify the ca, key and user cert that currently exist in the > NetworkManager GUI? 1) The config file is stored separately from the rest of the configuration data like IP address, routing information, DNS, etc. If it's not available (user downloads it into ~/Downloads and then it gets deleted when FF quits) then it's no longer available 2) root daemons accessing files in users' directories is often not allowed by security software like SELinux or AppArmor, for good reason; it's really hard to contain a binary and limit the attack points when you have to allow the binary to read from all over the hard drive 3) it's a security risk on daemons that require a password in the config file when not using stdin (ex vpnc) 4) using a config file can create temporary files that require cleanup which doesn't always get done; if we do need to substitute certain values (like we do with dhclient) then we need to create a temporary config file that has to be cleaned up after the transaction is complete, which is more housekeeping and more trouble. > > 5) it wasnt' integrated into the consistent NetworkManager > > configuration system. > > I have to admit ignorance about the standards for configuring > NetworkManager, but I imagine that they say something about storing > configuration internally rather than referencing external files? http://live.gnome.org/NetworkManagerConfiguration The NM configuration system actually produces an abstraction over various distro and desktop-specific configuration systems so taht you can use your preferred configuration system. For example, GConf, KConfig, /etc/network/interfaces, keyfiles, ifcfg files, etc, all are transformed into a standard format that clients can read and handle. That allows you, from a client, to actually figure out what's going on in a standard way instead of having to code logic for each and every configuration system. NM doesn't store config /internally/, but the user-settings and system-settings services do use configuration systems like GConf or system config files that you might consider to store the config "internally", at least in a different format than the native config file for openvpn. That has some benefits; as the admin you can use tools, behaviors, processes, and knowledge that you already have for your distro's native configuration file format. You can lock configuration down using GConf or keep your scripts for fixing up /e/n/i or ifcfg files. That sort of thing. If it's just a random config file from a random daemon, you need to start creating custom rules for a lot of the stuff that you might want to do while
Re: network-manager-openvpn
On 09-12-14 06:09 PM, Dan Williams wrote: On Mon, 2009-12-14 at 09:24 -0500, Matt Wilks wrote: This must have been discussed before on this list, but I'm curious the reasoning behind making network-manager-openvpn have its own GUI for configuration in the first place. Why not offer functionality similar to the Windows/Mac clients that simply manage your connections via configuration files? You'd get all the flexibility of OpenVPN with none of the overhead of constantly having to write patches to support / debate the inclusion of individual options. For a number of reasons; Thanks for your response Dan, I appreciate you taking the time to do so. Allow me to make a few comments. 1) not everyone wants to use configuration files, 2) not everyone is aware of (or cares about) the intricacies of configuration options, some cannot be used with others, some require others to be turned on, Granted. However, I would think that anyone who is attempting to connect to a work/school VPN is more likely to have a configuration file handed to them then a set of OpenVPN parameters. That is how we do it with the VPN I am responsible for. 3) GUI interfaces are often more approachable and do not preclude advanced users from using config files anyway, and I think you are making an incorrect distinction here between advanced and beginner users. Using a config file does not necessarily mean that a user is advanced. In our case, we distribute a config file precisely because so many of our users are not advanced and we don't want them having to fiddle around with options on various clients. 4) handling random config files is often problematic, I'm not sure I understand why. Using the model of OpenVPN-GUI or Tunnelblick (Windows and Mac GUIs respectively) however, you would just have NetworkManager monitor a directory for config files. Could be a directory in the user's home (ala Tunnelblick) or a system directory (ala OpenVPN-GUI). Even if the user were able to specify arbitrary configuration file locations, how is this any more problematic then the dialogs to specify the ca, key and user cert that currently exist in the NetworkManager GUI? 5) it wasnt' integrated into the consistent NetworkManager configuration system. I have to admit ignorance about the standards for configuring NetworkManager, but I imagine that they say something about storing configuration internally rather than referencing external files? Now that we have good import/export capability for openvpn, it's not actually that hard to use your own configs. If there's options that people use, we can also whitelist them and add them to import/export even if they aren't shown in the GUI. What prompted my initial query was the lack of support for , and directives (supported in OpenVPN since 2.1-beta7, Nov 2005). They allow you to specify the key files directly in the configuration file, making it a self-contained configuration for a connection using keys to authenticate. NetworkManager also seemed to miss the fact that my config required both keys and a password; not hard to manually set but it wasn't caught by the import. Just because there's a GUI doesn't preclude you from writing a config file and importing it of course. That's true, and apart from the missing config I mentioned above, I found it to be a relatively painless process. Kudos! However I don't see how this benefits the NetworkManager developers. Writing a plugin that used external config files would be a one-time job. As it stands now, each new option must be whitelisted and incorporated into the plugin. Again, thanks for taking the time to respond. Much appreciated. -- Matt Wilks Colossians 2:6-7 University of TorontoInformation Security, I+TS (416) 978-3328 m...@madhaus.cns.utoronto.ca 4 Bancroft Ave., Rm. 102 Toronto, ON M5S 1C1 ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: network-manager-openvpn
On Mon, 2009-12-14 at 09:24 -0500, Matt Wilks wrote: > >> Read slowly, im not talking about routes here, talking about all the > >> openvpn parameters that are not yet configurable/importable with the > >> current graphical interface. They could just be configured through or > >> imported into a single listbox as described above. > > > > But that's *horrible* UI and not something I'd like to condone. I'd > > rather add the options on an as-needed basis to ensure we don't just > > dump everything in, and find out that we overloaded the UI with 50 > > options that almost nobody uses. Which I suspect is true for at least > > half of openvpn's options, because they did absolutely no work in > > consolidating them and asking the people who requested the options > > what they were actually trying to accomplish to constrain the number > > of switches that openvpn supports. I'm interested in making it work > > for 90 - 95% of use-cases, but I don't think we should be designing > > for that last 5%, especially when it makes things nearly unusable for > > the other 90. > > This must have been discussed before on this list, but I'm curious the > reasoning behind making network-manager-openvpn have its own GUI for > configuration in the first place. Why not offer functionality similar > to the Windows/Mac clients that simply manage your connections via > configuration files? You'd get all the flexibility of OpenVPN with none > of the overhead of constantly having to write patches to support / > debate the inclusion of individual options. For a number of reasons; 1) not everyone wants to use configuration files, 2) not everyone is aware of (or cares about) the intricacies of configuration options, some cannot be used with others, some require others to be turned on, 3) GUI interfaces are often more approachable and do not preclude advanced users from using config files anyway, and 4) handling random config files is often problematic, and 5) it wasnt' integrated into the consistent NetworkManager configuration system. Now that we have good import/export capability for openvpn, it's not actually that hard to use your own configs. If there's options that people use, we can also whitelist them and add them to import/export even if they aren't shown in the GUI. Just because there's a GUI doesn't preclude you from writing a config file and importing it of course. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: network-manager-openvpn
Read slowly, im not talking about routes here, talking about all the openvpn parameters that are not yet configurable/importable with the current graphical interface. They could just be configured through or imported into a single listbox as described above. But that's *horrible* UI and not something I'd like to condone. I'd rather add the options on an as-needed basis to ensure we don't just dump everything in, and find out that we overloaded the UI with 50 options that almost nobody uses. Which I suspect is true for at least half of openvpn's options, because they did absolutely no work in consolidating them and asking the people who requested the options what they were actually trying to accomplish to constrain the number of switches that openvpn supports. I'm interested in making it work for 90 - 95% of use-cases, but I don't think we should be designing for that last 5%, especially when it makes things nearly unusable for the other 90. This must have been discussed before on this list, but I'm curious the reasoning behind making network-manager-openvpn have its own GUI for configuration in the first place. Why not offer functionality similar to the Windows/Mac clients that simply manage your connections via configuration files? You'd get all the flexibility of OpenVPN with none of the overhead of constantly having to write patches to support / debate the inclusion of individual options. Matt ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: network-manager-openvpn
On Wed, 2009-09-23 at 15:49 +0200, Luc Deschenaux wrote: > Le mardi 22 septembre 2009 à 23:09 -0700, Dan Williams a écrit : > > On Fri, 2009-09-11 at 04:27 +0200, Luc Deschenaux wrote: > > > > > 1. It should be possible to activate simutaneously many openvpn > > > > > configurations using checkboxes instead of radiobuttons, (in server > > > > > mode > > > > > also, say in a second time...). > > > > > > > > Yes, this is something that's been on the map for a while but there was > > > > other stuff that we considered more important. It will take some rework > > > > internally in NetworkManager, though NM 0.7 already has half the work > > > > done. > > > > > > > > > 2. It should be possible to "import" any openvpn configuration file, > > > > > eg: > > > > > > > > The 0.7 openvpn plugin should already be able to import an openvpn > > > > connection, but I think we just never got around to implementing export. > > > > > > Every configuration parameter should be importable/modifiable, not only > > > the ones used in a given configuration. > > > > > > > What specific configuration were you having problems with? Can you > > > > attach that config so we can see what's going on with it? > > > > > > My config was attached :) But someone may need to use other parameters > > > as well. > > > > > > > > * Options not modifiable actually by network-manager-openvpn should > > > > > also > > > > > be gathered and displayed, eg: in a dynamic listbox like for the > > > > > routes, > > > > > with an add button. There could be a pop-up in the first column to set > > > > > or change the option name, an editable field in the second column to > > > > > set > > > > > or change its value. > > > > > > > > > > > 0.7 already provides the ability to specify custom routes to apply to > > > > the connection in addition to any routes sent by the server. > > > > > > > > > > Read slowly, im not talking about routes here, talking about all the > > > openvpn parameters that are not yet configurable/importable with the > > > current graphical interface. They could just be configured through or > > > imported into a single listbox as described above. > > > > But that's *horrible* UI and not something I'd like to condone. I'd > > rather add the options on an as-needed basis to ensure we don't just > > dump everything in, and find out that we overloaded the UI with 50 > > options that almost nobody uses. Which I suspect is true for at least > > half of openvpn's options, because they did absolutely no work in > > consolidating them and asking the people who requested the options what > > they were actually trying to accomplish to constrain the number of > > switches that openvpn supports. I'm interested in making it work for 90 > > - 95% of use-cases, but I don't think we should be designing for that > > last 5%, especially when it makes things nearly unusable for the other > > 90. > > > > Dan > > Your judgment is totally subjective. What I did suggest is not more > horrible than the UI to define routes actually, did you read > thoroughly ?... Routes is a specific, targeted property that can be done much better than I've done it. But trying to put all the available openvpn options into a table like that isn't, and I think we can do better that that. We don't *have* to support all the options. We just have to support the options that most people use. > I suggest a listbox in a another panel (like the routes panel) with an > popup or a text field to specify which option to set in the first > column , and a second column to set the value. If you've got some time to mock it up or prototype, I'm quite happy to be proved wrong as an addition piece or external utility. I've run into quite a few UIs like that in various products (mostly Microsoft IIS/DHCP/Exchange though) and I have to say, they didn't work well there. I have no doubt you could probably do better than IIS 6 though. > Maybe you and your extended "me" (people you know of) will never add any > other options in this listobx, but i doesnt mean nobody will. > > Concerning usability, it doesnt makes things nearly unusable for the > other 90 you know of, since they actually dont need to use any other > parameters. More, to display the listbox the user would need to press a > button, like for adding routes. > > Concerning current usability, theres no way to specify missing openvpn > options people may need. What options? Again, I'm happy to find out the options that most people use and add those options on an as-needed basis. I've always been willing to do that, provided I have the time to do so. If I don't have the time to do so, I'm quite happy to suggest what should be done to get that option added. For example: https://bugzilla.redhat.com/show_bug.cgi?id=490971 I still don't understand why openvpn can't figure out the renegotiation interval *by itself*, but that's an example. I didn't have time to do the work, but I told Huzaifa what needed to be do
Re: network-manager-openvpn
Le mardi 22 septembre 2009 à 23:09 -0700, Dan Williams a écrit : > On Fri, 2009-09-11 at 04:27 +0200, Luc Deschenaux wrote: > > > > 1. It should be possible to activate simutaneously many openvpn > > > > configurations using checkboxes instead of radiobuttons, (in server mode > > > > also, say in a second time...). > > > > > > Yes, this is something that's been on the map for a while but there was > > > other stuff that we considered more important. It will take some rework > > > internally in NetworkManager, though NM 0.7 already has half the work > > > done. > > > > > > > 2. It should be possible to "import" any openvpn configuration file, eg: > > > > > > The 0.7 openvpn plugin should already be able to import an openvpn > > > connection, but I think we just never got around to implementing export. > > > > Every configuration parameter should be importable/modifiable, not only > > the ones used in a given configuration. > > > > > What specific configuration were you having problems with? Can you > > > attach that config so we can see what's going on with it? > > > > My config was attached :) But someone may need to use other parameters > > as well. > > > > > > * Options not modifiable actually by network-manager-openvpn should also > > > > be gathered and displayed, eg: in a dynamic listbox like for the routes, > > > > with an add button. There could be a pop-up in the first column to set > > > > or change the option name, an editable field in the second column to set > > > > or change its value. > > > > > > > > 0.7 already provides the ability to specify custom routes to apply to > > > the connection in addition to any routes sent by the server. > > > > > > > Read slowly, im not talking about routes here, talking about all the > > openvpn parameters that are not yet configurable/importable with the > > current graphical interface. They could just be configured through or > > imported into a single listbox as described above. > > But that's *horrible* UI and not something I'd like to condone. I'd > rather add the options on an as-needed basis to ensure we don't just > dump everything in, and find out that we overloaded the UI with 50 > options that almost nobody uses. Which I suspect is true for at least > half of openvpn's options, because they did absolutely no work in > consolidating them and asking the people who requested the options what > they were actually trying to accomplish to constrain the number of > switches that openvpn supports. I'm interested in making it work for 90 > - 95% of use-cases, but I don't think we should be designing for that > last 5%, especially when it makes things nearly unusable for the other > 90. > > Dan Your judgment is totally subjective. What I did suggest is not more horrible than the UI to define routes actually, did you read thoroughly ?... I suggest a listbox in a another panel (like the routes panel) with an popup or a text field to specify which option to set in the first column , and a second column to set the value. Maybe you and your extended "me" (people you know of) will never add any other options in this listobx, but i doesnt mean nobody will. Concerning usability, it doesnt makes things nearly unusable for the other 90 you know of, since they actually dont need to use any other parameters. More, to display the listbox the user would need to press a button, like for adding routes. Concerning current usability, theres no way to specify missing openvpn options people may need. Objectively we cannot call it "openvpn GUI", but rather an uncomplete version of an openvpn GUI. It is like a ftp, pop3 or http client that doesnt implement the full protocol. The only difference is that there is no alternative choice for an openvpn GUI integrated to the network manager. Sincerly, L:üC: ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: network-manager-openvpn
On Fri, 2009-09-11 at 04:27 +0200, Luc Deschenaux wrote: > > > 1. It should be possible to activate simutaneously many openvpn > > > configurations using checkboxes instead of radiobuttons, (in server mode > > > also, say in a second time...). > > > > Yes, this is something that's been on the map for a while but there was > > other stuff that we considered more important. It will take some rework > > internally in NetworkManager, though NM 0.7 already has half the work > > done. > > > > > 2. It should be possible to "import" any openvpn configuration file, eg: > > > > The 0.7 openvpn plugin should already be able to import an openvpn > > connection, but I think we just never got around to implementing export. > > Every configuration parameter should be importable/modifiable, not only > the ones used in a given configuration. > > > What specific configuration were you having problems with? Can you > > attach that config so we can see what's going on with it? > > My config was attached :) But someone may need to use other parameters > as well. > > > > * Options not modifiable actually by network-manager-openvpn should also > > > be gathered and displayed, eg: in a dynamic listbox like for the routes, > > > with an add button. There could be a pop-up in the first column to set > > > or change the option name, an editable field in the second column to set > > > or change its value. > > > > > 0.7 already provides the ability to specify custom routes to apply to > > the connection in addition to any routes sent by the server. > > > > Read slowly, im not talking about routes here, talking about all the > openvpn parameters that are not yet configurable/importable with the > current graphical interface. They could just be configured through or > imported into a single listbox as described above. But that's *horrible* UI and not something I'd like to condone. I'd rather add the options on an as-needed basis to ensure we don't just dump everything in, and find out that we overloaded the UI with 50 options that almost nobody uses. Which I suspect is true for at least half of openvpn's options, because they did absolutely no work in consolidating them and asking the people who requested the options what they were actually trying to accomplish to constrain the number of switches that openvpn supports. I'm interested in making it work for 90 - 95% of use-cases, but I don't think we should be designing for that last 5%, especially when it makes things nearly unusable for the other 90. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: network-manager-openvpn
> > 1. It should be possible to activate simutaneously many openvpn > > configurations using checkboxes instead of radiobuttons, (in server mode > > also, say in a second time...). > > Yes, this is something that's been on the map for a while but there was > other stuff that we considered more important. It will take some rework > internally in NetworkManager, though NM 0.7 already has half the work > done. > > > 2. It should be possible to "import" any openvpn configuration file, eg: > > The 0.7 openvpn plugin should already be able to import an openvpn > connection, but I think we just never got around to implementing export. Every configuration parameter should be importable/modifiable, not only the ones used in a given configuration. > What specific configuration were you having problems with? Can you > attach that config so we can see what's going on with it? My config was attached :) But someone may need to use other parameters as well. > > * Options not modifiable actually by network-manager-openvpn should also > > be gathered and displayed, eg: in a dynamic listbox like for the routes, > > with an add button. There could be a pop-up in the first column to set > > or change the option name, an editable field in the second column to set > > or change its value. > > 0.7 already provides the ability to specify custom routes to apply to > the connection in addition to any routes sent by the server. > Read slowly, im not talking about routes here, talking about all the openvpn parameters that are not yet configurable/importable with the current graphical interface. They could just be configured through or imported into a single listbox as described above. Regards, L:üc: ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: network-manager-openvpn
On Mon, 2009-09-07 at 22:24 +0200, Luc Deschenaux wrote: > Le dimanche 06 septembre 2009 à 19:12 +0200, Tim Niemueller a écrit : > > On 06.09.2009 18:27, Luc Deschenaux wrote: > > > Hello ! > > > > Hello Luc. > > Hello everybody ! > > > > Nice try, but you could do better :) > > > > Feel free to send patches. > > I know that patches are always welcome :) > But i dont have the time to make it work like everybody at first glance > will expect it should, ie: allowing to import any valid openvpn > configuration file. > > Let me just send you, instead of a patch, a more serious analysis of > what could make network-manager-openvpn less annoying: > > 1. It should be possible to activate simutaneously many openvpn > configurations using checkboxes instead of radiobuttons, (in server mode > also, say in a second time...). Yes, this is something that's been on the map for a while but there was other stuff that we considered more important. It will take some rework internally in NetworkManager, though NM 0.7 already has half the work done. > 2. It should be possible to "import" any openvpn configuration file, eg: The 0.7 openvpn plugin should already be able to import an openvpn connection, but I think we just never got around to implementing export. What specific configuration were you having problems with? Can you attach that config so we can see what's going on with it? > * Copy the config (as a file or individual parameters in gconf) and > patch it: parse options for actually supported parameters and patch or > add "up", "down", "cd", ... > > (using gconf to store openvpn parameters is much less cool when it's > time to copy the configs directly from disk or to port the application, > but it is ok to store the config location or other external details in > gconf). > > * Options not modifiable actually by network-manager-openvpn should also > be gathered and displayed, eg: in a dynamic listbox like for the routes, > with an add button. There could be a pop-up in the first column to set > or change the option name, an editable field in the second column to set > or change its value. 0.7 already provides the ability to specify custom routes to apply to the connection in addition to any routes sent by the server. The plugin does not yet support (nor I think does NM) using openvpn in a multi-client server configuration, though peer-to-peer openvpn using a shared secret should work just fine. Dan > > However, send them to the NM mailing list, as > > I'm not longer an active developer on that project. > > > It was the only mail address specified for the debian package. > > Feel free to forward this mail to the mailing list for me or to send me > the mailing list address. Thanks in advance ! > > Oh forget it i found the address :) > > > > At least there should be a way to enable openvpn connections defined > > > somewhere in /etc/openvpn or so. > > > > Not to do that was a concious design decision at that time. > > > Or you could add a text field so that one could add options not > > > supported by network-manager-openvpn, or that would be filled in when > > > importing a configuration file. > > > > That's not the way the applet was designed. The applet should cover most > > of the typical use cases and make it easy to configure those. And from > > my experience that works nicely. Though I haven't followed the recent > > development and discussions. So my statements may be obsolete by now and > > different decisions may have been made. I'm pretty sure though that a > > "command line args" input field is the worst idea ever. > > It just mean "anything should be done so that it works for every > possible configuration" :) > > > > ps: > > [...] > > > > Contact the mailing list. But first you should go and read > > http://catb.org/~esr/faqs/smart-questions.html and change your style of > > writing. I wouldn't expect an answer otherwise. > > > > I wrote first the mail impulsively, but with a smile :) > Nothing agressive or disrespectful from my point of view. > Isn't it better than no feedback at all ? > > Beside this i didn't ask anything... it was only constructive remarks > and suggestions. > > Many openvpn users (me first) will never use this version of the > network-manager-openvpn applet which is not handling the configuration > they are using, and, after some waste of time trying to use it, will > continue to run openvpn as a service, eventually starting additional > openvpn processes manually or using kvpnc, and keep in mind a bad image > of network-manager-openvpn. > > One could use kvpnc, or modify network-manager-openvpn, or reinvent the > wheel and write a configuration tool using standard openvpn > configuration files, for server and client configs, generating keys, and > write some glue to paste it in the gnome-network-manager applet. > > But actually i need nothing, so i won't use, modify, write nor reinvent > anything... network-manager-openvpn was available so i tried
Re: network-manager-openvpn
Le dimanche 06 septembre 2009 à 19:12 +0200, Tim Niemueller a écrit : > On 06.09.2009 18:27, Luc Deschenaux wrote: > > Hello ! > > Hello Luc. Hello everybody ! > > Nice try, but you could do better :) > > Feel free to send patches. I know that patches are always welcome :) But i dont have the time to make it work like everybody at first glance will expect it should, ie: allowing to import any valid openvpn configuration file. Let me just send you, instead of a patch, a more serious analysis of what could make network-manager-openvpn less annoying: 1. It should be possible to activate simutaneously many openvpn configurations using checkboxes instead of radiobuttons, (in server mode also, say in a second time...). 2. It should be possible to "import" any openvpn configuration file, eg: * Copy the config (as a file or individual parameters in gconf) and patch it: parse options for actually supported parameters and patch or add "up", "down", "cd", ... (using gconf to store openvpn parameters is much less cool when it's time to copy the configs directly from disk or to port the application, but it is ok to store the config location or other external details in gconf). * Options not modifiable actually by network-manager-openvpn should also be gathered and displayed, eg: in a dynamic listbox like for the routes, with an add button. There could be a pop-up in the first column to set or change the option name, an editable field in the second column to set or change its value. > However, send them to the NM mailing list, as > I'm not longer an active developer on that project. > It was the only mail address specified for the debian package. Feel free to forward this mail to the mailing list for me or to send me the mailing list address. Thanks in advance ! Oh forget it i found the address :) > > At least there should be a way to enable openvpn connections defined > > somewhere in /etc/openvpn or so. > > Not to do that was a concious design decision at that time. > > Or you could add a text field so that one could add options not > > supported by network-manager-openvpn, or that would be filled in when > > importing a configuration file. > > That's not the way the applet was designed. The applet should cover most > of the typical use cases and make it easy to configure those. And from > my experience that works nicely. Though I haven't followed the recent > development and discussions. So my statements may be obsolete by now and > different decisions may have been made. I'm pretty sure though that a > "command line args" input field is the worst idea ever. It just mean "anything should be done so that it works for every possible configuration" :) > > ps: > [...] > > Contact the mailing list. But first you should go and read > http://catb.org/~esr/faqs/smart-questions.html and change your style of > writing. I wouldn't expect an answer otherwise. > I wrote first the mail impulsively, but with a smile :) Nothing agressive or disrespectful from my point of view. Isn't it better than no feedback at all ? Beside this i didn't ask anything... it was only constructive remarks and suggestions. Many openvpn users (me first) will never use this version of the network-manager-openvpn applet which is not handling the configuration they are using, and, after some waste of time trying to use it, will continue to run openvpn as a service, eventually starting additional openvpn processes manually or using kvpnc, and keep in mind a bad image of network-manager-openvpn. One could use kvpnc, or modify network-manager-openvpn, or reinvent the wheel and write a configuration tool using standard openvpn configuration files, for server and client configs, generating keys, and write some glue to paste it in the gnome-network-manager applet. But actually i need nothing, so i won't use, modify, write nor reinvent anything... network-manager-openvpn was available so i tried it and wasted time doing so... > Tim > Regards, L:üc: ps: Past events forged my style :) Le dimanche 06 septembre 2009 à 18:28 +0200, Luc Deschenaux a écrit : Hello ! > > It tooks me days and hours, and learning how to use openvpn "manually" > before understanding (while trying to import my configuration in order > to enable it through the gnome-network-manager applet and seeing it was > not possible) that network-manager-openvpn is quite unusable and > obsolete. > > Nice try, but you could do better :) > > At least there should be a way to enable openvpn connections defined > somewhere in /etc/openvpn or so. > > Or you could add a text field so that one could add options not > supported by network-manager-openvpn, or that would be filled in when > importing a configuration file. > > Thanks anyway :) > > L:üc: > > ps: > > When trying to import a configuration the gateway name (remote) is set > to "-cert-tls" because of the "remote-cert-tls" directive in my > configuration file. > > When i correct this, i have the me
Re: Network Manager - OpenVPN
Alexander Sandström Krantz wrote: > Hi! > When will the openvpn addon have build in support to change the > openvpn-configuration > ns-cert-type server I think it is possible to accomplish this using the gconf editor to modify the vpn configuration directly. I have a feeling (haven't tested) that if you do this, modifying the vpn connection settings through the network manager openvpn configuration dialog afterwards will overwrite the settings. First configure everything else for your vpn connection through network manager. Then fire up the gconf configuration editor (Applications->System Tools->Configuration Editor on FC6) and find /system/networking/vpn_connections/YOUR_CONNECTION from the tree on the left. Then edit the value of vpn_data on the right. This is a list of the openvpn configuration options (i.e. key,value,key,value...etc). I'm mostly guessing at this, but I vaguely remember modifying the openvpn configuration in this way with success in the past. -casey ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager - OpenVPN
On Mon, 2007-03-26 at 21:19 +0200, Alexander Sandström Krantz wrote: > Hi! > When will the openvpn addon have build in support to change the > openvpn-configuration > ns-cert-type server > > or to be more precise, turn of the requirement for the ns-cert-type to > be set to server. From what I've understood this way of determining if > a certificate is a server or a client certificate is deprecated so the > CA I use (CAcert) doesn't use this flag any more. At the moment I > can't use Network Manager to connect to my VPN because of this, but > instead I have run openvpn through my CLI. > > It would be nice to have this feature in the Network Manager OpenVPN > addon. > Please put feature requests like this in bugzilla. I don't get emailed, but tend to check pet projects I work on pretty religously. This makes it easier for me to post patches and have NM developers review them for inclusion. Jon ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: network-manager-openvpn remote port?
On Mon, 2006-12-11 at 22:08 -0500, Dan Williams wrote: > On Mon, 2006-12-11 at 18:15 -0500, Jim Popovitch wrote: > > I keep hearing that. I want to get involved in NM dev work, > > specifically to help add two-phase auth. I started to send you a > > Two phase auth for WPA[2] Enterprise and 802.1x? Yes. -Jim P. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: network-manager-openvpn remote port?
On Mon, 2006-12-11 at 18:15 -0500, Jim Popovitch wrote: > On Mon, 2006-12-11 at 17:48 -0500, Dan Williams wrote: > > On Fri, 2006-12-08 at 18:22 -0500, Jim Popovitch wrote: > > > Is there a way to specify a non-standard remote port to use with > > > network-manager-openvpn? I don't see anything on the vpn config gui, > > > nor could I find anything conclusive via Google. > > > > Not yet; what's the config item and how is it used? > > > > remote-port 3252 > > Hmm, I saw 1194 in the source code. I worked around it by recompiling > with my port. > > > something like that? It's pretty trivial to add to the code, but the > > GUI bits are a disaster at the moment. > > I keep hearing that. I want to get involved in NM dev work, > specifically to help add two-phase auth. I started to send you a Two phase auth for WPA[2] Enterprise and 802.1x? Dan > private email abt this last week, but held off as I'm not sure who does > what wrt NM and I didn't want to step on anyone's work. > > -Jim P. > ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: network-manager-openvpn remote port?
On Mon, 2006-12-11 at 17:48 -0500, Dan Williams wrote: > On Fri, 2006-12-08 at 18:22 -0500, Jim Popovitch wrote: > > Is there a way to specify a non-standard remote port to use with > > network-manager-openvpn? I don't see anything on the vpn config gui, > > nor could I find anything conclusive via Google. > > Not yet; what's the config item and how is it used? > > remote-port 3252 Hmm, I saw 1194 in the source code. I worked around it by recompiling with my port. > something like that? It's pretty trivial to add to the code, but the > GUI bits are a disaster at the moment. I keep hearing that. I want to get involved in NM dev work, specifically to help add two-phase auth. I started to send you a private email abt this last week, but held off as I'm not sure who does what wrt NM and I didn't want to step on anyone's work. -Jim P. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: network-manager-openvpn remote port?
On Fri, 2006-12-08 at 18:22 -0500, Jim Popovitch wrote: > Is there a way to specify a non-standard remote port to use with > network-manager-openvpn? I don't see anything on the vpn config gui, > nor could I find anything conclusive via Google. Not yet; what's the config item and how is it used? remote-port 3252 something like that? It's pretty trivial to add to the code, but the GUI bits are a disaster at the moment. Dan > Tia, > > -Jim P. > > ___ > NetworkManager-list mailing list > NetworkManager-list@gnome.org > http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list