failure with bridge devices
I'm running openSUSE Tumbleweed, with GNOME 3.16.2 and NM 1.0.6, and have odd issues with networking. Initially GNOME automatically configured the onboard ethernet and named it "Wired Connection 1". I added a few VPN connections and all was fine. A few weeks later I finally got around to reenable my winxp-tax VM. For this I needed a bridge. The GNOME UI is appearently unable to handle bridge. I was unable to get online, under the hood only the onboard connection was enabled. Later I found nm-connection-editor. This showed the bridge devices etc. But in the end, since both seem to disagree about what is configured, I removed the related config files from /etc/NetworkManager/system-connections, used nm-connection-editor to configure a bridge with the onboard ethernet. After a reboot it finally worked. The GNOME UI is still unable to recognize the bridge connection. But in the end I was able to run the VM and all was fine again. With todays TW snapshot the IPv4 part of the connection did not get up. I found the nmcli command. It showed the bridge is online, but no IPv4 route was set. Dowing down and up showed that only the bridge came up, but not the onboard device. Trying the GNOME UI did not get a connection either. To my surprise, once I ran 'nmcli connection up bridge' the established onboard connection from GNOME changed something, now the bridge came up fine including IPv4. Up to now only IPv6 was usable to get outside. So my questions: Are there known bugs in the cooperation between NM and GNOME? Are bridge devices fully supported? If so, why did NM not bringup onboard before configuring bridge? Does NM rely on the iproute2 package in any way? Below is the output of what I configured with 'nm-connection-editor'. Why is that output even localized?! Olaf nmcli connection show br0-onboard connection.id: br0-onboard connection.uuid:e28ba628-68ec-4893-8fbd-49846c89009a connection.interface-name: enp2s0 connection.type:802-3-ethernet connection.autoconnect: yes connection.autoconnect-priority:0 connection.timestamp: 1443421196 connection.read-only: no connection.permissions: connection.zone:-- connection.master: br0 connection.slave-type: bridge connection.autoconnect-slaves: -1 (default) connection.secondaries: connection.gateway-ping-timeout:0 connection.metered: unknown 802-3-ethernet.port:-- 802-3-ethernet.speed: 0 802-3-ethernet.duplex: full 802-3-ethernet.auto-negotiate: yes 802-3-ethernet.mac-address: 1C:C1:DE:B9:BB:48 802-3-ethernet.cloned-mac-address: -- 802-3-ethernet.mac-address-blacklist: 802-3-ethernet.mtu: auto 802-3-ethernet.s390-subchannels: 802-3-ethernet.s390-nettype:-- 802-3-ethernet.s390-options: 802-3-ethernet.wake-on-lan: default 802-3-ethernet.wake-on-lan-password:-- bridge-port.priority: 32 bridge-port.path-cost: 100 bridge-port.hairpin-mode: no nmcli connection show bridge connection.id: bridge connection.uuid:7dcdbbf1-26bb-4981-a837-a617d5de88f6 connection.interface-name: br0 connection.type:bridge connection.autoconnect: yes connection.autoconnect-priority:0 connection.timestamp: 1443421195 connection.read-only: no connection.permissions: connection.zone:-- connection.master: -- connection.slave-type: -- connection.autoconnect-slaves: -1 (default) connection.secondaries: connection.gateway-ping-timeout:0 connection.metered: unknown ipv4.method:auto ipv4.dns: ipv4.dns-search: ipv4.addresses: ipv4.gateway: -- ipv4.routes: ipv4.route-metric: -1 ipv4.ignore-auto-routes:no ipv4.ignore-auto-dns: no ipv4.dhcp-client-id:-- ipv4.dhcp-send-hostname:yes ipv4.dhcp-hostname: -- ipv4.never-default: no ipv4.may-fail: yes ipv6.method:auto ipv6.dns: ipv6.dns-search: ipv6.addresses: ipv6.gateway: -- ipv6.routes: ipv6.route-metric: -1 ipv6.ignore-aut
vpn password stored in plain text
Why is the VPN password stored in plain text in /etc/NetworkManager/system-connections? Is there a way to let the GUI ask for it every time? Olaf ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM and IETF MIF working group
On Mon, 2015-09-07 at 12:05 +0200, Stjepan Groš wrote: > > Two colleagues of mine and I started to work on MIF implementation on > Fedora. In case someone doesn't know, IETF MIF working group ( > https://datatracker.ietf.org/wg/mif/charter/) tries to solve the > problems of a single node having multiple parallel connections to > different destinations (Internet, VPN, some private networks, etc.). Please ensure you take proxies into account. If my local DHCP server handed me a proxy PAC file, and if I connect to a split-tunnel VPN which *also* provides a proxy PAC file, I expect that requests I make to to the company VPN (within its domain names and IP ranges) to use one proxy configuration, while requests to the Internet at large should use my local proxy. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation smime.p7s Description: S/MIME cryptographic signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM and IETF MIF working group
Just want to say that I have been trying (in OpenSUSE) to get a rather simple scenario working, but failed, probably due to kernel mechanics: - main connection receives all traffic destined for port 80, 443. - VPN receives all else. I just consider it a more special case of directing VPN traffic to only the VPN network (no forwarding/routing at the end node). It required a few simple steps: - tag (SYN) packages for 80,443 with a mark - use the fwmark as an iproute rule - the rule sends the traffic to a different routing table Unfortunately although the routing seems to work, the traffic gets returned but not progressed by the kernel apparently due to some blocking or safety measure. I could not get around it, though I tried everything I could find on the web. A fourth step that may be required is: - snat the outgoing packages to match the interface they are now sent out on (meaning to match its ip address) such that a reverse route will coincide with the outgoing route that the kernel/routing system has chosen for the outgoing packets. I thought it was going to be a simple thing to setup and though I spent easily 4-5 hours on it, I could not get it to work. Perhaps if this seems an interesting or important use case, someone who is more knowledgeable than me could look into it? It seems rather... that it would look really bad on Linux if this common use case is a near impossibility due to kernel mechanics or security measures, or whatever else is causing it. Not sure how else to phrase it. I mean that it would not be a selling point, that sort of stuff. You could even integrate it into NM if it did work. "Route only selected ports over this VPN" or "Route everything except selected ports over this VPN". Would really be awesome. Just wanted to say that. Regards, Bart. On Mon, 28 Sep 2015, David Woodhouse wrote: On Mon, 2015-09-07 at 12:05 +0200, Stjepan Groš wrote: Two colleagues of mine and I started to work on MIF implementation on Fedora. In case someone doesn't know, IETF MIF working group ( https://datatracker.ietf.org/wg/mif/charter/) tries to solve the problems of a single node having multiple parallel connections to different destinations (Internet, VPN, some private networks, etc.).___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: vpn password stored in plain text
On Mon, 2015-09-28 at 09:32 +0200, Olaf Hering wrote: > Why is the VPN password stored in plain text in > /etc/NetworkManager/system-connections? Is there a way to let the GUI > ask for it every time? Note that the file is read-only by root. If somebody has root on your machine, they can do a lot more than read your password. It's stored there because no "password flags" have been set for the password that tell NM where to get it from. If you set the "agent-owned" flag and the "always ask" flags on the password, either through the GUI or by editing the file in /etc, then NM will ask an agent for the password every time. Most desktop environments have an agent (eg, GNOME and KDE have their own) and there's also nm-applet. For vpnc for example, the user password is "xauthpassword" and the corresponding item to ask for it every time would be "xauthpassword-flags=3". For OpenVPN the user password is "password" and the corresponding item to ask for it every time is "password-flags=3". See also 'man nm-settings' and look for the "Secret flag types" section near the bottom. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: vpn password stored in plain text
Am 28.09.2015 um 17:00 schrieb Dan Williams: > On Mon, 2015-09-28 at 09:32 +0200, Olaf Hering wrote: >> Why is the VPN password stored in plain text in >> /etc/NetworkManager/system-connections? Is there a way to let the GUI >> ask for it every time? > > Note that the file is read-only by root. If somebody has root on your > machine, they can do a lot more than read your password. If the disk gets stolen the password is accessible. Thanks for your other suggestions, will work through them. Olaf ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: vpn password stored in plain text
On Mon, 2015-09-28 at 17:57 +0200, Olaf Hering wrote: > Am 28.09.2015 um 17:00 schrieb Dan Williams: > > On Mon, 2015-09-28 at 09:32 +0200, Olaf Hering wrote: > >> Why is the VPN password stored in plain text in > >> /etc/NetworkManager/system-connections? Is there a way to let the GUI > >> ask for it every time? > > > > Note that the file is read-only by root. If somebody has root on your > > machine, they can do a lot more than read your password. > > If the disk gets stolen the password is accessible. Thanks for your > other suggestions, will work through them. Yes, that is correct. Although best practices suggest full-disk encryption on anything that can walk away, plus two-factor "something you know and something you have" for VPNs. But yes, setting the flags in the file and removing the password should ensure that the password is not stored on-disk. You can also set the flags to '1' (agent-owned) and the common agents like GNOME and KDE will store the password in their respective keyrings/wallets that is protected by another password. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: failure with bridge devices
Am 28.09.2015 um 09:05 schrieb Olaf Hering: > connection.autoconnect-slaves: -1 (default) Did I miss that knob in the GUI? Setting it to 1 with "nmcli connection edit bridge" seems to fix the "up" command. Olaf ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: vpn password stored in plain text
Am 28.09.2015 um 18:09 schrieb Dan Williams: > Yes, that is correct. Although best practices suggest full-disk > encryption on anything that can walk away, plus two-factor "something > you know and something you have" for VPNs. But yes, setting the flags > in the file and removing the password should ensure that the password is > not stored on-disk. You can also set the flags to '1' (agent-owned) and > the common agents like GNOME and KDE will store the password in their > respective keyrings/wallets that is protected by another password. I poked around in nm-connection-editor and realized that the icon on the right side of the password fields is actually a mode selector. Now the setting is "ask always", which wipes the password string from /etc. Thanks again! Olaf ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM and IETF MIF working group
On 28.09.2015 11:48, David Woodhouse wrote: > On Mon, 2015-09-07 at 12:05 +0200, Stjepan Groš wrote: >> Two colleagues of mine and I started to work on MIF implementation on >> Fedora. In case someone doesn't know, IETF MIF working group ( >> https://datatracker.ietf.org/wg/mif/charter/) tries to solve the >> problems of a single node having multiple parallel connections to >> different destinations (Internet, VPN, some private networks, etc.). > Please ensure you take proxies into account. > > If my local DHCP server handed me a proxy PAC file, and if I connect to > a split-tunnel VPN which *also* provides a proxy PAC file, I expect > that requests I make to to the company VPN (within its domain names and > IP ranges) to use one proxy configuration, while requests to the > Internet at large should use my local proxy. > If I understand it correctly, PAC information received from DHCP is send by NM via DBus, but otherwise not used in any way? So, it is necessary to use some tool like proxydriver (https://github.com/jimlawton/proxydriver) that will modify system settings based on this info? In any case, this is interesting info because we didn't though of it. Namely, if browser is configured to use system proxy settings and it is placed within new namespace, then it might happen that wrong proxy is used, or global proxy settings are mixed up. SG signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
