Re: openvpn and network manager
On Mon, 2 Jun 2008, Dan Williams wrote: > On Mon, 2008-06-02 at 10:34 +0300, Dimitris Zilaskos wrote: >>> >>> Yeah, I poked at this some ago. The issue here is that since TAP looks >>> like an ethernet device, it doesn't have the same IP configuration >>> characteristics as TUN devices do. In the TAP case, you can also do >>> DHCP over the TAP interface and get an IP that way too, or you can use >>> static IP, or you can have the server push the IP down I think. >>> >>> There was also a lot of stuff about bridging in some of the HOWTOs that >>> I read about TAP-mode. Do you have to set up bridging to use openvpn >>> TAP mode on the client? It wasn't clear to me if that was required or >>> not. >> >> I do not think so. I use tap and I have not setup a bridge. > > Ok, good :) Do you use DHCP on the tap interface? > No, my ip is assigned to my certificate DN by the openvpn server. -- Dimitris Zilaskos Department of Physics @ Aristotle University of Thessaloniki , Greece PGP key : http://tassadar.physics.auth.gr/~dzila/pgp_public_key.asc http://egnatia.ee.auth.gr/~dzila/pgp_public_key.asc MD5sum : de2bd8f73d545f0e4caf3096894ad83f pgp_public_key.asc ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: openvpn and network manager
On Mon, 2008-06-02 at 10:34 +0300, Dimitris Zilaskos wrote: > > > > Yeah, I poked at this some ago. The issue here is that since TAP looks > > like an ethernet device, it doesn't have the same IP configuration > > characteristics as TUN devices do. In the TAP case, you can also do > > DHCP over the TAP interface and get an IP that way too, or you can use > > static IP, or you can have the server push the IP down I think. > > > > There was also a lot of stuff about bridging in some of the HOWTOs that > > I read about TAP-mode. Do you have to set up bridging to use openvpn > > TAP mode on the client? It wasn't clear to me if that was required or > > not. > > I do not think so. I use tap and I have not setup a bridge. Ok, good :) Do you use DHCP on the tap interface? Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: openvpn and network manager
> > Yeah, I poked at this some ago. The issue here is that since TAP looks > like an ethernet device, it doesn't have the same IP configuration > characteristics as TUN devices do. In the TAP case, you can also do > DHCP over the TAP interface and get an IP that way too, or you can use > static IP, or you can have the server push the IP down I think. > > There was also a lot of stuff about bridging in some of the HOWTOs that > I read about TAP-mode. Do you have to set up bridging to use openvpn > TAP mode on the client? It wasn't clear to me if that was required or > not. I do not think so. I use tap and I have not setup a bridge. Regards, -- Dimitris Zilaskos Department of Physics @ Aristotle University of Thessaloniki , Greece PGP key : http://tassadar.physics.auth.gr/~dzila/pgp_public_key.asc http://egnatia.ee.auth.gr/~dzila/pgp_public_key.asc MD5sum : de2bd8f73d545f0e4caf3096894ad83f pgp_public_key.asc ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: openvpn and network manager
On Sat, 2008-05-31 at 13:18 -0500, Casey Harkins wrote: > On Sat, 2008-05-31 at 10:42 +0300, Dimitris Zilaskos wrote: > > > By default, NetworkManager will route all traffic through the VPN, so > > > the server supplied routes with a TUN connection are usually moot (as > > > long as the VPN gateway knows how to route things properly). If you > > > don't want to route all traffic through the VPN, you can manually > > > specify which subnets should be routed through the VPN in the advanced > > > properties dialog. > > > > > > I have tried specifying the route manually, and it is not working. If I > > understand correctly what networkmanager is doing, this is caused because > > it treats my TAP interface as a Point-to-Point link, while it actually > > creates a network bridge: > > Right, I forgot about that part of the problem. I really need to sit > down and set up a TAP openvpn server to test this stuff out with and see Yeah, I poked at this some ago. The issue here is that since TAP looks like an ethernet device, it doesn't have the same IP configuration characteristics as TUN devices do. In the TAP case, you can also do DHCP over the TAP interface and get an IP that way too, or you can use static IP, or you can have the server push the IP down I think. There was also a lot of stuff about bridging in some of the HOWTOs that I read about TAP-mode. Do you have to set up bridging to use openvpn TAP mode on the client? It wasn't clear to me if that was required or not. > what I can come up with. As Dan mentioned earlier, Tambet has a patch > that will clean up routing in NMIP4Config (not sure what all that > covers). After that, we need to figure out how to optionally specify a > gateway (and device?) for each route. All the information we need is > available to us, its just a matter of getting it between the openvpn > plugin and NM and having NM do the right thing. Tambet's patch fixes that internally in NM, so I think it's just a matter of getting the tuple of (ip, netmask/prefix, gateway) associated together when they are passed back to NM from the vpn control daemon. dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: openvpn and network manager
On Sat, 2008-05-31 at 10:42 +0300, Dimitris Zilaskos wrote: > > By default, NetworkManager will route all traffic through the VPN, so > > the server supplied routes with a TUN connection are usually moot (as > > long as the VPN gateway knows how to route things properly). If you > > don't want to route all traffic through the VPN, you can manually > > specify which subnets should be routed through the VPN in the advanced > > properties dialog. > > > I have tried specifying the route manually, and it is not working. If I > understand correctly what networkmanager is doing, this is caused because > it treats my TAP interface as a Point-to-Point link, while it actually > creates a network bridge: Right, I forgot about that part of the problem. I really need to sit down and set up a TAP openvpn server to test this stuff out with and see what I can come up with. As Dan mentioned earlier, Tambet has a patch that will clean up routing in NMIP4Config (not sure what all that covers). After that, we need to figure out how to optionally specify a gateway (and device?) for each route. All the information we need is available to us, its just a matter of getting it between the openvpn plugin and NM and having NM do the right thing. -casey ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: openvpn and network manager
> By default, NetworkManager will route all traffic through the VPN, so > the server supplied routes with a TUN connection are usually moot (as > long as the VPN gateway knows how to route things properly). If you > don't want to route all traffic through the VPN, you can manually > specify which subnets should be routed through the VPN in the advanced > properties dialog. I have tried specifying the route manually, and it is not working. If I understand correctly what networkmanager is doing, this is caused because it treats my TAP interface as a Point-to-Point link, while it actually creates a network bridge: May 31 10:22:03 mitsos nm-openvpn[7063]: LZO compression initialized May 31 10:22:03 mitsos nm-openvpn[7063]: Attempting to establish TCP connection with 1.2.3.4:443 [nonblock] May 31 10:22:04 mitsos nm-openvpn[7063]: TCP connection established with 1.2.3.4:443 May 31 10:22:04 mitsos nm-openvpn[7063]: TCPv4_CLIENT link local: [undef] May 31 10:22:04 mitsos nm-openvpn[7063]: TCPv4_CLIENT link remote: 1.2.3.4:443 May 31 10:22:06 mitsos nm-openvpn[7063]: event_wait : Interrupted system call (code=4) May 31 10:22:06 mitsos nm-openvpn[7063]: SIGTERM[hard,] received, process exiting May 31 10:22:19 mitsos NetworkManager: VPN plugin state changed: 3 May 31 10:22:19 mitsos nm-openvpn[7075]: OpenVPN 2.1_rc7 i386-redhat-linux-gnu [SSL] [LZO2] [EPOLL] built on Feb 21 2008 May 31 10:22:19 mitsos nm-openvpn[7075]: WARNING: --ping should normally be used with --ping-restart or --ping-exit May 31 10:22:19 mitsos nm-openvpn[7075]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info. May 31 10:22:19 mitsos NetworkManager: VPN connection 'server.physics.auth.gr' (Connect) reply received. May 31 10:22:19 mitsos nm-openvpn[7075]: LZO compression initialized May 31 10:22:19 mitsos nm-openvpn[7075]: Attempting to establish TCP connection with 1.2.3.4:443 [nonblock] May 31 10:22:20 mitsos nm-openvpn[7075]: TCP connection established with 1.2.3.4:443 May 31 10:22:20 mitsos nm-openvpn[7075]: TCPv4_CLIENT link local: [undef] May 31 10:22:20 mitsos nm-openvpn[7075]: TCPv4_CLIENT link remote: 1.2.3.4:443 May 31 10:22:25 mitsos nm-openvpn[7075]: [vpn.grid.auth.gr] Peer Connection Initiated with 1.2.3.4:443 May 31 10:22:27 mitsos nm-openvpn[7075]: TUN/TAP device tap0 opened May 31 10:22:27 mitsos nm-openvpn[7075]: /sbin/ip link set dev tap0 up mtu 1500 May 31 10:22:27 mitsos nm-openvpn[7075]: /sbin/ip addr add dev tap0 192.168.1.1/24 broadcast 192.168.1.255 May 31 10:22:27 mitsos avahi-daemon[2577]: Joining mDNS multicast group on interface tap0.IPv4 with address 192.168.1.1. May 31 10:22:27 mitsos avahi-daemon[2577]: New relevant interface tap0.IPv4 for mDNS. May 31 10:22:27 mitsos avahi-daemon[2577]: Registering new address record for 192.168.1.1 on tap0.IPv4. May 31 10:22:27 mitsos nm-openvpn[7075]: /usr/bin/nm-openvpn-service-openvpn-helper tap0 1500 1576 192.168.1.1 255.255.255.0 init May 31 10:22:27 mitsos NetworkManager: VPN connection 'server.physics.auth.gr' (IP Config Get) reply received. May 31 10:22:27 mitsos NetworkManager: VPN Gateway: 1.2.3.4 May 31 10:22:27 mitsos NetworkManager: Tunnel Device: tap0 May 31 10:22:27 mitsos NetworkManager: Internal IP4 Address: 192.168.1.1 May 31 10:22:27 mitsos NetworkManager: Internal IP4 Netmask: 255.255.255.0 May 31 10:22:27 mitsos NetworkManager: Internal IP4 Point-to-Point Address: 0.0.0.0 May 31 10:22:27 mitsos NetworkManager: Maximum Segment Size (MSS): 0 May 31 10:22:27 mitsos NetworkManager: Internal IP4 DNS: 192.168.1.2 May 31 10:22:27 mitsos NetworkManager: DNS Domain: '(none)' May 31 10:22:27 mitsos NetworkManager: Login Banner: May 31 10:22:27 mitsos NetworkManager: - May 31 10:22:27 mitsos NetworkManager: (null) May 31 10:22:27 mitsos NetworkManager: - May 31 10:22:27 mitsos nm-openvpn[7075]: Initialization Sequence Completed May 31 10:22:28 mitsos NetworkManager: VPN connection 'server.physics.auth.gr' (IP Config Get) complete. May 31 10:22:28 mitsos NetworkManager: VPN plugin state changed: 4 May 31 10:22:28 mitsos avahi-daemon[2577]: Registering new address record for fe80::2ff:beff:fe18:557f on tap0.*. If I specify the routes manually, they are assigned to the tap0 interface, while the requrirement is to specify for each route its gateway(which in my case is the same for all). I do not wish all traffic to go to vpn, only selected. -- Dimitris Zilaskos Department of Physics @ Aristotle University of Thessaloniki , Greece PGP key : http://tassadar.physics.auth.gr/~dzila/pgp_public_key.asc http://egnatia.ee.auth.gr/~dzila/pgp_public_key.asc MD5sum : de2bd8f73d545f0e4caf3096894ad83f pgp_public_key.asc
Re: openvpn and network manager
On Fri, 2008-05-30 at 14:02 -0400, Dan Williams wrote: > > able to test this. (Does NM require polkit, or can it be disabled?). > > We're going to require PK for lockdown and authorization of editing > system connections and such, and eventually for checking whether the > user actually has authorization to change network connections at all... > so yeah. Are you on Slackware or something? Nope, F8. I was just missing PolicyKit-devel and wrongfully assumed that PolicyKit was new to F9. A 'yum search' eventually set me straight, but not until after I submitted that patch. -casey ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: openvpn and network manager
On Fri, 2008-05-30 at 09:37 -0500, Casey Harkins wrote: > On Fri, 2008-05-30 at 11:59 +0300, Dimitris Zilaskos wrote: > > I have tried removing the ns-cert-type from the nm-openvpn-service.c file. > > Thus I have successfully connected to my openvpn server using x509 > > authentication. However I am facing another issue now: routes are not > > pushed, or if they are, they are ignored Here is the log: > > > They are pushed, but ignored. Like the situation with openvpn TAP > connections, we don't have a way to push these server supplied routes > from the VPN plugin back into NetworkManager's core. It's on my TODO > list to get this working. Tambet's got a patch cleaning up the route stuff in the NMIP4Config object. What's left is if the plugin has routes, we should add another key to the dict that the plugin sends back to NM to hold the routes from the VPN concentrator. > By default, NetworkManager will route all traffic through the VPN, so > the server supplied routes with a TUN connection are usually moot (as > long as the VPN gateway knows how to route things properly). If you > don't want to route all traffic through the VPN, you can manually > specify which subnets should be routed through the VPN in the advanced > properties dialog. > > > Dan: Attached is a patch (against svn rev 3712) which removes the > '--ns-cert-type server' argument from the openvpn service. I was not r3713, thanks! > able to test this. (Does NM require polkit, or can it be disabled?). We're going to require PK for lockdown and authorization of editing system connections and such, and eventually for checking whether the user actually has authorization to change network connections at all... so yeah. Are you on Slackware or something? Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: openvpn and network manager
On Fri, 2008-05-30 at 11:59 +0300, Dimitris Zilaskos wrote:
> I have tried removing the ns-cert-type from the nm-openvpn-service.c file.
> Thus I have successfully connected to my openvpn server using x509
> authentication. However I am facing another issue now: routes are not
> pushed, or if they are, they are ignored Here is the log:
They are pushed, but ignored. Like the situation with openvpn TAP
connections, we don't have a way to push these server supplied routes
from the VPN plugin back into NetworkManager's core. It's on my TODO
list to get this working.
By default, NetworkManager will route all traffic through the VPN, so
the server supplied routes with a TUN connection are usually moot (as
long as the VPN gateway knows how to route things properly). If you
don't want to route all traffic through the VPN, you can manually
specify which subnets should be routed through the VPN in the advanced
properties dialog.
Dan: Attached is a patch (against svn rev 3712) which removes the
'--ns-cert-type server' argument from the openvpn service. I was not
able to test this. (Does NM require polkit, or can it be disabled?).
-casey
Index: NetworkManager/vpn-daemons/openvpn/src/nm-openvpn-service.c
===
--- NetworkManager.orig/vpn-daemons/openvpn/src/nm-openvpn-service.c
+++ NetworkManager/vpn-daemons/openvpn/src/nm-openvpn-service.c
@@ -474,8 +474,6 @@ nm_openvpn_start_openvpn_binary (NMOpenv
switch (connection_type) {
case NM_OPENVPN_CONTYPE_X509:
g_ptr_array_add (openvpn_argv, (gpointer) "--client");
- g_ptr_array_add (openvpn_argv, (gpointer) "--ns-cert-type");
- g_ptr_array_add (openvpn_argv, (gpointer) "server");
tmp = g_hash_table_lookup (properties, NM_OPENVPN_KEY_CA);
if (tmp) {
@@ -525,8 +523,6 @@ nm_openvpn_start_openvpn_binary (NMOpenv
case NM_OPENVPN_CONTYPE_PASSWORD:
/* Client mode */
g_ptr_array_add (openvpn_argv, (gpointer) "--client");
- g_ptr_array_add (openvpn_argv, (gpointer) "--ns-cert-type");
- g_ptr_array_add (openvpn_argv, (gpointer) "server");
/* Use user/path authentication */
g_ptr_array_add (openvpn_argv, (gpointer) "--auth-user-pass");
@@ -539,8 +535,6 @@ nm_openvpn_start_openvpn_binary (NMOpenv
case NM_OPENVPN_CONTYPE_X509USERPASS:
g_ptr_array_add (openvpn_argv, (gpointer) "--client");
- g_ptr_array_add (openvpn_argv, (gpointer) "--ns-cert-type");
- g_ptr_array_add (openvpn_argv, (gpointer) "server");
tmp = g_hash_table_lookup (properties, NM_OPENVPN_KEY_CA);
if (tmp) {
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: openvpn and network manager
Hi guys, I have tried removing the ns-cert-type from the nm-openvpn-service.c file. Thus I have successfully connected to my openvpn server using x509 authentication. However I am facing another issue now: routes are not pushed, or if they are, they are ignored Here is the log: May 30 11:10:47 mitsos nm-openvpn[3319]: LZO compression initialized May 30 11:10:47 mitsos nm-openvpn[3319]: Attempting to establish TCP connection with 1.2.3.4:443 [nonblock] May 30 11:10:48 mitsos nm-openvpn[3319]: TCP connection established with 1.2.3.4:443 May 30 11:10:48 mitsos nm-openvpn[3319]: TCPv4_CLIENT link local: [undef] May 30 11:10:48 mitsos nm-openvpn[3319]: TCPv4_CLIENT link remote: 1.2.3.4:443 May 30 11:10:50 mitsos nm-openvpn[3319]: WARNING: 'dev-type' is used inconsistently, local='dev-type tun', remote='dev-type tap' May 30 11:10:50 mitsos nm-openvpn[3319]: WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1544', remote='link-mtu 1576' May 30 11:10:50 mitsos nm-openvpn[3319]: WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1500', remote='tun-mtu 1532' May 30 11:10:50 mitsos nm-openvpn[3319]: [server.physics.auth.gr] Peer Connection Initiated with 1.2.3.4:443 May 30 11:10:51 mitsos nm-openvpn[3319]: WARNING: Since you are using --dev tun with a point-to-point topology, the second argument to --ifconfig must be an IP address. You are using something (255.255.255.0) that looks more like a netmask. (silence this warning with --ifconfig-nowarn) May 30 11:10:51 mitsos kernel: tun0: Disabled Privacy Extensions May 30 11:10:51 mitsos nm-openvpn[3319]: TUN/TAP device tun0 opened May 30 11:10:51 mitsos nm-openvpn[3319]: /sbin/ip link set dev tun0 up mtu 1500 May 30 11:10:51 mitsos nm-openvpn[3319]: /sbin/ip addr add dev tun0 local 192.168.1.1 peer 255.255.255.0 May 30 11:10:51 mitsos nm-openvpn[3319]: /usr/bin/nm-openvpn-service-openvpn-helper tun0 1500 1544 192.168.1.1 255.255.255.0 init May 30 11:10:51 mitsos NetworkManager: VPN connection 'server.physics.auth.gr' (IP Config Get) reply received. May 30 11:10:51 mitsos NetworkManager: VPN Gateway: 1.2.3.4 May 30 11:10:51 mitsos NetworkManager: Tunnel Device: tun0 May 30 11:10:51 mitsos NetworkManager: Internal IP4 Address: 192.168.1.1 May 30 11:10:51 mitsos NetworkManager: Internal IP4 Netmask: 255.255.255.0 May 30 11:10:51 mitsos NetworkManager: Internal IP4 Point-to-Point Address: 255.255.255.0 May 30 11:10:51 mitsos NetworkManager: Maximum Segment Size (MSS): 0 May 30 11:10:51 mitsos NetworkManager: Internal IP4 DNS: 192.168.1.2 May 30 11:10:51 mitsos NetworkManager: DNS Domain: '(none)' May 30 11:10:51 mitsos NetworkManager: Login Banner: May 30 11:10:51 mitsos NetworkManager: - May 30 11:10:51 mitsos NetworkManager: (null) May 30 11:10:51 mitsos NetworkManager: - May 30 11:10:51 mitsos nm-openvpn[3319]: Initialization Sequence Completed May 30 11:10:52 mitsos NetworkManager: VPN connection 'server.physics.auth.gr' (IP Config Get) complete. May 30 11:10:52 mitsos NetworkManager: VPN plugin state changed: 4 Cheers, On Fri, 23 May 2008, Dan Williams wrote: > On Fri, 2008-05-23 at 14:00 -0500, Casey Harkins wrote: >> On Fri, 2008-05-23 at 07:57 +0300, Dimitris Zilaskos wrote: >>> On Thu, 22 May 2008, Dan Williams wrote: I didn't originally write that bit, but what's the impact of getting rid of the check, if any? That openvpn will just accept any old certificate that it gets sent from the server? Dan >>> >>> >>> No, this check examines if the certificate has the nsCertType field set to >>> "client", it has nothing to do with certificate age. As I mentioned in my >>> previous mail, it is an old depracated field. It has been replaced by >>> extendedkeyusage (http://www.ietf.org/rfc/rfc3280.txt?number=3280). >>> >> >> Also worth noting that it has nothing to do with validating the >> certificate. >> >> The question is should it be removed entirely or made a preference in >> nm-openvpn-properties? Removing is as simple as removing the relevant >> lines (as indicated in the thread referenced earlier). Making it a >> preference should be relatively straight forward as well. I'd imagine a >> patch would be the best way to make this happen. If there aren't any >> takers, I'll whip one up next week to make the ns-cert-type openvpn >> option configurable (none, client, server). > > A patch to just remove the check entirely would be fine with me. It > doesn't sound like we need it at all. > > Dan > -- Dimitris Zilaskos Department of Physics @ Aristotle University of Thessaloniki , Greece PGP key : http://tassadar.physics.auth.gr/~dzila/pgp_public_key.asc http://egnatia.ee.auth.gr/~dzila/pgp_public_key.asc MD5sum : de2bd8f73d545f0e4caf3096894ad83f pgp_public_key.asc ===
Re: openvpn and network manager
On Fri, 2008-05-23 at 14:00 -0500, Casey Harkins wrote: > On Fri, 2008-05-23 at 07:57 +0300, Dimitris Zilaskos wrote: > > On Thu, 22 May 2008, Dan Williams wrote: > > > I didn't originally write that bit, but what's the impact of getting rid > > > of the check, if any? That openvpn will just accept any old certificate > > > that it gets sent from the server? > > > > > > Dan > > > > > > No, this check examines if the certificate has the nsCertType field set to > > "client", it has nothing to do with certificate age. As I mentioned in my > > previous mail, it is an old depracated field. It has been replaced by > > extendedkeyusage (http://www.ietf.org/rfc/rfc3280.txt?number=3280). > > > > Also worth noting that it has nothing to do with validating the > certificate. > > The question is should it be removed entirely or made a preference in > nm-openvpn-properties? Removing is as simple as removing the relevant > lines (as indicated in the thread referenced earlier). Making it a > preference should be relatively straight forward as well. I'd imagine a > patch would be the best way to make this happen. If there aren't any > takers, I'll whip one up next week to make the ns-cert-type openvpn > option configurable (none, client, server). A patch to just remove the check entirely would be fine with me. It doesn't sound like we need it at all. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: openvpn and network manager
> Also worth noting that it has nothing to do with validating the > certificate. > > The question is should it be removed entirely or made a preference in > nm-openvpn-properties? Removing is as simple as removing the relevant > lines (as indicated in the thread referenced earlier). Making it a > preference should be relatively straight forward as well. I'd imagine a > patch would be the best way to make this happen. If there aren't any > takers, I'll whip one up next week to make the ns-cert-type openvpn > option configurable (none, client, server). > > -casey Thank you for having a look at this. IMHO, I do not consider this particular option worthy of becoming a configurable choice. Perhaps it would be better to invest effort on a network manager method that will enable advanced users to specify/modify the parameters fed to openvpn by network manager. Cheers, -- Dimitris Zilaskos Department of Physics @ Aristotle University of Thessaloniki , Greece PGP key : http://tassadar.physics.auth.gr/~dzila/pgp_public_key.asc http://egnatia.ee.auth.gr/~dzila/pgp_public_key.asc MD5sum : de2bd8f73d545f0e4caf3096894ad83f pgp_public_key.asc ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: openvpn and network manager
On Fri, 2008-05-23 at 07:57 +0300, Dimitris Zilaskos wrote: > On Thu, 22 May 2008, Dan Williams wrote: > > I didn't originally write that bit, but what's the impact of getting rid > > of the check, if any? That openvpn will just accept any old certificate > > that it gets sent from the server? > > > > Dan > > > No, this check examines if the certificate has the nsCertType field set to > "client", it has nothing to do with certificate age. As I mentioned in my > previous mail, it is an old depracated field. It has been replaced by > extendedkeyusage (http://www.ietf.org/rfc/rfc3280.txt?number=3280). > Also worth noting that it has nothing to do with validating the certificate. The question is should it be removed entirely or made a preference in nm-openvpn-properties? Removing is as simple as removing the relevant lines (as indicated in the thread referenced earlier). Making it a preference should be relatively straight forward as well. I'd imagine a patch would be the best way to make this happen. If there aren't any takers, I'll whip one up next week to make the ns-cert-type openvpn option configurable (none, client, server). -casey ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: openvpn and network manager
On Thu, 22 May 2008, Dan Williams wrote: On Thu, 2008-05-22 at 16:13 +0400, Vasiliy G Tolstov wrote: On Thu, 2008-05-22 at 14:52 +0300, Dimitris Zilaskos wrote: I did some research on that and also contacted the local CA operators. They told me that ns-cert-type is old,propriety and depracated and does not significantly add to security. Here are some references: http://osdir.com/ml/java.ejbca.devel/2005-11/msg3.html http://openvpn.net/archive/openvpn-users/2007-03/msg00062.html http://readlist.com/lists/postfix.org/postfix-users/12/64401.html http://emperor.canarie.ca/pipermail/tagpma-general/2007-January/001326.html In any case, this certificate extension is never gonna be supported in several educational large PKI infrastructures that I (and serveral other academic users as well) employ. So lack of this feature will mean loss of a large audience for the networkmanager tool. Can we have a fix please ?:) yes, can we have a fix ? or option to disable this... ? I didn't originally write that bit, but what's the impact of getting rid of the check, if any? That openvpn will just accept any old certificate that it gets sent from the server? Dan No, this check examines if the certificate has the nsCertType field set to "client", it has nothing to do with certificate age. As I mentioned in my previous mail, it is an old depracated field. It has been replaced by extendedkeyusage (http://www.ietf.org/rfc/rfc3280.txt?number=3280). In any case, no modern CA should support it. And frankly I do find its whole concept contradicting. For example I may use an x509 host certificate for my system to have an ssl enabled web server. I might also need to use the same certificate to establish an openvpn to my laboratory or business. That makes my system both "client" and "server". Best regards, -- Dimitris Zilaskos Department of Physics @ Aristotle University of Thessaloniki , Greece PGP key : http://tassadar.physics.auth.gr/~dzila/pgp_public_key.asc http://egnatia.ee.auth.gr/~dzila/pgp_public_key.asc MD5sum : de2bd8f73d545f0e4caf3096894ad83f pgp_public_key.asc ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: openvpn and network manager
On Thu, 2008-05-22 at 16:13 +0400, Vasiliy G Tolstov wrote: > On Thu, 2008-05-22 at 14:52 +0300, Dimitris Zilaskos wrote: > > I did some research on that and also contacted the local CA operators. > > They told me that ns-cert-type is old,propriety and depracated and does > > not significantly add to security. Here are some references: > > > > http://osdir.com/ml/java.ejbca.devel/2005-11/msg3.html > > http://openvpn.net/archive/openvpn-users/2007-03/msg00062.html > > http://readlist.com/lists/postfix.org/postfix-users/12/64401.html > > http://emperor.canarie.ca/pipermail/tagpma-general/2007-January/001326.html > > > > In any case, this certificate extension is never gonna be > > supported in several educational large PKI infrastructures that I (and > > serveral other academic users as well) employ. So lack of this feature > > will mean loss of a large audience for the networkmanager tool. > > > > Can we have a fix please ?:) > > yes, can we have a fix ? or option to disable this... ? I didn't originally write that bit, but what's the impact of getting rid of the check, if any? That openvpn will just accept any old certificate that it gets sent from the server? Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: openvpn and network manager
On Thu, 2008-05-22 at 14:52 +0300, Dimitris Zilaskos wrote: > I did some research on that and also contacted the local CA operators. > They told me that ns-cert-type is old,propriety and depracated and does > not significantly add to security. Here are some references: > > http://osdir.com/ml/java.ejbca.devel/2005-11/msg3.html > http://openvpn.net/archive/openvpn-users/2007-03/msg00062.html > http://readlist.com/lists/postfix.org/postfix-users/12/64401.html > http://emperor.canarie.ca/pipermail/tagpma-general/2007-January/001326.html > > In any case, this certificate extension is never gonna be > supported in several educational large PKI infrastructures that I (and > serveral other academic users as well) employ. So lack of this feature > will mean loss of a large audience for the networkmanager tool. > > Can we have a fix please ?:) yes, can we have a fix ? or option to disable this... ? -- Vasiliy G Tolstov http://selfip.ru smime.p7s Description: S/MIME cryptographic signature ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: openvpn and network manager
I did some research on that and also contacted the local CA operators. They told me that ns-cert-type is old,propriety and depracated and does not significantly add to security. Here are some references: http://osdir.com/ml/java.ejbca.devel/2005-11/msg3.html http://openvpn.net/archive/openvpn-users/2007-03/msg00062.html http://readlist.com/lists/postfix.org/postfix-users/12/64401.html http://emperor.canarie.ca/pipermail/tagpma-general/2007-January/001326.html In any case, this certificate extension is never gonna be supported in several educational large PKI infrastructures that I (and serveral other academic users as well) employ. So lack of this feature will mean loss of a large audience for the networkmanager tool. Can we have a fix please ?:) -- Dimitris Zilaskos Department of Physics @ Aristotle University of Thessaloniki , Greece PGP key : http://tassadar.physics.auth.gr/~dzila/pgp_public_key.asc http://egnatia.ee.auth.gr/~dzila/pgp_public_key.asc MD5sum : de2bd8f73d545f0e4caf3096894ad83f pgp_public_key.asc On Thu, 22 May 2008, Vasiliy G Tolstov wrote: > On Thu, 2008-05-22 at 14:20 +0300, Dimitris Zilaskos wrote: > >> Hi, >> >> I am using Fedora Core 9 and I have been bitten by this issue: >> >> http://www.mail-archive.com/networkmanager-list@gnome.org/msg09258.html >> >> Is there any other why, apart from changing the source code, to bypass it? >> Maybe a feature to be added allowing changes of advanced openvpn settings? >> >> TIA >> > > > Greate feature, but may break security... > > > -- > Vasiliy G Tolstov > http://selfip.ru > > > ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
openvpn and network manager
Hi, I am using Fedora Core 9 and I have been bitten by this issue: http://www.mail-archive.com/networkmanager-list@gnome.org/msg09258.html Is there any other why, apart from changing the source code, to bypass it? Maybe a feature to be added allowing changes of advanced openvpn settings? TIA -- Dimitris Zilaskos Department of Physics @ Aristotle University of Thessaloniki , Greece PGP key : http://tassadar.physics.auth.gr/~dzila/pgp_public_key.asc http://egnatia.ee.auth.gr/~dzila/pgp_public_key.asc MD5sum : de2bd8f73d545f0e4caf3096894ad83f pgp_public_key.asc ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
