Re: Headless VPN connections
On Tue, 2014-07-15 at 17:16 +0200, D.S. Ljungmark wrote: On 15/07/14 15:20, Thomas Haller wrote: ... BUT... for VPN, the settings are opaque to NetworkManager and passed on to the VPN plugin. So, to know the meaning of the [vpn] settings, you have to look for their meaning in NetworkManager-openvpn... usually these parameters correspond to command line options to openvpn. So see `man openvpn`. Aye, we have openVpn setup working. but not integrated with NetworkManager, what we're hoping is to have NM manage all interfaces and VPN's and just have stuff work without having to manage it via various cron jobs to automatically restart things just in case. ( seriously, running curl http://vpn.vpn.vpn || service vpn restart is -not- optimal. But was what we used to have ) Sidenote: NetworkManager-openvpn plugin does not pass any keys blindly to openvpn. It only allows those options, that it understands. The reason is that if the plugin would allow options that it cannot understand, it would not know what openvpn is doing. Thus, there might be some options, that are not implemented in the plugin and do not work. But as you said you got NM connecting, that does not concern you. Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Headless VPN connections
Thanks, good to know. The one thing I did struggle with for a while was permissions on the keyfiles. Now as said, we have a connection defined. It connects as intended, if ordered manually. But it doesn't auto connect or reconnect. /D.S. On 16 Jul 2014 10:20, Thomas Haller thal...@redhat.com wrote: On Tue, 2014-07-15 at 17:16 +0200, D.S. Ljungmark wrote: On 15/07/14 15:20, Thomas Haller wrote: ... BUT... for VPN, the settings are opaque to NetworkManager and passed on to the VPN plugin. So, to know the meaning of the [vpn] settings, you have to look for their meaning in NetworkManager-openvpn... usually these parameters correspond to command line options to openvpn. So see `man openvpn`. Aye, we have openVpn setup working. but not integrated with NetworkManager, what we're hoping is to have NM manage all interfaces and VPN's and just have stuff work without having to manage it via various cron jobs to automatically restart things just in case. ( seriously, running curl http://vpn.vpn.vpn || service vpn restart is -not- optimal. But was what we used to have ) Sidenote: NetworkManager-openvpn plugin does not pass any keys blindly to openvpn. It only allows those options, that it understands. The reason is that if the plugin would allow options that it cannot understand, it would not know what openvpn is doing. Thus, there might be some options, that are not implemented in the plugin and do not work. But as you said you got NM connecting, that does not concern you. Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Headless VPN connections
On Wed, 2014-07-16 at 02:59 +0200, D.S. Ljungmark wrote: So, I have now something that works. it can connect to vpn manually. Next up, how do I get autoconnect to work? I thought connection.autoconnect was enough, but appearantly that's not the case. What am I missing? ipv4 + ipv6 network comes up normally as it should. [[ I did not test this myself, but I think... ]] connection.autoconnect is ignored by VPN type connections. What might work for you, is setting the connection.secondaries option of the parent ethernet/wifi-connection. One downside of this is that the parent connection is not part of the VPN-keyfile that you want to deploy. Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Headless VPN connections
Ah. That means we have to deploy the primary connections as well. Right now those are auto generated and not stored persistently. I'll try that, any thing else I can try? On 16 Jul 2014 10:24, Thomas Haller thal...@redhat.com wrote: On Wed, 2014-07-16 at 02:59 +0200, D.S. Ljungmark wrote: So, I have now something that works. it can connect to vpn manually. Next up, how do I get autoconnect to work? I thought connection.autoconnect was enough, but appearantly that's not the case. What am I missing? ipv4 + ipv6 network comes up normally as it should. [[ I did not test this myself, but I think... ]] connection.autoconnect is ignored by VPN type connections. What might work for you, is setting the connection.secondaries option of the parent ethernet/wifi-connection. One downside of this is that the parent connection is not part of the VPN-keyfile that you want to deploy. Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Headless VPN connections
That sounds like a working method. I'm less worried about the cleartext hole as the VPN is for internal and debugging use. Dispatcher vs making the default connection persistent are about the same, which method is better supported and gives better guarantees that things work reliably? On 16 Jul 2014 10:43, Thomas Haller thal...@redhat.com wrote: On Wed, 2014-07-16 at 10:30 +0200, D.S. Ljungmark wrote: Ah. That means we have to deploy the primary connections as well. Right now those are auto generated and not stored persistently. I'll try that, any thing else I can try? On 16 Jul 2014 10:24, Thomas Haller thal...@redhat.com wrote: On Wed, 2014-07-16 at 02:59 +0200, D.S. Ljungmark wrote: So, I have now something that works. it can connect to vpn manually. Next up, how do I get autoconnect to work? I thought connection.autoconnect was enough, but appearantly that's not the case. What am I missing? ipv4 + ipv6 network comes up normally as it should. [[ I did not test this myself, but I think... ]] connection.autoconnect is ignored by VPN type connections. What might work for you, is setting the connection.secondaries option of the parent ethernet/wifi-connection. One downside of this is that the parent connection is not part of the VPN-keyfile that you want to deploy. Thomas You could also use dispatcher scripts. See `man NetworkManager`. You need to enable NetworkManager-dispatcher service (not sure how that works on Debian. On Fedora you would `systemctl enable NetworkManager-dispatcher`. Maybe it already works). then ads a root-owned script -- with proper access rights(?) -- to /etc/NetworkManager/dispatcher.d It can react on the status changes and call `nmcli connection up id my-vpn`. Downside: if for some reason the establishing of the VPN fails, users might communicate insecurely. And there is a short time after the parent interface connects, where the traffic does not yet go over the VPN. I think you could work around that, by setting never-default=no in the parent connection and/or not configuring any routes there (ignore-auto-routes?)... but then you must again deploy a parent connection... Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Headless VPN connections
On Wed, 2014-07-16 at 10:51 +0200, D.S. Ljungmark wrote: That sounds like a working method. I'm less worried about the cleartext hole as the VPN is for internal and debugging use. Dispatcher vs making the default connection persistent are about the same, which method is better supported and gives better guarantees that things work reliably? I think both methods should be reliable (provided your dispatcher-script behaves correctly). connection.secondaries seams easier to me. Thomas On 16 Jul 2014 10:43, Thomas Haller thal...@redhat.com wrote: On Wed, 2014-07-16 at 10:30 +0200, D.S. Ljungmark wrote: Ah. That means we have to deploy the primary connections as well. Right now those are auto generated and not stored persistently. I'll try that, any thing else I can try? On 16 Jul 2014 10:24, Thomas Haller thal...@redhat.com wrote: On Wed, 2014-07-16 at 02:59 +0200, D.S. Ljungmark wrote: So, I have now something that works. it can connect to vpn manually. Next up, how do I get autoconnect to work? I thought connection.autoconnect was enough, but appearantly that's not the case. What am I missing? ipv4 + ipv6 network comes up normally as it should. [[ I did not test this myself, but I think... ]] connection.autoconnect is ignored by VPN type connections. What might work for you, is setting the connection.secondaries option of the parent ethernet/wifi-connection. One downside of this is that the parent connection is not part of the VPN-keyfile that you want to deploy. Thomas You could also use dispatcher scripts. See `man NetworkManager`. You need to enable NetworkManager-dispatcher service (not sure how that works on Debian. On Fedora you would `systemctl enable NetworkManager-dispatcher`. Maybe it already works). then ads a root-owned script -- with proper access rights(?) -- to /etc/NetworkManager/dispatcher.d It can react on the status changes and call `nmcli connection up id my-vpn`. Downside: if for some reason the establishing of the VPN fails, users might communicate insecurely. And there is a short time after the parent interface connects, where the traffic does not yet go over the VPN. I think you could work around that, by setting never-default=no in the parent connection and/or not configuring any routes there (ignore-auto-routes?)... but then you must again deploy a parent connection... Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
recent update makes me crazy...
Hi, One of the recent upgrade continuously trying to destroy my brain by changing my virtual bridge configs... I don't have a very complicated config, one physical ethernet, one wireless and five virtual networks for my KVM machines. It was ok for several months, but after one of the recent update I cannot enable static addressing for my bridges. If I set-up the interface correctly (I mean using static address) and I restart NetworkManager my bridge interfaces are duplicated and NM creates another ones with DHCP enabled... crazy... I'm not sure if this is because virt-manager or nm this is why I post on both list Here is my versions Name: NetworkManager Arch: x86_64 Epoch : 1 Version : 0.9.9.1 Release : 4.git20140319.fc20 Installed Packages Name: virt-manager Arch: noarch Version : 1.0.1 Release : 3.fc20 Any idea? Thank you L: ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [virt-tools-list] recent update makes me crazy...
On 07/16/2014 04:59 AM, Pal, Laszlo wrote: Hi, One of the recent upgrade continuously trying to destroy my brain by changing my virtual bridge configs... I don't have a very complicated config, one physical ethernet, one wireless and five virtual networks for my KVM machines. It was ok for several months, but after one of the recent update I cannot enable static addressing for my bridges. If I set-up the interface correctly (I mean using static address) and I restart NetworkManager my bridge interfaces are duplicated and NM creates another ones with DHCP enabled... crazy... I'm not sure if this is because virt-manager or nm this is why I post on both list Here is my versions Name: NetworkManager Arch: x86_64 Epoch : 1 Version : 0.9.9.1 Release : 4.git20140319.fc20 Installed Packages Name: virt-manager Arch: noarch Version : 1.0.1 Release : 3.fc20 virt-manager/libvirt shouldn't be doing anything with running dhcp on your bridge, so I imagine this is NetworkManager related. - Cole ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: recent update makes me crazy...
Am 16.07.2014 10:59, schrieb Pal, Laszlo: Hi, One of the recent upgrade continuously trying to destroy my brain by changing my virtual bridge configs... I don't have a very complicated config, one physical ethernet, one wireless and five virtual networks for my KVM machines. It was ok for several months, but after one of the recent update I cannot enable static addressing for my bridges. If I set-up the interface correctly (I mean using static address) and I restart NetworkManager my bridge interfaces are duplicated and NM creates another ones with DHCP enabled... crazy... I'm not sure if this is because virt-manager or nm this is why I post on both list [1] and [2] might be related here. In the Debian package I currently ship [3], to not make NM manage any virtual devices, since I saw a similar behaviour as yours (NM tried to run DHCP on the vbox interfaces). Hope that helps, Michael [1] https://bugzilla.gnome.org/show_bug.cgi?id=731014#c27 [2] https://bugzilla.gnome.org/show_bug.cgi?id=732998 [3] http://anonscm.debian.org/gitweb/?p=pkg-utopia/network-manager.git;a=blob;f=debian/patches/0005-Mark-virtual-ethernet-interfaces-as-unmanaged.patch;hb=HEAD -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Request for discussion: patch - remove also request dhcpv6.server-id
Hi,
As already observed in the thread dhcpv6-problem some devices are confused
by option request dhcpv6.server-id.
I looked a little bit in to RFC 3736 and 3315. But I still don't know what is
correct.
Do you need the server-id, in case they are more than one servers in your LAN?
Is a empty server-id request a valid request? ( in case of a selection: does
empty mean all or nothing?)
Why doesn't windows send this request?
Because I don't see any disadvantages I propose to remove this request.
At the moment I know three devices which would work with this patch.
ZTE 823D
ZTEMF93E
alcatel one touch W800Z (tct-mobile) alias Telekom Speedsick LTE IV
and I don't know any device which would stop working.
Regards,
Thomas Schäfer
diff -ur a/NetworkManager-0.9.10/src/dhcp-manager/nm-dhcp-dhclient-utils.c b/NetworkManager-0.9.10/src/dhcp-manager/nm-dhcp-dhclient-utils.c
--- a/NetworkManager-0.9.10/src/dhcp-manager/nm-dhcp-dhclient-utils.c 2014-07-04 02:32:13.0 +0200
+++ b/NetworkManager-0.9.10/src/dhcp-manager/nm-dhcp-dhclient-utils.c 2014-07-16 22:00:08.333854069 +0200
@@ -225,7 +225,6 @@
add_also_request (alsoreq, dhcp6.name-servers);
add_also_request (alsoreq, dhcp6.domain-search);
add_also_request (alsoreq, dhcp6.client-id);
- add_also_request (alsoreq, dhcp6.server-id);
} else {
add_ip4_config (new_contents, dhcp_client_id, hostname);
add_also_request (alsoreq, rfc3442-classless-static-routes);
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Request for discussion: patch - remove also request dhcpv6.server-id
Hi, http://www.ietf.org/rfc/rfc3315.txt 15.12. Information-request Message Clients MUST discard any received Information-request messages. Servers MUST discard any received Information-request message that meets any of the following conditions: - The message includes a Server Identifier option and the DUID in the option does not match the server's DUID. - The message includes an IA option. Is the behavior of the devices correct? Are there other RFCs (e.g. RFC 4361, RFC 5494, RFC 6221, RFC 6422, RFC 6644, RFC 7083, RFC 7227 ) with different updated rules? Or I am completely wrong? (because of mixing Server Identifier and Option Request Server Identifier?) Regards, Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM refuses to manage a VLAN
On Tue, 15 Jul 2014 11:12:42 -0500 Dan Williams d...@redhat.com wrote: nmcli con mod my-wifi ipv4.method manual ipv4.addresses 192.168.1.2/24, 10.10.1.5/8 wifi.ssid blahblah If you try out F21 or RHEL7, are these issues solved? Indeed, it works on NetworkManager-0.9.9.1-13.git20140326.4dba720.el7, thanks a lot! -- Pete ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
How to set ipv4 default route
Greetings: Looks like I'm not done with user's questions yet. This time I'm failing at something as basic as setting a default route. It looks like this: [root@localhost ~]# nmcli c mod eth0 ipv4.routes 'default 192.168.129.17' Error: failed to modify ipv4.routes: invalid IPv4 route 'default'. [root@localhost ~]# nmcli c mod eth0 ipv4.routes '0.0.0.0/0 192.168.129.17' ** (process:2380): CRITICAL **: nm_ip4_route_set_prefix: assertion `prefix 0' failed Error: Failed to modify connection 'eth0': (32) ipv4.routes: 1. route is invalid [root@localhost ~]# [root@localhost ~]# nmcli c mod eth0 ipv4.routes '0.0.0.0 192.168.129.17' Error: Failed to modify connection 'eth0': (32) ipv4.routes: 1. route is invalid = this one has prefix /32, probably Clearly I'm missing something too obvious! What's interesting, the way to modify the ipv4.routes is not discussed in any docs. Not in nmcli(1) certainly, but neither in nmcli-examples(5). Still, NetworkManager.conf(5) contains this tantalizing hint: Remember that NetworkManager controls the default route, so because the interface is ignored, NetworkManager may assign the default route to some other interface. So... Perhaps the default route is not even set in the connection properties. But I cannot figure it out. -- Pete ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: How to set ipv4 default route
On Wed, 16 Jul 2014 16:48:24 -0600 Pete Zaitcev zait...@redhat.com wrote: [root@localhost ~]# nmcli c mod eth0 ipv4.routes 'default 192.168.129.17' Error: failed to modify ipv4.routes: invalid IPv4 route 'default'. Still, NetworkManager.conf(5) contains this tantalizing hint: Remember that NetworkManager controls the default route, so because the interface is ignored, NetworkManager may assign the default route to some other interface. I know, my shame is going to remain in the list archive forever. The right way to do it is obvious: nmcli c mod eth0 ipv4.addresses '191.168.129.23/28 192.168.129.17' nmcli c mod eth0 ipv6.addresses 'fd2d:acfb:74cc:3::7/64 fd2d:acfb:74cc:3::1' -- P ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
