IPv6 in network-manager-openvpn
Hello, A few weeks ago I ran into a bug in NetworkManager: even though OpenVPN now supports IPv6 in tunnels, the OpenVPN plugin of NetworkManager doesn't support it. I found bug 682620 ( https://bugzilla.gnome.org/show_bug.cgi?id=682620) and I've implemented some of the missing features with the help of network-manager-openconnect commits. My patches are attached to this email, can someone kindly review them and tell me what may be wrong with them? As I'm new with NetworkManager, I think there must be some mistakes in my code. The patches are working well in my testing environment with NetworkManager 0.9.8 but with the development revision, NetworkManager complains about invalid IP6 config received! in src/vpn-manager/nm-vpn-connection.c on line 1034. As I understand things, a ! is missing on line 1031 ( http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/vpn-manager/nm-vpn-connection.c?id=320a9d16a3067df32f5ad8a2bb3770104ec359b1#n1031), but this is strange as this means no IPv6 VPN should work with current development revision... Does anyone know how OpenConnect plugin can work with such code? Thanks, Nicolas (IooNag on irc.freenode.net) 0001-service-pass-IPv6-related-information-to-NM.patch Description: Binary data 0002-properties-expose-IPv6-capability-to-the-UI.patch Description: Binary data ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: IPv6 in network-manager-openvpn
On Thu, 2013-08-22 at 21:39 +0200, Nicolas Iooss wrote: 2013/8/21 Dan Winship On 08/19/2013 12:47 PM, Nicolas Iooss wrote: The patches are working well in my testing environment with NetworkManager 0.9.8 but with the development revision I've got few issues such as https://bugzilla.gnome.org/show_bug.cgi?id=706286. Now NM crashes on a segmentation fault at http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/nm-policy.c#n788as nm_vpn_connection_get_ip6_internal_gateway returns NULL for my VPN Right. Does the attached patch fix it? Your patch fixed the segmentation fault but now NetworkManager sets up a default route via the VPN even if the OpenVPN server has not pushed any. Unfortunately we cannot rely on administrators always pushing a default route if the VPN can actually route all traffic. What we *could* do is the same thing that openconnect and vpnc do, which is that if any other routes are pushed to the client, then nm-openvpn-service-openvpn-helper sets the NEVER_DEFAULT flag which prevents the tunnel from claiming the default route in NetworkManager. The problem you're going to run into is that the NM-openvpn plugin doesn't yet support IPv6, because last time some patches got proposed, openvpn didn't have full IPv6 support and didn't pass back the necessary stuff to the helper script :( That may have changed? Dan More precisely, with NetworkManager OpenVPN plugin, ip -6 route shows default dev tun0 proto static metric 1024 whereas executing openvpn in command line doesn't add this default route. Moreover this route doesn't work as the next hop needs to be defined to be able to route packets in an OpenVPN tunnel. To fix this behavior, I opened a bug a few days ago which makes get_best_ip6_config no longer returns VPN connections which don't have any internal gateway : https://bugzilla.gnome.org/show_bug.cgi?id=706332. In fact I don't know how to make an OpenVPN server route the IPv6 internet but by pushing to clients a route to 2000::/3 as described on http://tomsalmon.eu/2013/04/openvpn-ipv6-with-tun-device/ (last line of the config file), as there is no IPv6 equivalent of OpenVPN setting route_vpn_gateway (which is what NM uses as IPv4 internal gateway). This is why I think that a VPN plugin which doesn't set the IPv6 internal gateway connection parameter shouldn't be considered as a connection providing a default route to the Internet (and this is what I implemented in the patch for bug #706332). Nicolas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: PEAP and keyfile
On Fri, 2013-08-16 at 19:31 -0500, Jerry Vonau wrote: Hi All: I've ran into a situation that I'm not sure in how to handle with these packages[1] I was able to use nm-connection-editor with only the keyfile plugin to create the system connection with ease and resulted in this configuration: [802-1x] eap=peap; identity=x phase2-auth=mschapv2 password=y [802-11-wireless-security] key-mgmt=wpa-eap After updating the rpms[2] using nm-connection-editor results in this configuration: [802-11-wireless-security] key-mgmt=wpa-eap [802-1x] eap=peap; identity=x phase2-auth=mschapv2 password-flags=1 system-ca-certs=true I'm at a bit of a loss as to what to do about this, any help or pointers would be grateful. I understand that password-flags=1 hands this over to an auth agent for the secrets, gnome keyring is running but with an empty password. I clicked ignore when prompted for the certs file. I've tried to downgrade back to [1] but with the same results. Am I running into some polkit issue here? What other dependencies might I have to downgrade to return to the same functionality? If you change password-flags to 0 and put the password back in, does the editor preserve it? Dan Thank, Jerry 1. NetworkManager-0.9.7.0-8.git20121004.fc18.armv7hl network-manager-applet-0.9.7.0-4.git20121016.fc18.armv7hl NetworkManager-glib-0.9.7.0-8.git20121004.fc18.armv7hl nm-connection-editor-0.9.7.0-4.git20121016.fc18.armv7hl 2. NetworkManager-0.9.8.1-3.git20130514.fc18.armv7hl network-manager-applet-0.9.8.1-3.git20130430.fc18.armv7hl NetworkManager-glib-0.9.8.1-3.git20130514.fc18.armv7hl nm-connection-editor-0.9.8.1-3.git20130430.fc18.armv7hl ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [HELP] Don't save user name for 802.1x connection
On Wed, 2013-08-21 at 15:51 +0200, Matthias Ellmer wrote: Hey everyone, I'm trying to deploy linux to a classroom with 15 laptops that have to connect to 802.1x wireless. The students use their university accounts as logins. Is it possible to create a connection profile where the username is not remembered, similarly to how you can set the password-flag to not-saved? This would be very useful because there can't be any expactation of persistence between sessions. There is only one guest user account that students use, the $HOME of which will be wiped at shutdown, so per-user settings won't be an option either. Modifying the config every time seems way to cumbersome of an approach. Ideally I'd imagine something along the lines of: [802.1x] eap=ttls; phase2-auth=mschapv2 password-flags=2 # Don't remember identity-flags=2 # Don't remember Laptop boots up, sees system-connection, tries to connect and prompts for both username and password. Is this scenario currently possible? If not, is this something that can be implemented? At the moment it's not possible, but it's something that could be implemented using some of the new connection details stuff that's in the pipe, in combination with some flags like you describe. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: PEAP and keyfile
On Mon, 2013-08-26 at 11:53 -0500, Dan Williams wrote: On Fri, 2013-08-16 at 19:31 -0500, Jerry Vonau wrote: Hi All: I've ran into a situation that I'm not sure in how to handle with these packages[1] I was able to use nm-connection-editor with only the keyfile plugin to create the system connection with ease and resulted in this configuration: [802-1x] eap=peap; identity=x phase2-auth=mschapv2 password=y [802-11-wireless-security] key-mgmt=wpa-eap After updating the rpms[2] using nm-connection-editor results in this configuration: [802-11-wireless-security] key-mgmt=wpa-eap [802-1x] eap=peap; identity=x phase2-auth=mschapv2 password-flags=1 system-ca-certs=true I'm at a bit of a loss as to what to do about this, any help or pointers would be grateful. I understand that password-flags=1 hands this over to an auth agent for the secrets, gnome keyring is running but with an empty password. I clicked ignore when prompted for the certs file. I've tried to downgrade back to [1] but with the same results. Am I running into some polkit issue here? What other dependencies might I have to downgrade to return to the same functionality? If you change password-flags to 0 and put the password back in, does the editor preserve it? Dan When I have access to that network again that is one of the first things I was going to try. I'll let you know how I make out. Thanks a bunch, Jerry Thank, Jerry 1. NetworkManager-0.9.7.0-8.git20121004.fc18.armv7hl network-manager-applet-0.9.7.0-4.git20121016.fc18.armv7hl NetworkManager-glib-0.9.7.0-8.git20121004.fc18.armv7hl nm-connection-editor-0.9.7.0-4.git20121016.fc18.armv7hl 2. NetworkManager-0.9.8.1-3.git20130514.fc18.armv7hl network-manager-applet-0.9.8.1-3.git20130430.fc18.armv7hl NetworkManager-glib-0.9.8.1-3.git20130514.fc18.armv7hl nm-connection-editor-0.9.8.1-3.git20130430.fc18.armv7hl ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: IPv6 in network-manager-openvpn
* Dan Williams On Thu, 2013-08-22 at 21:39 +0200, Nicolas Iooss wrote: Your patch fixed the segmentation fault but now NetworkManager sets up a default route via the VPN even if the OpenVPN server has not pushed any. Unfortunately we cannot rely on administrators always pushing a default route if the VPN can actually route all traffic. Nor can you rely on the VPN always being able to route all traffic... The problem you're going to run into is that the NM-openvpn plugin doesn't yet support IPv6, because last time some patches got proposed, openvpn didn't have full IPv6 support and didn't pass back the necessary stuff to the helper script :( That may have changed? Most definitely! More info here: https://bugzilla.gnome.org/show_bug.cgi?id=682620#c1 BTW: When I tested Nicolas' patches I did so using the standard F19 OpenVPN RPM. It Works(tm)! Tore ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: IPv6 in network-manager-openvpn
On Mon, 2013-08-26 at 19:01 +0200, Tore Anderson wrote: * Dan Williams On Thu, 2013-08-22 at 21:39 +0200, Nicolas Iooss wrote: Your patch fixed the segmentation fault but now NetworkManager sets up a default route via the VPN even if the OpenVPN server has not pushed any. Unfortunately we cannot rely on administrators always pushing a default route if the VPN can actually route all traffic. Nor can you rely on the VPN always being able to route all traffic... The assumption here is on the side of security, that it's better to send all traffic to the VPN and fail, than it is to send your traffic over un-encrypted links when a VPN is supposed to be active and you think things are encrypted. Dan The problem you're going to run into is that the NM-openvpn plugin doesn't yet support IPv6, because last time some patches got proposed, openvpn didn't have full IPv6 support and didn't pass back the necessary stuff to the helper script :( That may have changed? Most definitely! More info here: https://bugzilla.gnome.org/show_bug.cgi?id=682620#c1 BTW: When I tested Nicolas' patches I did so using the standard F19 OpenVPN RPM. It Works(tm)! Tore ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: IPv6 in network-manager-openvpn
On Mon, 2013-08-26 at 19:01 +0200, Tore Anderson wrote: * Dan Williams On Thu, 2013-08-22 at 21:39 +0200, Nicolas Iooss wrote: Your patch fixed the segmentation fault but now NetworkManager sets up a default route via the VPN even if the OpenVPN server has not pushed any. Unfortunately we cannot rely on administrators always pushing a default route if the VPN can actually route all traffic. Nor can you rely on the VPN always being able to route all traffic... The problem you're going to run into is that the NM-openvpn plugin doesn't yet support IPv6, because last time some patches got proposed, openvpn didn't have full IPv6 support and didn't pass back the necessary stuff to the helper script :( That may have changed? Most definitely! More info here: https://bugzilla.gnome.org/show_bug.cgi?id=682620#c1 BTW: When I tested Nicolas' patches I did so using the standard F19 OpenVPN RPM. It Works(tm)! Did the issue with --proto you mentioned in the bug (eg http://thread.gmane.org/gmane.network.openvpn.devel/7160/focus=7165 ) get fixed as well? Then it would be a lot simpler to enable IPv6 support because we wouldn't need any UI changes to make the user indicate that they want IPv6 explicitly (which would trigger udp6/tcp6). Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: IPv6 in network-manager-openvpn
* Dan Williams The assumption here is on the side of security, that it's better to send all traffic to the VPN and fail, than it is to send your traffic over un-encrypted links when a VPN is supposed to be active and you think things are encrypted. That's a pretty good argument for merging these patches, actually. Right now all IPv6 traffic will go unencrypted, even though the VPN is perfectly capable of routing IPv6 to all or parts of ::/0. For me, this merely an annoyance (I always have to do ssh -4 some.work.system because IPv6 just times out), but for others this may be a big privacy problem, e.g. as reported here: http://torrentfreak.com/huge-security-flaw-makes-vpns-useless-for-bittorrent-100617/ Tore ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: IPv6 in network-manager-openvpn
* Dan Williams Did the issue with --proto you mentioned in the bug (eg http://thread.gmane.org/gmane.network.openvpn.devel/7160/focus=7165 ) get fixed as well? Then it would be a lot simpler to enable IPv6 support because we wouldn't need any UI changes to make the user indicate that they want IPv6 explicitly (which would trigger udp6/tcp6). No, not yet. However that is an orthogonal issue. --proto udp6/tcp6 vs tcp/udp becoming dual-stack strictly relates to the *transport*. I.e., the protocol the OpenVPN client uses for communicating with the OpenVPN server over the internet. Nicolas' patches relate strictly to IPv6 *payload*. You can very well tunnel IPv6 packets over a OpenVPN tunnel where the transport is using IPv4 and vice versa. (In pretty much the same way that you can make a TCP connection through an OpenVPN tunnel using --proto udp.) As long as --proto udp/tcp remains single-stack IPv4 in OpenVPN, this means that Nicolas' patches will not enable NM-OpenVPN to speak to the VPN servers over IPv6. That's OK, having support for IPv6 payload is still a huge improvement. If later --proto udp/tcp becomes dual-stack (and --proto udp6/tcp6 goes away), then that should just start working (except that maybe the insert a static host route to VPN server with the [old] default gateway as the next hop functionality might need some extra logic). Tore ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
