Re: Lack of new OpenVPN SAML interoperability
Hi, On Sun, 2021-08-01 at 14:19 -0300, Marcus Diniz wrote: > Hello, > > First of all, I'm sorry to copy both gnome-network-list and > networkmanager-list, because I didn't know or couldn't recognize > which one would be the proper one to mention this fact. > > I've been trying to access my OpenVPN cloud account through the > 'Import profile' wizard that comes with Gnome Network. > > I simply go to Settings->Network, then on VPN panel I click on '+' > symbol, a new window appears, then I select 'Import from file...'. > Finally, after imported, when I try to connect, I receive the > following errors: How you create a profile does not matter much. What matters, is the actual settings in the profile (you see them with `nmcli connection show "$PROFILE"`) and which versions of NetworkManager, nm-openpvn and openvpn versions are used. > Aug 1 14:17:13 blackbox systemd[1]: NetworkManager- > dispatcher.service: Succeeded. > Aug 1 14:17:17 blackbox NetworkManager[1266]: > [1627838237.3179] audit: op="connection-activate" uuid="29cf64b5- > 5104-4953-83e2-367bf0a140ed" > name="device_1_mdiniz@moneytrans_eu@secunit.openvpn.com_[Sao_Paulo]" > pid=2455 uid=1000 result="success" > Aug 1 14:17:17 blackbox NetworkManager[1266]: > [1627838237.3261] vpn-connection[0x559b36c6c510,29cf64b5-5104-4953- > 83e2- > 367bf0a140ed,"device_1_mdiniz@moneytrans_eu@secunit.openvpn.com_[Sao_ > Paul: Started the VPN service, PID 42217 > Aug 1 14:17:17 blackbox NetworkManager[1266]: > [1627838237.3367] vpn-connection[0x559b36c6c510,29cf64b5-5104-4953- > 83e2- > 367bf0a140ed,"device_1_mdiniz@moneytrans_eu@secunit.openvpn.com_[Sao_ > Paul: Saw the service appear; activating connection > Aug 1 14:17:17 blackbox NetworkManager[1266]: > [1627838237.3699] vpn-connection[0x559b36c6c510,29cf64b5-5104-4953- > 83e2- > 367bf0a140ed,"device_1_mdiniz@moneytrans_eu@secunit.openvpn.com_[Sao_ > Paul: VPN plugin: state changed: starting (3) > Aug 1 14:17:17 blackbox NetworkManager[1266]: > [1627838237.3705] vpn-connection[0x559b36c6c510,29cf64b5-5104-4953- > 83e2- > 367bf0a140ed,"device_1_mdiniz@moneytrans_eu@secunit.openvpn.com_[Sao_ > Paul: VPN connection: (ConnectInteractive) reply received > Aug 1 14:17:17 blackbox nm-openvpn[42221]: OpenVPN 2.4.7 x86_64-pc- > linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] > [AEAD] built on Jul 19 2021 > Aug 1 14:17:17 blackbox nm-openvpn[42221]: library versions: OpenSSL > 1.1.1f 31 Mar 2020, LZO 2.10 > Aug 1 14:17:17 blackbox nm-openvpn[42221]: NOTE: the current -- > script-security setting may allow this configuration to call user- > defined scripts > Aug 1 14:17:17 blackbox nm-openvpn[42221]: TCP/UDP: Preserving > recently used remote address: [AF_INET]209.14.3.201:1194 > Aug 1 14:17:17 blackbox nm-openvpn[42221]: UDP link local: (not > bound) > Aug 1 14:17:17 blackbox nm-openvpn[42221]: UDP link remote: > [AF_INET]209.14.3.201:1194 > Aug 1 14:17:17 blackbox nm-openvpn[42221]: NOTE: chroot will be > delayed because of --client, --pull, or --up-delay > Aug 1 14:17:17 blackbox nm-openvpn[42221]: NOTE: UID/GID downgrade > will be delayed because of --client, --pull, or --up-delay > Aug 1 14:17:17 blackbox nm-openvpn[42221]: [br-gru-dc2- > g1.cloud.openvpn.net] Peer Connection Initiated with > [AF_INET]209.14.3.201:1194 > Aug 1 14:17:18 blackbox nm-openvpn[42221]: AUTH: Received control > message: AUTH_FAILED,SSO Auth Failed due to lack of client support > Aug 1 14:17:18 blackbox nm-openvpn[42221]: SIGUSR1[soft,auth- > failure] received, process restarting > Aug 1 14:17:23 blackbox NetworkManager[1266]: > [1627838243.8605] vpn-connection[0x559b36c6c510,29cf64b5-5104-4953- > 83e2- > 367bf0a140ed,"device_1_mdiniz@moneytrans_eu@secunit.openvpn.com_[Sao_ > Paul: VPN plugin: requested secrets; state connect (4) > Aug 1 14:17:25 blackbox nm-openvpn[42221]: NOTE: the current -- > script-security setting may allow this configuration to call user- > defined scripts > Aug 1 14:17:25 blackbox nm-openvpn[42221]: TCP/UDP: Preserving > recently used remote address: [AF_INET]209.14.3.201:1194 > Aug 1 14:17:25 blackbox nm-openvpn[42221]: UDP link local: (not > bound) > Aug 1 14:17:25 blackbox nm-openvpn[42221]: UDP link remote: > [AF_INET]209.14.3.201:1194 > Aug 1 14:17:25 blackbox nm-openvpn[42221]: [br-gru-dc2- > g1.cloud.openvpn.net] Peer Connection Initiated with > [AF_INET]209.14.3.201:1194 > Aug 1 14:17:26 blackbox nm-openvpn[42221]: AUTH: Received control > message: AUTH_FAILED,SSO Auth Failed due to lack of client support > Aug 1 14:17:26 blackbox nm-openvpn[42221]: SIGUSR1[soft,auth-
Lack of new OpenVPN SAML interoperability
Hello, First of all, I'm sorry to copy both gnome-network-list and networkmanager-list, because I didn't know or couldn't recognize which one would be the proper one to mention this fact. I've been trying to access my OpenVPN cloud account through the 'Import profile' wizard that comes with Gnome Network. I simply go to Settings->Network, then on VPN panel I click on '+' symbol, a new window appears, then I select '*Import from file...*'. Finally, after imported, when I try to connect, I receive the following errors: Aug 1 14:17:13 blackbox systemd[1]: NetworkManager-dispatcher.service: Succeeded. Aug 1 14:17:17 blackbox NetworkManager[1266]: [1627838237.3179] audit: op="connection-activate" uuid="29cf64b5-5104-4953-83e2-367bf0a140ed" name="device_1_mdiniz@moneytrans_eu@secunit.openvpn.com_[Sao_Paulo]" pid=2455 uid=1000 result="success" Aug 1 14:17:17 blackbox NetworkManager[1266]: [1627838237.3261] vpn-connection[0x559b36c6c510,29cf64b5-5104-4953-83e2-367bf0a140ed,"device_1_mdiniz@moneytrans_eu@secunit.openvpn.com_[Sao_Paul: Started the VPN service, PID 42217 Aug 1 14:17:17 blackbox NetworkManager[1266]: [1627838237.3367] vpn-connection[0x559b36c6c510,29cf64b5-5104-4953-83e2-367bf0a140ed,"device_1_mdiniz@moneytrans_eu@secunit.openvpn.com_[Sao_Paul: Saw the service appear; activating connection Aug 1 14:17:17 blackbox NetworkManager[1266]: [1627838237.3699] vpn-connection[0x559b36c6c510,29cf64b5-5104-4953-83e2-367bf0a140ed,"device_1_mdiniz@moneytrans_eu@secunit.openvpn.com_[Sao_Paul: VPN plugin: state changed: starting (3) Aug 1 14:17:17 blackbox NetworkManager[1266]: [1627838237.3705] vpn-connection[0x559b36c6c510,29cf64b5-5104-4953-83e2-367bf0a140ed,"device_1_mdiniz@moneytrans_eu@secunit.openvpn.com_[Sao_Paul: VPN connection: (ConnectInteractive) reply received Aug 1 14:17:17 blackbox nm-openvpn[42221]: OpenVPN 2.4.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jul 19 2021 Aug 1 14:17:17 blackbox nm-openvpn[42221]: library versions: OpenSSL 1.1.1f 31 Mar 2020, LZO 2.10 Aug 1 14:17:17 blackbox nm-openvpn[42221]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Aug 1 14:17:17 blackbox nm-openvpn[42221]: TCP/UDP: Preserving recently used remote address: [AF_INET]209.14.3.201:1194 Aug 1 14:17:17 blackbox nm-openvpn[42221]: UDP link local: (not bound) Aug 1 14:17:17 blackbox nm-openvpn[42221]: UDP link remote: [AF_INET] 209.14.3.201:1194 Aug 1 14:17:17 blackbox nm-openvpn[42221]: NOTE: chroot will be delayed because of --client, --pull, or --up-delay Aug 1 14:17:17 blackbox nm-openvpn[42221]: NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay Aug 1 14:17:17 blackbox nm-openvpn[42221]: [br-gru-dc2-g1.cloud.openvpn.net] Peer Connection Initiated with [AF_INET]209.14.3.201:1194 Aug 1 14:17:18 blackbox nm-openvpn[42221]: AUTH: Received control message: AUTH_FAILED,SSO Auth Failed due to lack of client support Aug 1 14:17:18 blackbox nm-openvpn[42221]: SIGUSR1[soft,auth-failure] received, process restarting Aug 1 14:17:23 blackbox NetworkManager[1266]: [1627838243.8605] vpn-connection[0x559b36c6c510,29cf64b5-5104-4953-83e2-367bf0a140ed,"device_1_mdiniz@moneytrans_eu@secunit.openvpn.com_[Sao_Paul: VPN plugin: requested secrets; state connect (4) Aug 1 14:17:25 blackbox nm-openvpn[42221]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Aug 1 14:17:25 blackbox nm-openvpn[42221]: TCP/UDP: Preserving recently used remote address: [AF_INET]209.14.3.201:1194 Aug 1 14:17:25 blackbox nm-openvpn[42221]: UDP link local: (not bound) Aug 1 14:17:25 blackbox nm-openvpn[42221]: UDP link remote: [AF_INET] 209.14.3.201:1194 Aug 1 14:17:25 blackbox nm-openvpn[42221]: [br-gru-dc2-g1.cloud.openvpn.net] Peer Connection Initiated with [AF_INET]209.14.3.201:1194 Aug 1 14:17:26 blackbox nm-openvpn[42221]: AUTH: Received control message: AUTH_FAILED,SSO Auth Failed due to lack of client support Aug 1 14:17:26 blackbox nm-openvpn[42221]: SIGUSR1[soft,auth-failure] received, process restarting While using openvpn3 package it works flawlessly. I wonder, are there any plans to add openvpn3 support for the VPNs? Thank you, Marcus ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Problems with OpenVPN client conf having several remotes
On Mon, 2021-06-14 at 17:52 +, Samuel Le Thiec via networkmanager-list wrote: > Hello again:) > > I encountered two problems with an openvpn client conf having several remotes. > > The first problem occurs when importing a openvpn client config having > multiple remotes > mixing udp & tcp and using the "implicit udp syntax": > > $ grep ^remote openvpn.conf > remote ovpn.mydomain.com > remote ovpn.mydomain.com 53 > remote ovpn.mydomain.com 1194 tcp > > When imported in Network Manager, this translates to (in the vpn settings: > Identity → > General → Gateway) : > ovpn.mydomain.com, ovpn.mydomain.com:53, ovpn.mydomain.com:1194:tcp > > When I try to enable the vpn connection, it goes back to being disabled > immediately. > Here > is the error message I can see in the journal: > Options error: --explicit-exit-notify can only be used with --proto udp > > Now, if I change the gateway vpn setting to: > ovpn.mydomain.com:1194:udp, ovpn.mydomain.com:53:udp, > ovpn.mydomain.com:1194:tcp > > Then, I can enable the vpn and it looks like it's working... > > **BUT** > > When I look closer, the fallback/try on the other remotes does not seem to > work: on the > journal, I can see the tries on the first remote (IPv6, then IPv4), then I > see this log > entry: > > Jun 14 19:44:31 nsfw nm-openvpn-serv[333567]: Connect timer expired, > disconnecting. > > This "fallback mechanism" works fine when invoking openvpn directly. Is there > something > else to do to have it working with Network Manager? Hello, I just would like to make sure this message does not get lost in the way. Let me summarise it, I think there is two problems with the openvpn functionnality within Network Manager : 1. When importing an openvpn config file: NM can't start a openvpn 'connection' with a remote using implicit UDP notation and a tcp (server1:port1 server2:port2:tcp) (see above) 2. The fallback mechanism does not seem to work with NetworkManager, probably because it takes too long and NM tags the connection as failing: is there a way to force it to continue trying indefinitely? Thank you, samuel > > Any help greatly appreciated! > > Thanks, > > samuel > > PS: I'm using: > > $ NetworkManager --version > 1.30.4-1.fc34 > > > ___ > 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
Problems with OpenVPN client conf having several remotes
Hello again:) I encountered two problems with an openvpn client conf having several remotes. The first problem occurs when importing a openvpn client config having multiple remotes mixing udp & tcp and using the "implicit udp syntax": $ grep ^remote openvpn.conf ovpn.mydomain.com ovpn.mydomain.com 53 ovpn.mydomain.com 1194 tcp When imported in Network Manager, this translates to (in the vpn settings: Identity → General → Gateway) : ovpn.mydomain.com, ovpn.mydomain.com:53, ovpn.mydomain.com:1194:tcp When I try to enable the vpn connection, it goes back to being disabled immediately. Here is the error message I can see in the journal: Options error: --explicit-exit-notify can only be used with --proto udp Now, if I change the gateway vpn setting to: ovpn.mydomain.com:1194:udp, ovpn.mydomain.com:53:udp, ovpn.mydomain.com:1194:tcp Then, I can enable the vpn and it looks like it's working... **BUT** When I look closer, the fallback/try on the other remotes does not seem to work: on the journal, I can see the tries on the first remote (IPv6, then IPv4), then I see this log entry: Jun 14 19:44:31 nsfw nm-openvpn-serv[333567]: Connect timer expired, disconnecting. This "fallback mechanism" works fine when invoking openvpn directly. Is there something else to do to have it working with Network Manager? Any help greatly appreciated! Thanks, samuel PS: I'm using: $ NetworkManager --version 1.30.4-1.fc34 ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Trouble converting full OpenVPN tunnel to split tunnel
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, 2021-02-03 at 12:25 +0100, Thomas Haller wrote: > On Wed, 2021-02-03 at 12:08 +0100, Chris Coutinho via networkmanager- > list wrote: > > Hello NM folks, > > > > I'm running into a problem converting an OpenVPN "full" tunnel > > configuration to > > a split tunnel configuration. I've received an .ovpn file from a > > client which, > > by default, routes all my traffic through their VPN. I want to > > configure my VPN > > connection such that only traffic to/from resources within their > > network are > > routed through the VPN, and all other traffic is routed through > > whatever network > > I'm currently on. > > > > I'm running: > > - openSUSE Tumbleweed with Gnome > > - Network Manager 1.28.0 > > - NM OpenVPN Gnome plugin 1.8.12 > > > > I can modify the connection profile to route traffic to publicly > > accessible IP > > addresses through the VPN by manually setting the ipv4.dns and > > ipv4.routes > > options using nmcli. I'm able to modify the VPN connection profile as > > follows, > > which allows me to access publicly resolvable resources. > > > > # nmcli connection modify ignore-auto-dns=true > > # nmcli connection modify dns= <- Current LAN > > DNS > > # nmcli connection modify +ipv4.routes <- > > public > > # nmcli connection modify +ipv4.routes <- > > private > > > > By public/private here I mean I can access host-A with these options > > because my > > LAN DNS can resolve the IP address, meanwhie host-B is unresolvable > > and I can't > > figure out why. > > > > Connected to the full tunnel shows the following nslookup output for > > an > > "internal" host: > > > > $ nslookup > > Server: 8.8.8.8 > > Address: 8.8.8.8#53 > > > > Non-authoritative answer: > > Name: > > Address: 10.243.a.b > > Name: > > Address: 10.243.c.d > > Name: > > Address: 10.243.e.f > > > > If I'm connected to the "full" tunnel, inspecting the connection > > profile returns > > the following. I think the "IP4.ROUTE[1]" line means that all traffic > > is being > > sent through their gateway. > > > > > > $ nmcli connection show "Client VPN (Full)" > > GENERAL.NAME: Client VPN (Full) > > GENERAL.UUID: 6a647d45-1740-4a49-81d1- > > 6d49f5631a40 > > GENERAL.DEVICES: wlp0s20f3 > > GENERAL.IP-IFACE: wlp0s20f3 > > GENERAL.STATE: activated > > GENERAL.DEFAULT: yes > > GENERAL.DEFAULT6: no > > GENERAL.SPEC-OBJECT: > > /org/freedesktop/NetworkManager/ActiveConnection/2 > > GENERAL.VPN: yes > > GENERAL.DBUS-PATH: > > /org/freedesktop/NetworkManager/ActiveConnection/49 > > GENERAL.CON-PATH: > > /org/freedesktop/NetworkManager/Settings/29 > > GENERAL.ZONE: -- > > GENERAL.MASTER-PATH: > > /org/freedesktop/NetworkManager/Devices/3 > > IP4.ADDRESS[1]: a.b.c.d/23 > > IP4.GATEWAY: a.b.c.1 > > IP4.ROUTE[1]: dst = 0.0.0.0/0, nh = > > a.b.c.1, mt = 50 > > IP4.ROUTE[2]: dst = a.b.c.d/23, nh = > > 0.0.0.0, mt = 50 > > IP4.DNS[1]: a.b.c.d > > IP4.DNS[2]: a.b.c.d > > IP4.DOMAIN[1]: > > VPN.TYPE: openvpn > > VPN.USERNAME: > > VPN.GATEWAY: a.b.c.d:1194:udp, > > a.b.c.d:443:tcp > > VPN.BANNER: -- > > VPN.VPN-STATE: 5 - VPN connected > > VPN.CFG[1]: ca = /home/chris/.cert/nm- > > openvpn/client-ca.pem > > VPN.CFG[2]: cert = /home/chris/.cert/nm- > > openvpn/client-cert.pem > > VPN.CFG[3]: cert-pass-flags = 0 > > VPN.CFG[4]: cipher = AES-256-CBC > > VPN.CFG[5]: comp-lzo = no-by-default > > VPN.CFG[6]: connect-timeout = 4 > > VPN.C
Re: Trouble converting full OpenVPN tunnel to split tunnel
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, 2021-02-03 at 12:25 +0100, Thomas Haller wrote: > On Wed, 2021-02-03 at 12:08 +0100, Chris Coutinho via networkmanager- > list wrote: > > Hello NM folks, > > > > I'm running into a problem converting an OpenVPN "full" tunnel > > configuration to > > a split tunnel configuration. I've received an .ovpn file from a > > client which, > > by default, routes all my traffic through their VPN. I want to > > configure my VPN > > connection such that only traffic to/from resources within their > > network are > > routed through the VPN, and all other traffic is routed through > > whatever network > > I'm currently on. > > > > I'm running: > > - openSUSE Tumbleweed with Gnome > > - Network Manager 1.28.0 > > - NM OpenVPN Gnome plugin 1.8.12 > > > > I can modify the connection profile to route traffic to publicly > > accessible IP > > addresses through the VPN by manually setting the ipv4.dns and > > ipv4.routes > > options using nmcli. I'm able to modify the VPN connection profile as > > follows, > > which allows me to access publicly resolvable resources. > > > > # nmcli connection modify ignore-auto-dns=true > > # nmcli connection modify dns= <- Current LAN > > DNS > > # nmcli connection modify +ipv4.routes <- > > public > > # nmcli connection modify +ipv4.routes <- > > private > > > > By public/private here I mean I can access host-A with these options > > because my > > LAN DNS can resolve the IP address, meanwhie host-B is unresolvable > > and I can't > > figure out why. > > > > Connected to the full tunnel shows the following nslookup output for > > an > > "internal" host: > > > > $ nslookup > > Server: 8.8.8.8 > > Address: 8.8.8.8#53 > > > > Non-authoritative answer: > > Name: > > Address: 10.243.a.b > > Name: > > Address: 10.243.c.d > > Name: > > Address: 10.243.e.f > > > > If I'm connected to the "full" tunnel, inspecting the connection > > profile returns > > the following. I think the "IP4.ROUTE[1]" line means that all traffic > > is being > > sent through their gateway. > > > > > > $ nmcli connection show "Client VPN (Full)" > > GENERAL.NAME: Client VPN (Full) > > GENERAL.UUID: 6a647d45-1740-4a49-81d1- > > 6d49f5631a40 > > GENERAL.DEVICES: wlp0s20f3 > > GENERAL.IP-IFACE: wlp0s20f3 > > GENERAL.STATE: activated > > GENERAL.DEFAULT: yes > > GENERAL.DEFAULT6: no > > GENERAL.SPEC-OBJECT: > > /org/freedesktop/NetworkManager/ActiveConnection/2 > > GENERAL.VPN: yes > > GENERAL.DBUS-PATH: > > /org/freedesktop/NetworkManager/ActiveConnection/49 > > GENERAL.CON-PATH: > > /org/freedesktop/NetworkManager/Settings/29 > > GENERAL.ZONE: -- > > GENERAL.MASTER-PATH: > > /org/freedesktop/NetworkManager/Devices/3 > > IP4.ADDRESS[1]: a.b.c.d/23 > > IP4.GATEWAY: a.b.c.1 > > IP4.ROUTE[1]: dst = 0.0.0.0/0, nh = > > a.b.c.1, mt = 50 > > IP4.ROUTE[2]: dst = a.b.c.d/23, nh = > > 0.0.0.0, mt = 50 > > IP4.DNS[1]: a.b.c.d > > IP4.DNS[2]: a.b.c.d > > IP4.DOMAIN[1]: > > VPN.TYPE: openvpn > > VPN.USERNAME: > > VPN.GATEWAY: a.b.c.d:1194:udp, > > a.b.c.d:443:tcp > > VPN.BANNER: -- > > VPN.VPN-STATE: 5 - VPN connected > > VPN.CFG[1]: ca = /home/chris/.cert/nm- > > openvpn/client-ca.pem > > VPN.CFG[2]: cert = /home/chris/.cert/nm- > > openvpn/client-cert.pem > > VPN.CFG[3]: cert-pass-flags = 0 > > VPN.CFG[4]: cipher = AES-256-CBC > > VPN.CFG[5]: comp-lzo = no-by-default > > VPN.CFG[6]: connect-timeout = 4 > > VPN.C
Re: Trouble converting full OpenVPN tunnel to split tunnel
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, 2021-02-03 at 12:25 +0100, Thomas Haller wrote: > On Wed, 2021-02-03 at 12:08 +0100, Chris Coutinho via networkmanager- > list wrote: > > Hello NM folks, > > > > I'm running into a problem converting an OpenVPN "full" tunnel > > configuration to > > a split tunnel configuration. I've received an .ovpn file from a > > client which, > > by default, routes all my traffic through their VPN. I want to > > configure my VPN > > connection such that only traffic to/from resources within their > > network are > > routed through the VPN, and all other traffic is routed through > > whatever network > > I'm currently on. > > > > I'm running: > > - openSUSE Tumbleweed with Gnome > > - Network Manager 1.28.0 > > - NM OpenVPN Gnome plugin 1.8.12 > > > > I can modify the connection profile to route traffic to publicly > > accessible IP > > addresses through the VPN by manually setting the ipv4.dns and > > ipv4.routes > > options using nmcli. I'm able to modify the VPN connection profile as > > follows, > > which allows me to access publicly resolvable resources. > > > > # nmcli connection modify ignore-auto-dns=true > > # nmcli connection modify dns= <- Current LAN > > DNS > > # nmcli connection modify +ipv4.routes <- > > public > > # nmcli connection modify +ipv4.routes <- > > private > > > > By public/private here I mean I can access host-A with these options > > because my > > LAN DNS can resolve the IP address, meanwhie host-B is unresolvable > > and I can't > > figure out why. > > > > Connected to the full tunnel shows the following nslookup output for > > an > > "internal" host: > > > > $ nslookup > > Server: 8.8.8.8 > > Address: 8.8.8.8#53 > > > > Non-authoritative answer: > > Name: > > Address: 10.243.a.b > > Name: > > Address: 10.243.c.d > > Name: > > Address: 10.243.e.f > > > > If I'm connected to the "full" tunnel, inspecting the connection > > profile returns > > the following. I think the "IP4.ROUTE[1]" line means that all traffic > > is being > > sent through their gateway. > > > > > > $ nmcli connection show "Client VPN (Full)" > > GENERAL.NAME: Client VPN (Full) > > GENERAL.UUID: 6a647d45-1740-4a49-81d1- > > 6d49f5631a40 > > GENERAL.DEVICES: wlp0s20f3 > > GENERAL.IP-IFACE: wlp0s20f3 > > GENERAL.STATE: activated > > GENERAL.DEFAULT: yes > > GENERAL.DEFAULT6: no > > GENERAL.SPEC-OBJECT: > > /org/freedesktop/NetworkManager/ActiveConnection/2 > > GENERAL.VPN: yes > > GENERAL.DBUS-PATH: > > /org/freedesktop/NetworkManager/ActiveConnection/49 > > GENERAL.CON-PATH: > > /org/freedesktop/NetworkManager/Settings/29 > > GENERAL.ZONE: -- > > GENERAL.MASTER-PATH: > > /org/freedesktop/NetworkManager/Devices/3 > > IP4.ADDRESS[1]: a.b.c.d/23 > > IP4.GATEWAY: a.b.c.1 > > IP4.ROUTE[1]: dst = 0.0.0.0/0, nh = > > a.b.c.1, mt = 50 > > IP4.ROUTE[2]: dst = a.b.c.d/23, nh = > > 0.0.0.0, mt = 50 > > IP4.DNS[1]: a.b.c.d > > IP4.DNS[2]: a.b.c.d > > IP4.DOMAIN[1]: > > VPN.TYPE: openvpn > > VPN.USERNAME: > > VPN.GATEWAY: a.b.c.d:1194:udp, > > a.b.c.d:443:tcp > > VPN.BANNER: -- > > VPN.VPN-STATE: 5 - VPN connected > > VPN.CFG[1]: ca = /home/chris/.cert/nm- > > openvpn/client-ca.pem > > VPN.CFG[2]: cert = /home/chris/.cert/nm- > > openvpn/client-cert.pem > > VPN.CFG[3]: cert-pass-flags = 0 > > VPN.CFG[4]: cipher = AES-256-CBC > > VPN.CFG[5]: comp-lzo = no-by-default > > VPN.CFG[6]: connect-timeout = 4 > > VPN.C
Re: Trouble converting full OpenVPN tunnel to split tunnel
On Wed, 2021-02-03 at 12:08 +0100, Chris Coutinho via networkmanager- list wrote: > Hello NM folks, > > I'm running into a problem converting an OpenVPN "full" tunnel > configuration to > a split tunnel configuration. I've received an .ovpn file from a > client which, > by default, routes all my traffic through their VPN. I want to > configure my VPN > connection such that only traffic to/from resources within their > network are > routed through the VPN, and all other traffic is routed through > whatever network > I'm currently on. > > I'm running: > - openSUSE Tumbleweed with Gnome > - Network Manager 1.28.0 > - NM OpenVPN Gnome plugin 1.8.12 > > I can modify the connection profile to route traffic to publicly > accessible IP > addresses through the VPN by manually setting the ipv4.dns and > ipv4.routes > options using nmcli. I'm able to modify the VPN connection profile as > follows, > which allows me to access publicly resolvable resources. > > # nmcli connection modify ignore-auto-dns=true > # nmcli connection modify dns= <- Current LAN > DNS > # nmcli connection modify +ipv4.routes <- > public > # nmcli connection modify +ipv4.routes <- > private > > By public/private here I mean I can access host-A with these options > because my > LAN DNS can resolve the IP address, meanwhie host-B is unresolvable > and I can't > figure out why. > > Connected to the full tunnel shows the following nslookup output for > an > "internal" host: > > $ nslookup > Server: 8.8.8.8 > Address: 8.8.8.8#53 > > Non-authoritative answer: > Name: > Address: 10.243.a.b > Name: > Address: 10.243.c.d > Name: > Address: 10.243.e.f > > If I'm connected to the "full" tunnel, inspecting the connection > profile returns > the following. I think the "IP4.ROUTE[1]" line means that all traffic > is being > sent through their gateway. > > > $ nmcli connection show "Client VPN (Full)" > GENERAL.NAME: Client VPN (Full) > GENERAL.UUID: 6a647d45-1740-4a49-81d1- > 6d49f5631a40 > GENERAL.DEVICES: wlp0s20f3 > GENERAL.IP-IFACE: wlp0s20f3 > GENERAL.STATE: activated > GENERAL.DEFAULT: yes > GENERAL.DEFAULT6: no > GENERAL.SPEC-OBJECT: > /org/freedesktop/NetworkManager/ActiveConnection/2 > GENERAL.VPN: yes > GENERAL.DBUS-PATH: > /org/freedesktop/NetworkManager/ActiveConnection/49 > GENERAL.CON-PATH: > /org/freedesktop/NetworkManager/Settings/29 > GENERAL.ZONE: -- > GENERAL.MASTER-PATH: > /org/freedesktop/NetworkManager/Devices/3 > IP4.ADDRESS[1]: a.b.c.d/23 > IP4.GATEWAY: a.b.c.1 > IP4.ROUTE[1]: dst = 0.0.0.0/0, nh = > a.b.c.1, mt = 50 > IP4.ROUTE[2]: dst = a.b.c.d/23, nh = > 0.0.0.0, mt = 50 > IP4.DNS[1]: a.b.c.d > IP4.DNS[2]: a.b.c.d > IP4.DOMAIN[1]: > VPN.TYPE: openvpn > VPN.USERNAME: > VPN.GATEWAY: a.b.c.d:1194:udp, > a.b.c.d:443:tcp > VPN.BANNER: -- > VPN.VPN-STATE: 5 - VPN connected > VPN.CFG[1]: ca = /home/chris/.cert/nm- > openvpn/client-ca.pem > VPN.CFG[2]: cert = /home/chris/.cert/nm- > openvpn/client-cert.pem > VPN.CFG[3]: cert-pass-flags = 0 > VPN.CFG[4]: cipher = AES-256-CBC > VPN.CFG[5]: comp-lzo = no-by-default > VPN.CFG[6]: connect-timeout = 4 > VPN.CFG[7]: connection-type = password- > tls > VPN.CFG[8]: dev = tun > VPN.CFG[9]: dev-type = tun > VPN.CFG[10]: key = /home/chris/.cert/nm- > openvpn/client-key.pem > VPN.CFG[11]: ns-cert-type = server > VPN.CFG[12]: password-flags = 1 > VPN.CFG[13]: remote = a.b.c.d:1194:udp, > a.b.c.d:443:tcp > VPN.CFG[14]: reneg-seconds = 604800 > VPN.CFG[15]: ta = /home/chris/.cert/nm- > openvpn/clien
Trouble converting full OpenVPN tunnel to split tunnel
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello NM folks, I'm running into a problem converting an OpenVPN "full" tunnel configuration to a split tunnel configuration. I've received an .ovpn file from a client which, by default, routes all my traffic through their VPN. I want to configure my VPN connection such that only traffic to/from resources within their network are routed through the VPN, and all other traffic is routed through whatever network I'm currently on. I'm running: - - openSUSE Tumbleweed with Gnome - - Network Manager 1.28.0 - - NM OpenVPN Gnome plugin 1.8.12 I can modify the connection profile to route traffic to publicly accessible IP addresses through the VPN by manually setting the ipv4.dns and ipv4.routes options using nmcli. I'm able to modify the VPN connection profile as follows, which allows me to access publicly resolvable resources. # nmcli connection modify ignore-auto-dns=true # nmcli connection modify dns=<- Current LAN DNS # nmcli connection modify +ipv4.routes <- public # nmcli connection modify +ipv4.routes <- private By public/private here I mean I can access host-A with these options because my LAN DNS can resolve the IP address, meanwhie host-B is unresolvable and I can't figure out why. Connected to the full tunnel shows the following nslookup output for an "internal" host: $ nslookup Server: 8.8.8.8 Address:8.8.8.8#53 Non-authoritative answer: Name: Address: 10.243.a.b Name: Address: 10.243.c.d Name: Address: 10.243.e.f If I'm connected to the "full" tunnel, inspecting the connection profile returns the following. I think the "IP4.ROUTE[1]" line means that all traffic is being sent through their gateway. $ nmcli connection show "Client VPN (Full)" GENERAL.NAME: Client VPN (Full) GENERAL.UUID: 6a647d45-1740-4a49-81d1-6d49f5631a40 GENERAL.DEVICES:wlp0s20f3 GENERAL.IP-IFACE: wlp0s20f3 GENERAL.STATE: activated GENERAL.DEFAULT:yes GENERAL.DEFAULT6: no GENERAL.SPEC-OBJECT: /org/freedesktop/NetworkManager/ActiveConnection/2 GENERAL.VPN:yes GENERAL.DBUS-PATH: /org/freedesktop/NetworkManager/ActiveConnection/49 GENERAL.CON-PATH: /org/freedesktop/NetworkManager/Settings/29 GENERAL.ZONE: -- GENERAL.MASTER-PATH: /org/freedesktop/NetworkManager/Devices/3 IP4.ADDRESS[1]: a.b.c.d/23 IP4.GATEWAY:a.b.c.1 IP4.ROUTE[1]: dst = 0.0.0.0/0, nh = a.b.c.1, mt = 50 IP4.ROUTE[2]: dst = a.b.c.d/23, nh = 0.0.0.0, mt = 50 IP4.DNS[1]: a.b.c.d IP4.DNS[2]: a.b.c.d IP4.DOMAIN[1]: VPN.TYPE: openvpn VPN.USERNAME: VPN.GATEWAY:a.b.c.d:1194:udp, a.b.c.d:443:tcp VPN.BANNER: -- VPN.VPN-STATE: 5 - VPN connected VPN.CFG[1]: ca = /home/chris/.cert/nm- openvpn/client-ca.pem VPN.CFG[2]: cert = /home/chris/.cert/nm- openvpn/client-cert.pem VPN.CFG[3]: cert-pass-flags = 0 VPN.CFG[4]: cipher = AES-256-CBC VPN.CFG[5]: comp-lzo = no-by-default VPN.CFG[6]: connect-timeout = 4 VPN.CFG[7]: connection-type = password-tls VPN.CFG[8]: dev = tun VPN.CFG[9]: dev-type = tun VPN.CFG[10]:key = /home/chris/.cert/nm- openvpn/client-key.pem VPN.CFG[11]:ns-cert-type = server VPN.CFG[12]:password-flags = 1 VPN.CFG[13]:remote = a.b.c.d:1194:udp, a.b.c.d:443:tcp VPN.CFG[14]:reneg-seconds = 604800 VPN.CFG[15]:ta = /home/chris/.cert/nm- openvpn/client-tls-auth.pem VPN.CFG[16]:ta-dir = 1 VPN.CFG[17]:username = Is there anything I can do to fix this configuration and route only private/internal traffic through the VPN? Thanks in advance, Chris -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEss2dENO/PTuA9NTTOdNgxkl4+QMFAmAahCoACgkQOdNgxkl4 +QPLVg//dWLtUH8GaRYom/+/A0e6iaqtQXxaDFVVxd7dZz4LiJ+t44dulXJewTuh ahihGsh8kqRRcI2KXe/pn1wL7Srdiuutw5yzjEjnOV1eX+7P5u6L4alA6EGWvNl0 Bpn4tnXoFyeVsMLBuPtNBj5j37fR65watXQjxOUQsF7Yv+FHDbPmFP3s+vBOrBJ1 s72lTJB/zjd9vmENl7WiHVPSF6aTU1d149QLCaG+S1hwL95b10B1mcwN3An00YE3 GZOwtaP
Re: Adding basic OpenVPN PKCS#11 support
I did a first patch which used a naive approach and just added support for specifying the pkcs11-providers and pkcs11-id in the GUI. This works but is not elegant or user friendly and requires that openvpn plays nicely with the desired pkcs#11 provider. In practice this is often a big problem. After some more reading and investigating I think it is better to do all the pkcs#11 operations outside openvpn. This is what the openvpn developers seem to desire and it neatly sidesteps all the issues we have with bad support for various pkcs#11 libraries in openvpn. Openvpn already supports offloading these operations via the management interface. We can use the builtin pkcs#11 support in the cert_chooser so the UI is fairly simple to implement. The nm-openvpn-service is already responsible for talking to the management interface of openvpn so that has to support the new requests. But the question is where to put the code which does the actual pkcs#11 requests. My initial idea is to use the Gnome pkcs11 support and put teh code in the auth-dialog program. Does that sound like a good idea? On Tue, Apr 2, 2019 at 7:39 PM Thomas Haller wrote: > On Tue, 2019-03-26 at 08:41 +0100, Martin Forssen via networkmanager- > list wrote: > > Hello, > > > > I have the need to run OpenVPN with PKCS#11 hardware certificates on > > Linux. This does currently not seem to be possible with > > NetworkManager. > > > > I have looked around a bit and realize this is a can of worms. The > > nice clean solution would require changes to OpenVPN, which so far > > seems to be hard to get merged. > > > > So my plan right now is to take the simplest possible approach and > > just add text fields where one can enter pkcs11-providers and pkcs11- > > id (and of course support for importing these values). > > > > My question now is if I were to submit patches which does this, is > > there any chance of them getting merged (assuming they follow coding > > standard etc)? > > > > Hi, > > > work on this would be great. > > Lubomir was working on that, quite a while ago. > > Some work in progess is still at [1]. Note this also requires support > from NetworkManager ([2]). > > > [1] > https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/commits/lr/p11-forward > [2] > https://cgit.freedesktop.org/NetworkManager/NetworkManager/log/?h=lr/p11-forward > > > best, > Thomas > -- Martin Forssén Director of Information Security Recorded Future <https://www.recordedfuture.com/> +46 760 252357 m...@recordedfuture.com ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Adding basic OpenVPN PKCS#11 support
On Tue, 2019-03-26 at 08:41 +0100, Martin Forssen via networkmanager- list wrote: > Hello, > > I have the need to run OpenVPN with PKCS#11 hardware certificates on > Linux. This does currently not seem to be possible with > NetworkManager. > > I have looked around a bit and realize this is a can of worms. The > nice clean solution would require changes to OpenVPN, which so far > seems to be hard to get merged. > > So my plan right now is to take the simplest possible approach and > just add text fields where one can enter pkcs11-providers and pkcs11- > id (and of course support for importing these values). > > My question now is if I were to submit patches which does this, is > there any chance of them getting merged (assuming they follow coding > standard etc)? > Hi, work on this would be great. Lubomir was working on that, quite a while ago. Some work in progess is still at [1]. Note this also requires support from NetworkManager ([2]). [1] https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/commits/lr/p11-forward [2] https://cgit.freedesktop.org/NetworkManager/NetworkManager/log/?h=lr/p11-forward best, 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: openvpn: "Authenticate/Decrypt packet error: bad packet ID", link-mtu=1472 consequences
On Wed, 2019-03-27 at 18:56 +, avemilia via networkmanager-list wrote: > Sorry, I have assumed that the VPN tunnel is up with this link-mtu > setting, but > in reality it is not. Hi, Try: sudo nmcli general logging level TRACE domains ALL,VPN_PLUGIN:TRACE and reactivate the VPN connection. Then, look at the debug logs (journalctl?) Assertions are of course always a bug, and should be fixed. But that does not seem related to your issue here. best, 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: openvpn: "Authenticate/Decrypt packet error: bad packet ID", link-mtu=1472 consequences
Sorry, I have assumed that the VPN tunnel is up with this link-mtu setting, but in reality it is not. Now I have spotted in the journal: > [...] vpn-connection[...]: VPN connection: failed to connect: > 'property “link-mtu” invalid or not supported' So, instead I am looking for a working configuration to eliminate the "bad packet ID" errors. ‐‐‐ Original Message ‐‐‐ On Wednesday, March 27, 2019 7:28 PM, avemilia via networkmanager-list wrote: > Hello list, > > openSUSE Tumbleweed (KDE Plasma) > NetworkManager-1.16.0-1.1.x86_64 > NetworkManager-openvpn-1.8.10-1.1.x86_64 > > with this openvpn configuration: > > > [vpn] > > auth= > > ca= > > cipher= > > comp-lzo=adaptive > > connection-type=password > > float=no > > mssfix=no > > password-flags=1 > > port= > > proto-tcp=no > > remote= > > remote-random=no > > tun-ipv6=no > > username= > > service-type=org.freedesktop.NetworkManager.openvpn > > I get many > > > Authenticate/Decrypt packet error: bad packet ID ... > > messages in the journal. > > I am not a networking expert, so I googled around > (https://hamy.io/post/0003/optimizing-openvpn-throughput/) and added > > > link-mtu=1472 > > to the above, and the "bad packet ID" messages were gone (all is tested via > connecting to twitch.tv in a browser). > > However, now the journal contains > > > ((src/devices/nm-device.c:11965)): assertion '' failed > > ((src/devices/nm-device.c:1478)): assertion '' failed > > ((src/devices/nm-device.c:11965)): assertion '' failed > > ((src/devices/nm-device.c:1478)): assertion '' failed > > and the nm kde applet shows a greyed out icon with a red cross. > > I feel like the assertions should not fail. I also feel like the applet should > correctly show that the connection is established. > > That was one thing (or more like two things). Whether it's a reportable bug(s) > or not is not known to me. Now, about how to fix things right now. > > From what I see in the nm GUI configurator if I press 'Advanced' on the > openvpn > connection, it has no support for link-mtu. It has support for tun-mtu. It > also > doesn't have support for mssfix other than 'yes' or 'no', while the openvpn(8) > says the user can set mssfix to a value. > > Maybe I can try some combination of tun-mtu, fragment, boolean-only mssfix and > other things that the GUI configurator can chew, and show me a 'nice' icon? > > 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
openvpn: "Authenticate/Decrypt packet error: bad packet ID", link-mtu=1472 consequences
Hello list, openSUSE Tumbleweed (KDE Plasma) NetworkManager-1.16.0-1.1.x86_64 NetworkManager-openvpn-1.8.10-1.1.x86_64 with this openvpn configuration: > [vpn] > auth= > ca= > cipher= > comp-lzo=adaptive > connection-type=password > float=no > mssfix=no > password-flags=1 > port= > proto-tcp=no > remote= > remote-random=no > tun-ipv6=no > username= > service-type=org.freedesktop.NetworkManager.openvpn I get many > Authenticate/Decrypt packet error: bad packet ID ... messages in the journal. I am not a networking expert, so I googled around (<https://hamy.io/post/0003/optimizing-openvpn-throughput/>) and added > link-mtu=1472 to the above, and the "bad packet ID" messages were gone (all is tested via connecting to twitch.tv in a browser). However, now the journal contains > ((src/devices/nm-device.c:11965)): assertion '' failed > ((src/devices/nm-device.c:1478)): assertion '' failed > ((src/devices/nm-device.c:11965)): assertion '' failed > ((src/devices/nm-device.c:1478)): assertion '' failed and the nm kde applet shows a greyed out icon with a red cross. I feel like the assertions should not fail. I also feel like the applet should correctly show that the connection is established. That was one thing (or more like two things). Whether it's a reportable bug(s) or not is not known to me. Now, about how to fix things right now. >From what I see in the nm GUI configurator if I press 'Advanced' on the openvpn connection, it has no support for link-mtu. It has support for tun-mtu. It also doesn't have support for mssfix other than 'yes' or 'no', while the openvpn(8) says the user can set mssfix to a value. Maybe I can try some combination of tun-mtu, fragment, boolean-only mssfix and other things that the GUI configurator can chew, and show me a 'nice' icon? ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Adding basic OpenVPN PKCS#11 support
Hello, I have the need to run OpenVPN with PKCS#11 hardware certificates on Linux. This does currently not seem to be possible with NetworkManager. I have looked around a bit and realize this is a can of worms. The nice clean solution would require changes to OpenVPN, which so far seems to be hard to get merged. So my plan right now is to take the simplest possible approach and just add text fields where one can enter pkcs11-providers and pkcs11-id (and of course support for importing these values). My question now is if I were to submit patches which does this, is there any chance of them getting merged (assuming they follow coding standard etc)? -- Martin Forssén Director of Information Security Recorded Future <https://www.recordedfuture.com/> +46 760 252357 m...@recordedfuture.com ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
OpenVPN + PKCS#11
Hi! I'm trying to setup an OpenVPN connection with NetworkManager using a PKCS#11 token as the client certificate storage. As far as I understand after some googling, it's not possible to setup such a config with GUI (at least #1218335 states so), but the "pkcs11:" schema is supported internally. However, if I specify "cert=pkcs11:manufacturer=piv_II" and try to turn the VPN up, I get the following in the log: Options error: --cert fails with 'pkcs11:manufacturer=piv_II': No such file or directory (errno=2) WARNING: cannot stat file 'pkcs11:manufacturer=piv_II': No such file or directory (errno=2) Options error: --key fails with 'pkcs11:manufacturer=piv_II': No such file or directory (errno=2) Options error: Please correct these errors. It looks like the schema is not recognized. Is there a way to setup OpenVPN with PKCS#11-stored certificate using NetworkManager? I'm using Ubuntu 18.04 and the repository-supplied NetworkManager (version 1.10.6). Best regards, Ignat Loskutov ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Problem importing OpenVPN profile in Linux Mint 18.3 x64 cinnamon
Thomas Haller wrote: On Thu, 2018-02-22 at 12:34 -0500, David H. Durgee wrote: Thomas Haller wrote: The proper solution is to add support for this option. Patches welcome. I doubt my programming skills are up to a patch for this. Is this one on the list somewhere of addition options to be supported? If not, can it be added? Hi, I did something, it's on review: https://bugzilla.gnome.org/show_bug.cgi?id=793746 In either case, any idea of when it might be available? Is there a release schedule for the plugin? Releases are done infrequently. Also, your distribution might not rebase the package to a new upstream release, and it might not be willing to backport new features in the current release of the distribution. But that depends... Given that I only need to use the service when taking my laptop out of the office I believe I can live with continuing to use openvpn directly until the plugin supports the option. I doubt that private tunnel is the only service using this option, so I suspect others are also encountering it and adding support to the plugin should be done at some point. Maybe it's a pain point for many user. But I never saw a feature request about it, and there is (AFAIK) no open RFE on bugzilla.gnome.org. Be that as it may, it's easy to add. best, Thomas Thank you for your effort on this issue. My release of mint is based upon ubuntu xenial and that is where the openvpn plugin is packaged. So if your work passes review and is released I would expect to see it when ubuntu adds it to their repository. As this is an LTS release I would expect updates to be made, but I have no idea how quickly it would be done. If for some reason ubuntu does not update their repository, do you also maintain a PPA for your releases? I have added a few PPAs to my configuration to address products that are not updated as part of mint or ubuntu and could add another one if needed and available. Thank you once again for your assistance in sorting this issue out. Dave ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Problem importing OpenVPN profile in Linux Mint 18.3 x64 cinnamon
On Thu, 2018-02-22 at 12:34 -0500, David H. Durgee wrote: > Thomas Haller wrote: > > > > The proper solution is to add support for this option. Patches > > welcome. > > I doubt my programming skills are up to a patch for this. Is this > one > on the list somewhere of addition options to be supported? If not, > can > it be added? Hi, I did something, it's on review: https://bugzilla.gnome.org/show_bug.cgi?id=793746 > In either case, any idea of when it might be available? > Is there a release schedule for the plugin? Releases are done infrequently. Also, your distribution might not rebase the package to a new upstream release, and it might not be willing to backport new features in the current release of the distribution. But that depends... > Given that I only need to use the service when taking my laptop out > of > the office I believe I can live with continuing to use openvpn > directly > until the plugin supports the option. I doubt that > private > tunnel is the only service using this option, so I suspect others > are > also encountering it and adding support to the plugin should be done > at > some point. Maybe it's a pain point for many user. But I never saw a feature request about it, and there is (AFAIK) no open RFE on bugzilla.gnome.org. Be that as it may, it's easy to add. best, 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: Problem importing OpenVPN profile in Linux Mint 18.3 x64 cinnamon
Thomas Haller wrote: On Thu, 2018-02-22 at 11:43 -0500, David H. Durgee wrote: Thomas Haller wrote: On Wed, 2018-02-21 at 12:03 -0500, David H. Durgee wrote: Thomas Haller wrote: I will consider debug logging after you have a chance to inspect the connection show and let me know if it looks sane or is missing a crucial element. Hi, the settings don't look wrong, but whether the settings are correct depends very much on your server configuratoin. Enable debug logging and see why the connection failed. Since NM does not support the argument, you should investigate whether that argument is required in your setup. For example, (as you said, plain openvpn works) by running openvpn with the ovpn without the option. best, Thomas Per your suggestion I tried using openvpn with the edited file and as expected it fails to connect. So the appears to be required to initialize the connection. Now the question is how do I add them to the configuration? I manually added the contents of that element to a file ~/.certs/nm-openvpn/Ashburn-edited-extra-certs.pem along with the other elements, but that appears to be insufficient. I assume that I need to add the proper entry to /etc/NetworkManager/system-connections/Private Tunnel - Ashburn, but my question is what form does that entry take? In the [vpn] section I see various entries referencing the certificates, specifically: cert=/home/dhdurgee/.cert/nm-openvpn/Ashburn-edited-cert.pem key=/home/dhdurgee/.cert/nm-openvpn/Ashburn-edited-key.pem ca=/home/dhdurgee/.cert/nm-openvpn/Ashburn-edited-ca.pem ta=/home/dhdurgee/.cert/nm-openvpn/Ashburn-edited-tls-auth.pem So I assume I need a similar line for this one, but should it be "extra-certs=" or "ec=" there? I guess I could try both, but I would prefer to get it right the first time. Or is it perhaps something else entirely? Hi, Editing the connection of NetworkManager with a new option that is not supported by nm-openvpn plugin does not make it work. nm-openvpn plugin does not support this option (yet). See https://git.gnome.org/browse/network-manager-openvpn/commit/?id=master especially https://git.gnome.org/browse/network-manager-openvpn/tree/src/nm-openvpn-service.c?id=dd8868f8a020988a47b7d4d4b502a98531fdeee0 which constructs the command line arguments for openvpn binary. The proper solution is to add support for this option. Patches welcome. I doubt my programming skills are up to a patch for this. Is this one on the list somewhere of addition options to be supported? If not, can it be added? In either case, any idea of when it might be available? Is there a release schedule for the plugin? Possible work arounds are: - try to find a client configuration that does not require this option. Maybe reconfigure the server is feasable. Not in this case, this is not my server but a service provider. - use openvpn directly, without NetworkManager That is my current approach, I guess I can continue doing so while the option is added to the plugin. - replace the openvpn binary with a wrapper shell script, that hacks this option. Something like (totally untested!) #!/bin/bash EXTRA_ARGS= if [[ echo "$@" | grep -q '--remote MY.REMOTE.THAT.I.RECOGNIZE' ]]; then EXTRA_ARGS="--extra-certs /path/to/extra/certs" fi exec /path/to/real/openvpn "$@" $EXTRA_ARGS I guess that might work, but it is a bit messy. Given that I only need to use the service when taking my laptop out of the office I believe I can live with continuing to use openvpn directly until the plugin supports the option. I doubt that private tunnel is the only service using this option, so I suspect others are also encountering it and adding support to the plugin should be done at some point. Thanks again for your assistance in this matter. Dave ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Problem importing OpenVPN profile in Linux Mint 18.3 x64 cinnamon
On Thu, 2018-02-22 at 11:43 -0500, David H. Durgee wrote: > Thomas Haller wrote: > > On Wed, 2018-02-21 at 12:03 -0500, David H. Durgee wrote: > > > Thomas Haller wrote: > > > > > > I will consider debug logging after you have a chance to inspect > > > the > > > connection show and let me know if it looks sane or is missing a > > > crucial > > > element. > > > > Hi, > > > > the settings don't look wrong, but whether the settings are > > correct > > depends very much on your server configuratoin. Enable debug > > logging > > and see why the connection failed. > > > > Since NM does not support the argument, you should > > investigate whether that argument is required in your setup. For > > example, (as you said, plain openvpn works) by running openvpn with > > the > > ovpn without the option. > > > > > > best, > > Thomas > > Per your suggestion I tried using openvpn with the edited file and > as > expected it fails to connect. So the appears to be > required to initialize the connection. Now the question is how do I > add > them to the configuration? I manually added the contents of that > element to a file ~/.certs/nm-openvpn/Ashburn-edited-extra-certs.pem > along with the other elements, but that appears to be insufficient. > > I assume that I need to add the proper entry to > /etc/NetworkManager/system-connections/Private Tunnel - Ashburn, but > my > question is what form does that entry take? In the [vpn] section I > see > various entries referencing the certificates, specifically: > > cert=/home/dhdurgee/.cert/nm-openvpn/Ashburn-edited-cert.pem > key=/home/dhdurgee/.cert/nm-openvpn/Ashburn-edited-key.pem > ca=/home/dhdurgee/.cert/nm-openvpn/Ashburn-edited-ca.pem > ta=/home/dhdurgee/.cert/nm-openvpn/Ashburn-edited-tls-auth.pem > > So I assume I need a similar line for this one, but should it be > "extra-certs=" or "ec=" there? I guess I could try both, but I > would > prefer to get it right the first time. Or is it perhaps something > else > entirely? Hi, Editing the connection of NetworkManager with a new option that is not supported by nm-openvpn plugin does not make it work. nm-openvpn plugin does not support this option (yet). See https://git.gnome.org/browse/network-manager-openvpn/commit/?id=master especially https://git.gnome.org/browse/network-manager-openvpn/tree/src/nm-openvpn-service.c?id=dd8868f8a020988a47b7d4d4b502a98531fdeee0 which constructs the command line arguments for openvpn binary. The proper solution is to add support for this option. Patches welcome. Possible work arounds are: - try to find a client configuration that does not require this option. Maybe reconfigure the server is feasable. - use openvpn directly, without NetworkManager - replace the openvpn binary with a wrapper shell script, that hacks this option. Something like (totally untested!) #!/bin/bash EXTRA_ARGS= if [[ echo "$@" | grep -q '--remote MY.REMOTE.THAT.I.RECOGNIZE' ]]; then EXTRA_ARGS="--extra-certs /path/to/extra/certs" fi exec /path/to/real/openvpn "$@" $EXTRA_ARGS best, 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: Problem importing OpenVPN profile in Linux Mint 18.3 x64 cinnamon
Thomas Haller wrote: On Wed, 2018-02-21 at 12:03 -0500, David H. Durgee wrote: Thomas Haller wrote: I will consider debug logging after you have a chance to inspect the connection show and let me know if it looks sane or is missing a crucial element. Hi, the settings don't look wrong, but whether the settings are correct depends very much on your server configuratoin. Enable debug logging and see why the connection failed. Since NM does not support the argument, you should investigate whether that argument is required in your setup. For example, (as you said, plain openvpn works) by running openvpn with the ovpn without the option. best, Thomas Per your suggestion I tried using openvpn with the edited file and as expected it fails to connect. So the appears to be required to initialize the connection. Now the question is how do I add them to the configuration? I manually added the contents of that element to a file ~/.certs/nm-openvpn/Ashburn-edited-extra-certs.pem along with the other elements, but that appears to be insufficient. I assume that I need to add the proper entry to /etc/NetworkManager/system-connections/Private Tunnel - Ashburn, but my question is what form does that entry take? In the [vpn] section I see various entries referencing the certificates, specifically: cert=/home/dhdurgee/.cert/nm-openvpn/Ashburn-edited-cert.pem key=/home/dhdurgee/.cert/nm-openvpn/Ashburn-edited-key.pem ca=/home/dhdurgee/.cert/nm-openvpn/Ashburn-edited-ca.pem ta=/home/dhdurgee/.cert/nm-openvpn/Ashburn-edited-tls-auth.pem So I assume I need a similar line for this one, but should it be "extra-certs=" or "ec=" there? I guess I could try both, but I would prefer to get it right the first time. Or is it perhaps something else entirely? Dave ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Problem importing OpenVPN profile in Linux Mint 18.3 x64 cinnamon
On Wed, 2018-02-21 at 12:03 -0500, David H. Durgee wrote: > Thomas Haller wrote: > > I will consider debug logging after you have a chance to inspect the > connection show and let me know if it looks sane or is missing a > crucial > element. Hi, the settings don't look wrong, but whether the settings are correct depends very much on your server configuratoin. Enable debug logging and see why the connection failed. Since NM does not support the argument, you should investigate whether that argument is required in your setup. For example, (as you said, plain openvpn works) by running openvpn with the ovpn without the option. best, 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: Problem importing OpenVPN profile in Linux Mint 18.3 x64 cinnamon
Thomas Haller wrote: On Tue, 2018-02-20 at 16:46 -0500, David H. Durgee wrote: As I indicated in my last posting, I was going to try editing out the element that was being complained about in the error and see what happens. I was able to successfully import the edited ovpn file using network connections. Sidenote: import of a ovpn file is only a step to create the connection profile in NetworkManager. When you activate a VPN connection, what matters is how the connection profile locks in NetworkManager, see for example $ nmcli connection show "$VPN_PROFILE" The settings in the profile matter, but it does not matter how the profile was created originally (import ovpn file, or clicked in nm- connection-editor, or nmcli). I have attached the output of the connection show to this response. Now that it is in my available connections, I attempted to activate it. Unfortunately, this failed. Looking in /var/log/syslog I found the following: ... Feb 20 16:21:48 Z560 nm-openvpn[21289]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Feb 20 16:21:48 Z560 nm-openvpn[21289]: TLS Error: TLS handshake failed Feb 20 16:21:48 Z560 nm-openvpn[21289]: SIGUSR1[soft,tls-error] received, process restarting Unclear, what is wrong. What did you do about the unsupported extra-certs option? nm-openvpn does not support that, so there is no immediate way how to specify them. Is this option required for you to successfully establish the connection? I simply edited it out of the profile. I don't know if it is required or optional. You could enable debug logging, for example via sudo nmcli general logging level TRACE domains ALL,VPN_PLUGIN afterward, re-activate the VPN connection and look at journal. Note that verbose logging of openvpn might reveal private sensitive information. Take care before sending a logfile. See comment about rate limiting of journal at https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/contrib/fedora/rpm/NetworkManager.conf Also, in the logfile you will see how NetworkManager's VPN plugin invokes the openvpn binary and which parameters are passed to it. Are those parameters making sense? best, Thomas I will consider debug logging after you have a chance to inspect the connection show and let me know if it looks sane or is missing a crucial element. Thank you for your assistance in this matter. Dave connection.id: Private Tunnel - Ashburn connection.uuid:03cba5d7-57df-4bd8-b5d3-24c3f24013d7 connection.interface-name: -- connection.type:vpn connection.autoconnect: yes connection.autoconnect-priority:0 connection.timestamp: 0 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 connection.lldp:-1 (default) ipv4.method:auto ipv4.dns: ipv4.dns-search: ipv4.dns-options: (default) ipv4.dns-priority: 0 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-timeout: 0 ipv4.dhcp-send-hostname:yes ipv4.dhcp-hostname: -- ipv4.dhcp-fqdn: -- ipv4.never-default: no ipv4.may-fail: yes ipv4.dad-timeout: -1 (default) ipv6.method:auto ipv6.dns: ipv6.dns-search: ipv6.dns-options: (default) ipv6.dns-priority: 0 ipv6.addresses: ipv6.gateway: -- ipv6.routes: ipv6.route-metric: -1 ipv6.ignore-auto-routes:no ipv6.ignore-auto-dns: no ipv6.never-default: no ipv6.may-fail: yes ipv6.ip6-privacy: 0 (disabled) ipv6.addr-gen-mode: stable-privacy ipv6.dhcp-send-hostname:yes ipv6.dhcp-hostname: -- vpn.service-type: org.freedesktop.NetworkManager.openvpn vpn.user-name: -- vpn.data:
Re: Problem importing OpenVPN profile in Linux Mint 18.3 x64 cinnamon
On Tue, 2018-02-20 at 16:46 -0500, David H. Durgee wrote: > As I indicated in my last posting, I was going to try editing out > the > element that was being complained about in the error and see what > happens. I was able to successfully import the edited ovpn file > using > network connections. Sidenote: import of a ovpn file is only a step to create the connection profile in NetworkManager. When you activate a VPN connection, what matters is how the connection profile locks in NetworkManager, see for example $ nmcli connection show "$VPN_PROFILE" The settings in the profile matter, but it does not matter how the profile was created originally (import ovpn file, or clicked in nm- connection-editor, or nmcli). > Now that it is in my available connections, I attempted to activate > it. > Unfortunately, this failed. Looking in /var/log/syslog I found the > following: ... > Feb 20 16:21:48 Z560 nm-openvpn[21289]: TLS Error: TLS key > negotiation > failed to occur within 60 seconds (check your network connectivity) > Feb 20 16:21:48 Z560 nm-openvpn[21289]: TLS Error: TLS handshake > failed > Feb 20 16:21:48 Z560 nm-openvpn[21289]: SIGUSR1[soft,tls-error] > received, process restarting Unclear, what is wrong. What did you do about the unsupported extra-certs option? nm-openvpn does not support that, so there is no immediate way how to specify them. Is this option required for you to successfully establish the connection? You could enable debug logging, for example via sudo nmcli general logging level TRACE domains ALL,VPN_PLUGIN afterward, re-activate the VPN connection and look at journal. Note that verbose logging of openvpn might reveal private sensitive information. Take care before sending a logfile. See comment about rate limiting of journal at https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/contrib/fedora/rpm/NetworkManager.conf Also, in the logfile you will see how NetworkManager's VPN plugin invokes the openvpn binary and which parameters are passed to it. Are those parameters making sense? best, 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: Problem importing OpenVPN profile in Linux Mint 18.3 x64 cinnamon
As I indicated in my last posting, I was going to try editing out the element that was being complained about in the error and see what happens. I was able to successfully import the edited ovpn file using network connections. Now that it is in my available connections, I attempted to activate it. Unfortunately, this failed. Looking in /var/log/syslog I found the following: Feb 20 16:20:48 Z560 NetworkManager[1008]: [1519161648.0350] audit: op="connection-activate" uuid="03cba5d7-57df-4bd8-b5d3-24c3f24013d7" name="Private Tunnel - Ashburn" pid=2421 uid=1000 result="success" Feb 20 16:20:48 Z560 NetworkManager[1008]: [1519161648.0521] vpn-connection[0x132d270,03cba5d7-57df-4bd8-b5d3-24c3f24013d7,"Private Tunnel - Ashburn",0]: Started the VPN service, PID 21285 Feb 20 16:20:48 Z560 NetworkManager[1008]: [1519161648.0904] vpn-connection[0x132d270,03cba5d7-57df-4bd8-b5d3-24c3f24013d7,"Private Tunnel - Ashburn",0]: Saw the service appear; activating connection Feb 20 16:20:48 Z560 NetworkManager[1008]: nm-openvpn-Message: openvpn[21289] started Feb 20 16:20:48 Z560 NetworkManager[1008]: [1519161648.1261] vpn-connection[0x132d270,03cba5d7-57df-4bd8-b5d3-24c3f24013d7,"Private Tunnel - Ashburn",0]: VPN plugin: state changed: starting (3) Feb 20 16:20:48 Z560 NetworkManager[1008]: [1519161648.1262] vpn-connection[0x132d270,03cba5d7-57df-4bd8-b5d3-24c3f24013d7,"Private Tunnel - Ashburn",0]: VPN connection: (ConnectInteractive) reply received Feb 20 16:20:48 Z560 nm-openvpn[21289]: OpenVPN 2.4.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Sep 26 2017 Feb 20 16:20:48 Z560 nm-openvpn[21289]: library versions: OpenSSL 1.0.2g 1 Mar 2016, LZO 2.08 Feb 20 16:20:48 Z560 nm-openvpn[21289]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Feb 20 16:20:48 Z560 nm-openvpn[21289]: TCP/UDP: Preserving recently used remote address: [AF_INET]198.24.187.53:1194 Feb 20 16:20:48 Z560 nm-openvpn[21289]: UDP link local: (not bound) Feb 20 16:20:48 Z560 nm-openvpn[21289]: UDP link remote: [AF_INET]198.24.187.53:1194 Feb 20 16:20:48 Z560 nm-openvpn[21289]: NOTE: chroot will be delayed because of --client, --pull, or --up-delay Feb 20 16:20:48 Z560 nm-openvpn[21289]: NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay Feb 20 16:21:48 Z560 nm-openvpn[21289]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Feb 20 16:21:48 Z560 nm-openvpn[21289]: TLS Error: TLS handshake failed Feb 20 16:21:48 Z560 nm-openvpn[21289]: SIGUSR1[soft,tls-error] received, process restarting Feb 20 16:21:48 Z560 NetworkManager[1008]: [1519161708.8643] vpn-connection[0x132d270,03cba5d7-57df-4bd8-b5d3-24c3f24013d7,"Private Tunnel - Ashburn",0]: VPN connection: connect timeout exceeded. Feb 20 16:21:48 Z560 NetworkManager[1008]: libnm-Message: Connect timer expired, disconnecting. Feb 20 16:21:48 Z560 NetworkManager[1008]: nm-openvpn-Message: openvpn[21289]: send SIGTERM Feb 20 16:21:48 Z560 nm-openvpn[21289]: SIGTERM[hard,init_instance] received, process exiting Feb 20 16:21:48 Z560 NetworkManager[1008]: nm-openvpn-Message: openvpn[21289] exited with success Feb 20 16:21:48 Z560 NetworkManager[1008]: [1519161708.8712] vpn-connection[0x132d270,03cba5d7-57df-4bd8-b5d3-24c3f24013d7,"Private Tunnel - Ashburn",0]: VPN plugin: failed: connect-failed (1) Feb 20 16:21:48 Z560 NetworkManager[1008]: [1519161708.8721] vpn-connection[0x132d270,03cba5d7-57df-4bd8-b5d3-24c3f24013d7,"Private Tunnel - Ashburn",0]: VPN plugin: state changed: stopping (5) Feb 20 16:21:48 Z560 NetworkManager[1008]: [1519161708.8722] vpn-connection[0x132d270,03cba5d7-57df-4bd8-b5d3-24c3f24013d7,"Private Tunnel - Ashburn",0]: VPN plugin: state changed: stopped (6) I attached a copy of this log in case the above is unreadable. How do I correct this problem and get the tunnel working? Dave Feb 20 16:20:48 Z560 NetworkManager[1008]: [1519161648.0350] audit: op="connection-activate" uuid="03cba5d7-57df-4bd8-b5d3-24c3f24013d7" name="Private Tunnel - Ashburn" pid=2421 uid=1000 result="success" Feb 20 16:20:48 Z560 NetworkManager[1008]: [1519161648.0521] vpn-connection[0x132d270,03cba5d7-57df-4bd8-b5d3-24c3f24013d7,"Private Tunnel - Ashburn",0]: Started the VPN service, PID 21285 Feb 20 16:20:48 Z560 NetworkManager[1008]: [1519161648.0904] vpn-connection[0x132d270,03cba5d7-57df-4bd8-b5d3-24c3f24013d7,"Private Tunnel - Ashburn",0]: Saw the service appear; activating connection Feb 20 16:20:48 Z560 NetworkManager[1008]: nm-openvpn-Message: openvpn[21289] started Feb 20 16:20:48 Z560 NetworkManager[1008]: [1519161648.1261] vpn-connection[0x132d270,03cba5d7-57df-4bd8-b5d3-
Re: Problem importing OpenVPN profile in Linux Mint 18.3 x64 cinnamon
Thomas Haller wrote: On Thu, 2018-02-15 at 14:24 -0500, David H. Durgee wrote: Hi, I am running Linux Mint 18.3 x64 cinnamon and have the OpenVPN plugin installed with network manager. I have an OpenVPN profile from Private Tunnel that I use with no problems on my phone with the OpenVPN Connect app. I can also use the profile at the terminal window in LM 18.3 successfully. Attempting to import the OpenVPN profile fails with an error: Cannot import VPN connection The file 'Ashburn.ovpn' could not be read or does not contain recognized VPN connection information Error: the plugin does not support import capability. The error message is not helpful because of bug https://bugzilla.gnome.org/show_bug.cgi?id=790770#c1 You might get a better message with nmcli connection import type openvpn file "$FILENAME" and maybe that already tells you what's wrong. In my terminal window I get: [snip] all this information is not relevant, because import is solely done by the user application that reads the .ovpn file and creates a corresponding connection profile in NetworkManager compatible format Commonly it's one of nmcli, nm-connection-editor, gnome-control-center, or plasma-nm. Can you be more precise about which application you are using to import the ovpn file? The information that matters most is the ovpn file itself and the version of the nm-openvpn plugin that performs the import. Please send the ovpn file, but make sure to sanitize private information (without changing the meaning of the file too much). best, Thomas I tired the command line tool as suggested: dhdurgee@Z560 ~/Downloads $ nmcli connection import type openvpn file Ashburn.ovpn Error: failed to import 'Ashburn.ovpn': configuration error: unsupported blob/xml element (line 77). Looking at the file, the line indicated and following are: -BEGIN CERTIFICATE- *** certificate omitted *** -END CERTIFICATE- Beyond that extra certificate are the RSA KEY and TLS information. I guess I can try editing the file to remove the extra certificate and see if that passes muster. Dave ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Problem importing OpenVPN profile in Linux Mint 18.3 x64 cinnamon
On Thu, 2018-02-15 at 14:24 -0500, David H. Durgee wrote: Hi, > I am running Linux Mint 18.3 x64 cinnamon and have the OpenVPN > plugin > installed with network manager. I have an OpenVPN profile from > Private > Tunnel that I use with no problems on my phone with the OpenVPN > Connect > app. I can also use the profile at the terminal window in LM 18.3 > successfully. Attempting to import the OpenVPN profile fails with an > error: > > Cannot import VPN connection > > The file 'Ashburn.ovpn' could not be read or does not contain > recognized > VPN connection information > > Error: the plugin does not support import capability. The error message is not helpful because of bug https://bugzilla.gnome.org/show_bug.cgi?id=790770#c1 You might get a better message with nmcli connection import type openvpn file "$FILENAME" and maybe that already tells you what's wrong. > In my terminal window I get: [snip] all this information is not relevant, because import is solely done by the user application that reads the .ovpn file and creates a corresponding connection profile in NetworkManager compatible format Commonly it's one of nmcli, nm-connection-editor, gnome-control-center, or plasma-nm. Can you be more precise about which application you are using to import the ovpn file? The information that matters most is the ovpn file itself and the version of the nm-openvpn plugin that performs the import. Please send the ovpn file, but make sure to sanitize private information (without changing the meaning of the file too much). best, 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
Problem importing OpenVPN profile in Linux Mint 18.3 x64 cinnamon
I am running Linux Mint 18.3 x64 cinnamon and have the OpenVPN plugin installed with network manager. I have an OpenVPN profile from Private Tunnel that I use with no problems on my phone with the OpenVPN Connect app. I can also use the profile at the terminal window in LM 18.3 successfully. Attempting to import the OpenVPN profile fails with an error: Cannot import VPN connection The file 'Ashburn.ovpn' could not be read or does not contain recognized VPN connection information Error: the plugin does not support import capability. In my terminal window I get: dhdurgee@Z560 ~/Downloads $ sudo openvpn --config /home/dhdurgee/Downloads/Ashburn.ovpn [sudo] password for dhdurgee: Thu Nov 16 11:47:46 2017 OpenVPN 2.4.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Sep 26 2017 Thu Nov 16 11:47:46 2017 library versions: OpenSSL 1.0.2g 1 Mar 2016, LZO 2.08 Thu Nov 16 11:47:46 2017 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication Thu Nov 16 11:47:46 2017 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication Thu Nov 16 11:47:46 2017 TCP/UDP: Preserving recently used remote address: [AF_INET]172.106.104.151:1194 Thu Nov 16 11:47:46 2017 Socket Buffers: R=[212992->212992] S=[212992->212992] Thu Nov 16 11:47:46 2017 NOTE: setsockopt TCP_NODELAY=1 failed Thu Nov 16 11:47:46 2017 UDP link local: (not bound) Thu Nov 16 11:47:46 2017 UDP link remote: [AF_INET]172.106.104.151:1194 Thu Nov 16 11:47:46 2017 TLS: Initial packet from [AF_INET]172.106.104.151:1194, sid=dfa7b684 f0ff3286 Thu Nov 16 11:47:46 2017 VERIFY OK: depth=2, CN=OpenVPN CA Thu Nov 16 11:47:46 2017 VERIFY OK: depth=1, CN=PT Transitional 20150615 Thu Nov 16 11:47:46 2017 VERIFY KU OK Thu Nov 16 11:47:46 2017 Validating certificate extended key usage Thu Nov 16 11:47:46 2017 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication Thu Nov 16 11:47:46 2017 VERIFY EKU OK Thu Nov 16 11:47:46 2017 VERIFY OK: depth=0, CN=ash2.privatetunnel.com Thu Nov 16 11:47:46 2017 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA Thu Nov 16 11:47:46 2017 [ash2.privatetunnel.com] Peer Connection Initiated with [AF_INET]172.106.104.151:1194 Thu Nov 16 11:47:47 2017 SENT CONTROL [ash2.privatetunnel.com]: 'PUSH_REQUEST' (status=1) Thu Nov 16 11:47:47 2017 PUSH: Received control message: 'PUSH_REPLY,route-gateway 10.9.0.1,ifconfig 10.9.203.15 255.255.0.0,client-ip 72.83.50.38,ping 8,ping-restart 40,reneg-sec 3600,cipher AES-128-GCM,compress lz4-v2,peer-id 31367,topology subnet,explicit-exit-notify,redirect-gateway def1,dhcp-option DNS 10.9.0.1,sndbuf 0,rcvbuf 0,socket-flags TCP_NODELAY,block-ipv6' Thu Nov 16 11:47:47 2017 Options error: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:3: client-ip (2.4.4) Thu Nov 16 11:47:47 2017 Options error: option 'reneg-sec' cannot be used in this context ([PUSH-OPTIONS]) Thu Nov 16 11:47:47 2017 Option 'explicit-exit-notify' in [PUSH-OPTIONS]:11 is ignored by previous blocks Thu Nov 16 11:47:47 2017 Options error: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:17: block-ipv6 (2.4.4) Thu Nov 16 11:47:47 2017 OPTIONS IMPORT: timers and/or timeouts modified Thu Nov 16 11:47:47 2017 OPTIONS IMPORT: explicit notify parm(s) modified Thu Nov 16 11:47:47 2017 OPTIONS IMPORT: compression parms modified Thu Nov 16 11:47:47 2017 OPTIONS IMPORT: --sndbuf/--rcvbuf options modified Thu Nov 16 11:47:47 2017 Socket Buffers: R=[212992->212992] S=[212992->212992] Thu Nov 16 11:47:47 2017 OPTIONS IMPORT: --socket-flags option modified Thu Nov 16 11:47:47 2017 NOTE: setsockopt TCP_NODELAY=1 failed Thu Nov 16 11:47:47 2017 OPTIONS IMPORT: --ifconfig/up options modified Thu Nov 16 11:47:47 2017 OPTIONS IMPORT: route options modified Thu Nov 16 11:47:47 2017 OPTIONS IMPORT: route-related options modified Thu Nov 16 11:47:47 2017 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified Thu Nov 16 11:47:47 2017 OPTIONS IMPORT: peer-id set Thu Nov 16 11:47:47 2017 OPTIONS IMPORT: adjusting link_mtu to 1625 Thu Nov 16 11:47:47 2017 OPTIONS IMPORT: data channel crypto options modified Thu Nov 16 11:47:47 2017 Data Channel: using negotiated cipher 'AES-128-GCM' Thu Nov 16 11:47:47 2017 Outgoing Data Channel: Cipher 'AES-128-GCM' initialized with 128 bit key Thu Nov 16 11:47:47 2017 Incoming Data Channel: Cipher 'AES-128-GCM' initialized with 128 bit key Thu Nov 16 11:47:47 2017 ROUTE_GATEWAY 192.168.230.1/255.255.255.0 IFACE=wlp5s0 HWADDR=ac:81:12:a4:5e:43 Thu Nov 16 11:47:47 2017 TUN/TAP device tun0 opened Thu Nov 16 11:47:47 2017 TUN/TAP TX queue length set to 100 Thu Nov 16 11:47:47 2017 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Re: Format of the OpenVPN file
On Thu, 2017-12-28 at 10:35 +, Guillaume Betous wrote: > Hi, > > I have an openvpn setup which works fine on command-line. I have a > single file which contains inline keys. > > When I try to import it on network-manager (not sure of the version, > but I run Ubuntu 17.10), I have an error with message like "cannot > read or does not contain known VPN data / ERROR : plugin does not > handle import" (French message is : Le fichier xxx.ovpn est illisible > ou ne contient pas d'information de connexion VPN reconnues. ERREUR : > le greffon ne prend pas en charge la fonction d'importation). > > I could not find anywhere a clear documentation about the needed file > format. > > Thank you for your help, > > Regards, > > gUI > Hi, The "import" functionality takes a (native) OpenVPN configuration (ovpn file), and creates a corresponding connection profile in NetworkManager. The file format is of exactly as documented in `man openvpn`. If a certain valid ovpn file cannot be imported, it's either a bug or a missing feature. Since you don't provide the file that causes the failure to import, it's hard to say why it fails. The reason why you are getting such a generic error message is probably because import via nm-connection-editor asks all VPN plugins to import the file. Since they all fail, nm-connection-editor shows the failure message of an arbitrary plugin, not necessarily the openvpn plugin. Hence, the error message is not very helpful. That should be improved, but it's unclear how to find the ~best~ failure message. You would probably get a better message with nmcli connection import type openvpn file "$OVPN_FILENAME" best, 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: Format of the OpenVPN file
Are you feeding your config file to openvpn binary on the command line? I suspect OpenVPN and NM have different config formats and NM expects NM-exported file. Here's an example of OpenVPN connection, exported from NM (I simply exported mine), try adopting it to your needs: client remote 'server.com' ca '/ca.crt' cert '/client1.crt' key '/client1.key' dev tun proto tcp nobind auth-nocache script-security 2 persist-key persist-tun user nm-openvpn group nm-openvpn /--Regards, Aleksei/ On 28/12/17 13:35, Guillaume Betous wrote: Hi, I have an openvpn setup which works fine on command-line. I have a single file which contains inline keys. When I try to import it on network-manager (not sure of the version, but I run Ubuntu 17.10), I have an error with message like "cannot read or does not contain known VPN data / ERROR : plugin does not handle import" (French message is : Le fichier xxx.ovpn est illisible ou ne contient pas d'information de connexion VPN reconnues. ERREUR : le greffon ne prend pas en charge la fonction d'importation). I could not find anywhere a clear documentation about the needed file format. Thank you for your help, Regards, gUI -- Pour la santé de votre ordinateur, préférez les logiciels libres. Lire son mail : http://www.mozilla-europe.org/fr/products/thunderbird/ Browser le web : http://www.mozilla-europe.org/fr/products/firefox/ Suite bureautique : http://www.libreoffice.org/download/ ___ 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
Format of the OpenVPN file
Hi, I have an openvpn setup which works fine on command-line. I have a single file which contains inline keys. When I try to import it on network-manager (not sure of the version, but I run Ubuntu 17.10), I have an error with message like "cannot read or does not contain known VPN data / ERROR : plugin does not handle import" (French message is : Le fichier xxx.ovpn est illisible ou ne contient pas d'information de connexion VPN reconnues. ERREUR : le greffon ne prend pas en charge la fonction d'importation). I could not find anywhere a clear documentation about the needed file format. Thank you for your help, Regards, gUI -- Pour la santé de votre ordinateur, préférez les logiciels libres. Lire son mail : http://www.mozilla-europe.org/fr/products/thunderbird/ Browser le web : http://www.mozilla-europe.org/fr/products/firefox/ Suite bureautique : http://www.libreoffice.org/download/ ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager OpenVPN DNS returns REFUSED
On Thu, 2017-03-23 at 09:54 +0100, Beniamino Galvani wrote: > Which dnsmasq version are you using? There was a bug in the way > dnsmasq cached sockets for queries that caused problems when the VPN > interface is recreated by kernel with a different ifindex; see [1] [2] > for more details. This could be the cause of the problem you see. > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1367772 > [2] > http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=2675f2061525bc954be14988d64384b74aa7bf8b I applied the two patches discussed in the bug (there's a followup patch to your link [2], mentioned in the bug, that avoids a coredump in some situations) and so far it seems to have solved my problem. Thanks! ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager OpenVPN DNS returns REFUSED
On Thu, 2017-03-23 at 09:54 +0100, Beniamino Galvani wrote: > > What does it mean that the local DNS service is returning REFUSED? How > > can I debug this further? Or, does anyone know how to fix it? > > You can enable logging of queries in dnsmasq with: > > echo log-queries > /etc/NetworkManager/dnsmasq.d/log-queries > killall -HUP NetworkManager > > After this, you should see in logs queries sent by dnsmasq and > responses from name servers. Thank you for this info. I see that when this problem is happening I get a single line in the log: query[A] git.my.domain.com from 127.0.0.1 and that's it, nothing else. It seems that dnsmasq sends the REFUSED response without even trying to pass along the request any further. When things are working properly, I get a set of responses in the log for each lookup including forwarding to the upstream DNS server and the final answer. Also a belated, but heartfelt, thank-you to Thomas Haller for his reply to a similar question I asked last November; his email had a wealth of fantastic information for debugging NM issues and I still refer to it constantly. https://mail.gnome.org/archives/networkmanager-list/2016-November/msg00081.html > Which dnsmasq version are you using? There was a bug in the way > dnsmasq cached sockets for queries that caused problems when the VPN > interface is recreated by kernel with a different ifindex; see [1] [2] > for more details. This could be the cause of the problem you see. After I sent my email I realized I had forgotten to include dnsmasq info. I'm using 2.76 (Ubuntu package dnsmasq-base 2.76-4). From what I can tell the fixes you refer to are not available in any dnsmasq release yet but will be in the next release (2.77), and the version I have does not backport this patch. I will try building a dnsmasq with this patch applied and see if it helps. FWIW, I'm currently working around this issue by adding a script to /etc/NetworkManager/dispatcher.d that sends a SIGHUP to NetworkManager. It seems to work, although it's obviously not ideal. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager OpenVPN DNS returns REFUSED
On Wed, Mar 22, 2017 at 08:19:32PM -0400, Paul Smith wrote: > Hi all. I'm having a problem with DNS servers over openvpn. I use > NetworkManager to configure (via openvpn config file import) and > start/stop the VPN. I'm using Ubuntu GNOME 16.10, with: > > [...] > > I've also enabled "nmcli general logging level TRACE" and looked at the > journalctl logging when starting / stopping both VPN configurations and > it all looks fine to me: for both I can see the IP address for the DNS > server added as "50 vpn v4 tun0 : " where my default DNS servers > are 100. I see dnsmasq messages saying it's adding the new DNS address > as the nameserver for all the domains. > > What does it mean that the local DNS service is returning REFUSED? How > can I debug this further? Or, does anyone know how to fix it? You can enable logging of queries in dnsmasq with: echo log-queries > /etc/NetworkManager/dnsmasq.d/log-queries killall -HUP NetworkManager After this, you should see in logs queries sent by dnsmasq and responses from name servers. Which dnsmasq version are you using? There was a bug in the way dnsmasq cached sockets for queries that caused problems when the VPN interface is recreated by kernel with a different ifindex; see [1] [2] for more details. This could be the cause of the problem you see. Beniamino [1] https://bugzilla.redhat.com/show_bug.cgi?id=1367772 [2] http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=2675f2061525bc954be14988d64384b74aa7bf8b signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
NetworkManager OpenVPN DNS returns REFUSED
Hi all. I'm having a problem with DNS servers over openvpn. I use NetworkManager to configure (via openvpn config file import) and start/stop the VPN. I'm using Ubuntu GNOME 16.10, with: network-manager 1.2.6-0ubuntu1 network-manager-openvpn 1.2.6-2ubuntu1 network-manager-openvpn-gnome 1.2.6-2ubuntu1 openvpn 2.3.11-1ubuntu2 I'm using the default Ubuntu configuration: $ cat /etc/NetworkManager/NetworkManager.conf [main] plugins=ifupdown,keyfile,ofono dns=dnsmasq [ifupdown] managed=false FWIW, this is a wired connection. Ubuntu builds NetworkManager with rc- update set to resolvconf and indeed I can see that this is what I have: $ cat /etc/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 127.0.1.1 I have a VPN configuration I've been using for years at my company, that's worked just fine. The config is pretty straightforward: client remote comp-lzo yes dev tap proto udp nobind and a few other things. Now we're moving and our VPN is also changing, so I have a new openvpn configuration which is also straightforward: client dev tun proto udp remote and a few other things related to the key. This also connects fine, BUT my DNS doesn't work. Whenever I try to look up a hostname inside my VPN network, I get a REFUSED response: $ host git Host git.my.domain.com not found: 5(REFUSED) $ host git.my.domain.com Host git.my.domain.com not found: 5(REFUSED) One thing that will fix it is if I send a SIGHUP to NetworkManager after I connect the VPN: $ sudo killall -HUP NetworkManager $ host git git.my.domain.com is an alias for server.my.domain.com. server.my.domain.com has address 192.168.1.7 So, I don't think it's a problem with the remote DNS server since just resetting my local NetworkManager fixes it. However, I have to do this every time I connect which of course is bogus. Also this happens for all lookups of all hosts including A records, not just CNAME records as I show in this example. I've used "nmcli -f all device show " in both the working and non- working setups and compared the two configurations and they look fine to me: I can see the DNS server IP address (they are different VPN servers, different DHCP servers, different DNS servers, etc. of course). In fact if I find the DNS server IP address and use it directly on the host command that lookup works: $ host git 198.168.1.2 git.my.domain.com is an alias for server.my.domain.com. server.my.domain.com has address 192.168.1.7 I've also enabled "nmcli general logging level TRACE" and looked at the journalctl logging when starting / stopping both VPN configurations and it all looks fine to me: for both I can see the IP address for the DNS server added as "50 vpn v4 tun0 : " where my default DNS servers are 100. I see dnsmasq messages saying it's adding the new DNS address as the nameserver for all the domains. What does it mean that the local DNS service is returning REFUSED? How can I debug this further? Or, does anyone know how to fix it? ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: openvpn: embedding pkcs12 into ovpn config
On Fri, 2017-03-17 at 21:28 -0400, Paul Smith wrote: > Second, I really want to use an embedded certificate format in the ovpn > for the pkcs12 file rather than shipping two separate files. > [...] when I attempt to connect it fails. I tried this same ovpn file with embedded pkcs12 cert with Viscosity on my MacOS system and it worked just fine. Also, I discovered that the my-pkcs12.pem file is in fact just the un-decoded base64 content: if I convert that back from base64 into its binary format and put that in the file instead, it all works in NetworkManager as well. So, it seems like NM openvpn is just missing a step here when it extracts the embedded cert into a file. I've filed https://bugzilla.gnome.org/show_bug.cgi?id=780251 about this. Cheers! ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
openvpn: embedding pkcs12 into ovpn config
I guess I'm not sure where to ask this, so I'll try here. I've been provided an ovpn file and a separate pkcs12 (p12) file. The ovpn file contains: pkcs12 /path/to/my.p12 I am using Ubuntu 16.10 and I have network-manager-openvpn-gnome, network-manager-openvpn, and openvpn itself all installed (as well as openssl etc.) If I add a new VPN by importing this ovpn configuration it works, so yay! Next I need to distribute this file to a group of users and I'd like to simplify it somewhat. So, I have two questions: First, is it possible to add a setting to the ovpn file that will cause networkmanager to automatically check the IPv4 (and IPv6) "Use this connection only for resources on its network" box, without requiring the user to do it? I'd really like to have the routing set up that way, by default, for the users. Second, I really want to use an embedded certificate format in the ovpn for the pkcs12 file rather than shipping two separate files. I see that (from what I can tell) I should be able to replace the above line with this in my ovpn file: -BEGIN CERTIFICATE- ...certificate... -END CERTIFICATE- And, I see that the certificate has to be base64 encoded; of course my .p12 file is not: it's just a binary file. So after reading some things I ran this: openssl base64 -in /path/to/my.p12 > my.p12.b64 Then I imported that my.p12.b64 into my ovpn file in between the BEGIN/END CERTIFICATE lines. This SEEMED to work in that networkmanager accepted the contents of that file without complaint, but when I attempt to connect it fails. Looking at journalctl output I see the error is: nm-openvpn[31545]: OpenVPN 2.3.11 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Jun 22 2016 nm-openvpn[31545]: library versions: OpenSSL 1.0.2g 1 Mar 2016, LZO 2.08 nm-openvpn[31545]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts nm-openvpn[31545]: OpenSSL: error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag nm-openvpn[31545]: OpenSSL: error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error nm-openvpn[31545]: Error reading PKCS#12 file /home/paul/.cert/nm-openvpn/my-pkcs12.pem nm-openvpn[31545]: Exiting due to fatal error NetworkManager[948]: nm-openvpn[31539] openvpn[31545] exited with error code 1 Looking at /home/paul/.cert/nm-openvpn/my-pkcs12.pem I can see that it's not the same as my original .p12 file, plus by the name it seems that a PEM file is expected here instead maybe? All my attempts to work out what format things need to be in to make this work have failed. Anyone have any help for either of these problems? Thanks! ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: network manager does not lauch openvpn
On Tue, 2017-01-31 at 14:30 -0200, Ethy H. Brito wrote: > Hi all > > environment: Ubuntu 14.04 LTS (gnome) > > Left clicking NM at status bar, selecting VPN connections -> > myopenvpn does nothing. > > But I can start it from console like "nmcli c up id myopenvpn" > > Also I cannot shut it down from there, but i can from console. > > "/var/log/syslog" or dmesg are of no help. They both shows nothing > about it > when launching from graphics interface. > > How can I debug why it does not launch from graphic interface? > > Cheers > > Ethy > Hi, the GUI should do something very similar to what nmcli does. So, it's unclear why it wouldn't work. It's also not clear which GUI you are using, as there are several. Is it nm-applet? best, 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
network manager does not lauch openvpn
Hi all environment: Ubuntu 14.04 LTS (gnome) Left clicking NM at status bar, selecting VPN connections -> myopenvpn does nothing. But I can start it from console like "nmcli c up id myopenvpn" Also I cannot shut it down from there, but i can from console. "/var/log/syslog" or dmesg are of no help. They both shows nothing about it when launching from graphics interface. How can I debug why it does not launch from graphic interface? Cheers Ethy ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] openvpn: Add support for tls-crypt
On Sun, 2017-01-29 at 04:44 +0100, Pau Espin Pedrol wrote: > Signed-off-by: Pau Espin Pedrol > --- followed up on https://bugzilla.gnome.org/show_bug.cgi?id=68#c2 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
[PATCH] openvpn: Add support for tls-crypt
Signed-off-by: Pau Espin Pedrol
---
properties/import-export.c | 16 ++--
shared/utils.h | 1 +
src/nm-openvpn-service.c | 14 +-
3 files changed, 20 insertions(+), 11 deletions(-)
diff --git a/properties/import-export.c b/properties/import-export.c
index 1993026..eec662a 100644
--- a/properties/import-export.c
+++ b/properties/import-export.c
@@ -44,6 +44,7 @@
#define INLINE_BLOB_PKCS12 "pkcs12"
#define INLINE_BLOB_SECRET "secret"
#define INLINE_BLOB_TLS_AUTH"tls-auth"
+#define INLINE_BLOB_TLS_CRYPT "tls-crypt"
const char *_nmovpn_test_temp_path = NULL;
@@ -1155,7 +1156,8 @@ do_import (const char *path, const char *contents, gsize
contents_len, GError **
NMV_OVPN_TAG_CERT,
NMV_OVPN_TAG_KEY,
NMV_OVPN_TAG_SECRET,
-NMV_OVPN_TAG_TLS_AUTH)) {
+NMV_OVPN_TAG_TLS_AUTH,
+NMV_OVPN_TAG_TLS_CRYPT)) {
const char *file;
gs_free char *file_free = NULL;
gboolean can_have_direction;
@@ -1196,7 +1198,7 @@ do_import (const char *path, const char *contents, gsize
contents_len, GError **
if (s_direction)
setting_vpn_add_data_item (s_vpn,
NM_OPENVPN_KEY_STATIC_KEY_DIRECTION, s_direction);
have_sk = TRUE;
- } else if (NM_IN_STRSET (params[0],
NMV_OVPN_TAG_TLS_AUTH)) {
+ } else if (NM_IN_STRSET (params[0],
NMV_OVPN_TAG_TLS_AUTH, NMV_OVPN_TAG_TLS_CRYPT)) {
setting_vpn_add_data_item_path (s_vpn,
NM_OPENVPN_KEY_TA, file);
if (s_direction)
setting_vpn_add_data_item (s_vpn,
NM_OPENVPN_KEY_TA_DIR, s_direction);
@@ -1401,6 +1403,8 @@ do_import (const char *path, const char *contents, gsize
contents_len, GError **
key = NM_OPENVPN_KEY_KEY;
else if (nm_streq (token, INLINE_BLOB_PKCS12))
key = NULL;
+ else if (nm_streq (token, INLINE_BLOB_TLS_CRYPT))
+ key = NM_OPENVPN_KEY_TA;
else if (nm_streq (token, INLINE_BLOB_TLS_AUTH)) {
key = NM_OPENVPN_KEY_TA;
can_have_direction = TRUE;
@@ -1948,11 +1952,12 @@ do_export_create (NMConnection *connection, const char
*path, GError **error)
ta_key = nm_setting_vpn_get_data_item (s_vpn,
NM_OPENVPN_KEY_TA);
if (_arg_is_set (ta_key)) {
gs_free char *s_free = NULL;
-
+ const char *ta_dir = nm_setting_vpn_get_data_item
(s_vpn, NM_OPENVPN_KEY_TA_DIR);
+ const char *tls_type = _arg_is_set (ta_dir) ?
NMV_OVPN_TAG_TLS_AUTH : NMV_OVPN_TAG_TLS_CRYPT;
args_write_line (f,
-NMV_OVPN_TAG_TLS_AUTH,
+tls_type,
nmv_utils_str_utf8safe_unescape_c
(ta_key, &s_free),
-_arg_is_set
(nm_setting_vpn_get_data_item (s_vpn, NM_OPENVPN_KEY_TA_DIR)));
+_arg_is_set (ta_dir));
}
}
@@ -2093,4 +2098,3 @@ do_export (const char *path, NMConnection *connection,
GError **error)
return TRUE;
}
-
diff --git a/shared/utils.h b/shared/utils.h
index 61b35b6..05b8076 100644
--- a/shared/utils.h
+++ b/shared/utils.h
@@ -67,6 +67,7 @@
#define NMV_OVPN_TAG_TLS_AUTH "tls-auth"
#define NMV_OVPN_TAG_TLS_CIPHER "tls-cipher"
#define NMV_OVPN_TAG_TLS_CLIENT "tls-client"
+#define NMV_OVPN_TAG_TLS_CRYPT "tls-crypt"
#define NMV_OVPN_TAG_TLS_REMOTE "tls-remote"
#define NMV_OVPN_TAG_TOPOLOGY "topology"
#define NMV_OVPN_TAG_TUN_IPV6 "tun-ipv6"
diff --git a/src/nm-openvpn-service.c b/src/nm-openvpn-service.c
index d7bd29f..fbb0473 100644
--- a/src/nm-openvpn-service.c
+++ b/src/nm-openvpn-service.c
@@ -1441,12 +1441,16 @@ nm_openvpn_start_openvpn_binary (NMOpenvpnPlugin
*plugin,
/* TA */
tmp = nm_setting_vpn_get_data_item (s_vpn, NM_OPENVPN_KEY_TA);
if (tmp && strlen (tmp)) {
- add_openvpn_arg (args, "--tls-auth");
- add_openvpn_arg_utf8safe (args, tmp);
- tmp = nm_setting_vpn_get_data_item (s_vpn,
NM_OPENVPN_KEY_TA_DIR);
- if (tmp && strlen (tmp))
-
Re: unable to use openvpn server which uses "push route..."
On Tue, 2017-01-24 at 21:17 +0900, Tomasz Chmielewski wrote: > On 2017-01-24 21:04, Thomas Haller wrote: > > in many common setups, the VPN gateway will forward whatever > > packets > > you send it. I don't agree that "would almost never work" is > > accurate. > > With OpenVPN? I'd disagree. If it's the case with OpenVPN, than it > usually means that someone misconfigured OpenVPN server. > > It wouldn't normally act as a gateway without: > > # If enabled, this directive will configure > # all clients to redirect their default > # network gateway through the VPN, causing > # all IP traffic such as web browsing and > # and DNS lookups to go through the VPN > # (The OpenVPN server machine may need to NAT > # or bridge the TUN/TAP interface to the internet > # in order for this to work properly). > ;push "redirect-gateway def1 bypass-dhcp" Hi Tomasz, what you quote doesn't say anything about whether the server would actually forward traffic for the default-route. It says, that clients are encouraged to configure the default-route via the VPN gateway. Depending on how you configure openvpn client- side, it may follow the server's suggestion (--pull, ipv4.never- default). Whether server-side would route traffic to a certain destination depends on the server's routes, iptable rules, ip_forward, and openvpn options. But there is no real disagreement here. A ~server-choice~ option certainly would make sense. I merely said, that I don't agree with "would almost never work". best, 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: unable to use openvpn server which uses "push route..."
On 2017-01-24 21:04, Thomas Haller wrote: On Tue, 2017-01-24 at 09:55 +0900, Tomasz Chmielewski wrote: On 2017-01-24 03:05, Thomas Haller wrote: > > Please advise how to use NetworkManager for OpenVPN servers which > > are > > not default gateways and which push their own routes. > > whether the VPN gets the default route, depends on the (inverse) > "ipv4.never-default" setting. See `nmcli connection show "$MY_VPN"` Why does NM attempt to set a default route for a OpenVPN connection where the OpenVPN server does not advertise itself as a default route? It would almost never work, and sounds like a bug to me. in many common setups, the VPN gateway will forward whatever packets you send it. I don't agree that "would almost never work" is accurate. With OpenVPN? I'd disagree. If it's the case with OpenVPN, than it usually means that someone misconfigured OpenVPN server. It wouldn't normally act as a gateway without: # If enabled, this directive will configure # all clients to redirect their default # network gateway through the VPN, causing # all IP traffic such as web browsing and # and DNS lookups to go through the VPN # (The OpenVPN server machine may need to NAT # or bridge the TUN/TAP interface to the internet # in order for this to work properly). ;push "redirect-gateway def1 bypass-dhcp" Whether the default-route is routed along the VPN should be primarily configured client-side (NetworkManager). Optimally, ip4.never-default would support a 3rd value ~server-choice~, beside "yes" and "no". To allow the server to override it. This is a missing feature. And it should default to ~server-choice~. Tomasz Chmielewski https://lxadm.com ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: unable to use openvpn server which uses "push route..."
On Tue, 2017-01-24 at 09:55 +0900, Tomasz Chmielewski wrote: > On 2017-01-24 03:05, Thomas Haller wrote: > > > > Please advise how to use NetworkManager for OpenVPN servers which > > > are > > > not default gateways and which push their own routes. > > > > whether the VPN gets the default route, depends on the (inverse) > > "ipv4.never-default" setting. See `nmcli connection show "$MY_VPN"` > > Why does NM attempt to set a default route for a OpenVPN connection > where the OpenVPN server does not advertise itself as a default > route? > It would almost never work, and sounds like a bug to me. in many common setups, the VPN gateway will forward whatever packets you send it. I don't agree that "would almost never work" is accurate. Whether the default-route is routed along the VPN should be primarily configured client-side (NetworkManager). Optimally, ip4.never-default would support a 3rd value ~server-choice~, beside "yes" and "no". To allow the server to override it. This is a missing feature. > Anyway, with "Use this connection only for resources on its network" > set: > > # nmcli connection show $MY_VPN|grep never-default > ipv4.never-default: yes > ipv6.never-default: no > > > It no longer sets the connection as a default route. > > > > Try to enable debug-logging of the VPN server: > > > > sudo nmcli logging general level TRACE domains ALL:VPN_PLUGIN > > # nmcli logging general level TRACE domains ALL:VPN_PLUGIN > Error: Object 'logging' is unknown, try 'nmcli help'. ah, right. Typo > # nmcli general logging level TRACE domains ALL:VPN_PLUGIN > Error: failed to set logging: Unknown log level 'VPN_PLUGIN' > > So in the end I came up with this one: > > # nmcli general logging level TRACE domains VPN Another typo. sorry. Should be: sudo nmcli general logging level TRACE domains ALL,VPN_PLUGIN It should be "VPN_PLUGIN". This enables debug logging for the VPN service itself (openvpn). Contrary to the "VPN" logging domain, which is VPN related logging inside NetworkManager. If "VPN_PLUGIN" is unrecognized, your NM version is too old for it. In that case, you would need to follow https://wiki.gnome.org/Projects/NetworkManager/Debugging#Debugging_NetworkManager-openvpn to get debugging logs from the VPN service itself. > And it helped me debug this - thanks! cool Best, 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: unable to use openvpn server which uses "push route..."
On 2017-01-24 01:55, Tomasz Chmielewski wrote: > On 2017-01-24 03:05, Thomas Haller wrote: > >>> Please advise how to use NetworkManager for OpenVPN servers which >>> are >>> not default gateways and which push their own routes. >> >> whether the VPN gets the default route, depends on the (inverse) >> "ipv4.never-default" setting. See `nmcli connection show "$MY_VPN"` > > Why does NM attempt to set a default route for a OpenVPN connection where the > OpenVPN server does not advertise itself as a default route? It would > almost never work, and sounds like a bug to me. > > Anyway, with "Use this connection only for resources on its network" set: > > # nmcli connection show $MY_VPN|grep never-default > ipv4.never-default: yes > ipv6.never-default: no > > > It no longer sets the connection as a default route. > > >> Try to enable debug-logging of the VPN server: >> >> sudo nmcli logging general level TRACE domains ALL:VPN_PLUGIN > > # nmcli logging general level TRACE domains ALL:VPN_PLUGIN > Error: Object 'logging' is unknown, try 'nmcli help'. > # nmcli general logging level TRACE domains ALL:VPN_PLUGIN > Error: failed to set logging: Unknown log level 'VPN_PLUGIN' > > So in the end I came up with this one: > > # nmcli general logging level TRACE domains VPN > > And it helped me debug this - thanks! The main problem is that OpenVPN does not export if the route is intended as a default-route to the --up script, hence NetworkManager can't deduce what it should do. I submitted a pull request a few months ago, but haven't got any response yet: https://github.com/OpenVPN/openvpn/pull/69 /Anders Blomdell -- Anders Blomdell Email: anders.blomd...@control.lth.se Department of Automatic Control Lund University Phone:+46 46 222 4625 P.O. Box 118 Fax: +46 46 138118 SE-221 00 Lund, Sweden ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: unable to use openvpn server which uses "push route..."
On 2017-01-24 03:05, Thomas Haller wrote: Please advise how to use NetworkManager for OpenVPN servers which are not default gateways and which push their own routes. whether the VPN gets the default route, depends on the (inverse) "ipv4.never-default" setting. See `nmcli connection show "$MY_VPN"` Why does NM attempt to set a default route for a OpenVPN connection where the OpenVPN server does not advertise itself as a default route? It would almost never work, and sounds like a bug to me. Anyway, with "Use this connection only for resources on its network" set: # nmcli connection show $MY_VPN|grep never-default ipv4.never-default: yes ipv6.never-default: no It no longer sets the connection as a default route. Try to enable debug-logging of the VPN server: sudo nmcli logging general level TRACE domains ALL:VPN_PLUGIN # nmcli logging general level TRACE domains ALL:VPN_PLUGIN Error: Object 'logging' is unknown, try 'nmcli help'. # nmcli general logging level TRACE domains ALL:VPN_PLUGIN Error: failed to set logging: Unknown log level 'VPN_PLUGIN' So in the end I came up with this one: # nmcli general logging level TRACE domains VPN And it helped me debug this - thanks! Tomasz Chmielewski https://lxadm.com ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: unable to use openvpn server which uses "push route..."
On Mon, 2017-01-23 at 23:34 +0900, Tomasz Chmielewski wrote: > I have a VPN server which uses "push route..." options to push > specific > routes to the clients: > > # testing1 > push "route 10.11.0.0 255.255.255.0" > > # testing2 > push "route 10.12.0.0 255.255.255.0" > > # testing3 > push "route 10.13.1.0 255.255.255.0" > > > The same config file works correctly with command line openvpn on > Linux > (openvpn --config some.conf), with OpenVPN client for Windows, with > OpenVPN client for Mac (TunnelBlick), with OpenVPN clients for > Android > and iOS - the routes are pushed to the clients. However, it does not > work when the config is imported via NetworkManager (used version > 1.2.6 > on Ubuntu 16.10, but also tried several earlier Ubuntu versions, to > no > avail). > > > To reproduce: > > case 1) in NM, import a openvpn config file where the server uses > "push > route..." option, but is *not* a default gateway (i.e. no "push > redirect-gateway..." on the server). > > Expected result: config file is imported, when we initiate the > connection via NM, the routes pushed by the server are applied on > the > client > > Real result: NM routes *all* traffic through the established > connection. > There is no connectivity anywhere anymore (device is "offlined"). > > > > case 2) in NM, import a openvpn config file where the server uses > "push > route..." option, but is *not* a default gateway (i.e. no "push > redirect-gateway..." on the server). > Additionally, in IPv4 settings -> Routes for this OpenVPN config, we > select "Use this connection only for resources on its network". > > Expected result: config file is imported, when we initiate the > connection via NM, the routes pushed by the server are applied on > the > client > > Real result: routes pushed by the server are not applied on the > client. > > > > Please advise how to use NetworkManager for OpenVPN servers which > are > not default gateways and which push their own routes. > Hi, whether the VPN gets the default route, depends on the (inverse) "ipv4.never-default" setting. See `nmcli connection show "$MY_VPN"` Try to enable debug-logging of the VPN server: sudo nmcli logging general level TRACE domains ALL:VPN_PLUGIN (you need to re-activate the VPN connection for the change to take effect). (don't send the logfile with VPN_PLUGIN domain enabled, because it might contain private data) The "import" step is entirely separate from the later activation handling. That is, during import, the ovpn file is transformed to a NetworkManager connection profile. Whether you import a ovpn or click it manually makes no difference for the activation. Of course, it would be interesting *what* you actually import, and how NM's connection profile looks after the import step. best, 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
unable to use openvpn server which uses "push route..."
I have a VPN server which uses "push route..." options to push specific routes to the clients: # testing1 push "route 10.11.0.0 255.255.255.0" # testing2 push "route 10.12.0.0 255.255.255.0" # testing3 push "route 10.13.1.0 255.255.255.0" The same config file works correctly with command line openvpn on Linux (openvpn --config some.conf), with OpenVPN client for Windows, with OpenVPN client for Mac (TunnelBlick), with OpenVPN clients for Android and iOS - the routes are pushed to the clients. However, it does not work when the config is imported via NetworkManager (used version 1.2.6 on Ubuntu 16.10, but also tried several earlier Ubuntu versions, to no avail). To reproduce: case 1) in NM, import a openvpn config file where the server uses "push route..." option, but is *not* a default gateway (i.e. no "push redirect-gateway..." on the server). Expected result: config file is imported, when we initiate the connection via NM, the routes pushed by the server are applied on the client Real result: NM routes *all* traffic through the established connection. There is no connectivity anywhere anymore (device is "offlined"). case 2) in NM, import a openvpn config file where the server uses "push route..." option, but is *not* a default gateway (i.e. no "push redirect-gateway..." on the server). Additionally, in IPv4 settings -> Routes for this OpenVPN config, we select "Use this connection only for resources on its network". Expected result: config file is imported, when we initiate the connection via NM, the routes pushed by the server are applied on the client Real result: routes pushed by the server are not applied on the client. Please advise how to use NetworkManager for OpenVPN servers which are not default gateways and which push their own routes. Tomasz Chmielewski https://lxadm.com ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: How to avoid using policy kit with openvpn
I just noticed that I inserted that "Ping started to work" after wrong message chain. That must have been pretty confusing. I'm not worried about OpenVPN at the moment. It seems working quite well now. As I told before, problem was triggered uncompressing cert archive so that it produced /etc/openvpn directory whose owner did not exist in system records. There was no way back. Only re-installing Linux helped. These last messages should have been following chain with title: "Problems getting device state change events through" I'm terribly sorry about this confusion. -Matti 2016-12-15 19:36 GMT+02:00 matti kaasinen : > > 2016-12-15 18:41 GMT+02:00 Dan Williams : > >> > *route add default dev eth0 metric 99* >> > So, everything is fine! >> >> That implies that the default route was not set up correctly >> beforehand. What's the output of "ip route" before you add that >> default route? >> > Yes, there was no default route set at all. In fact it should have been > created by avahi-autoipd.action script command: > > ip route add default dev "$2" metric "$METRIC" scope link ||: > > Somehow this did not do the trick. I changed that to: > > ip route add default dev "$2" metric "$METRIC"||: > > Default route was produced after that. I did not check that command > manually, but I suppose that ip command is coming from busybox and do not > support ip command properly. It's also possibly that I had ordinary ip > command installed in that older set-up, I don > > I found out just before leaving office that connection did not recover > after unplugging and plugging again. It could come from the fact that I did > not fix "CONFLICT|UNBIND|STOP" branch of avahi-autoipd.action script that > seems also having these "scope link" statements. I'll check that tomorrow > >> >> You might try setting the "never-default" option in the VPN >> connection's config to "true", to indicate that the VPN shouldn't grab >> the default route. >> > I'll check this tomorrow. > > Thanks, > Matti > > > ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: How to avoid using policy kit with openvpn
2016-12-15 18:41 GMT+02:00 Dan Williams : > > *route add default dev eth0 metric 99* > > So, everything is fine! > > That implies that the default route was not set up correctly > beforehand. What's the output of "ip route" before you add that > default route? > Yes, there was no default route set at all. In fact it should have been created by avahi-autoipd.action script command: ip route add default dev "$2" metric "$METRIC" scope link ||: Somehow this did not do the trick. I changed that to: ip route add default dev "$2" metric "$METRIC"||: Default route was produced after that. I did not check that command manually, but I suppose that ip command is coming from busybox and do not support ip command properly. It's also possibly that I had ordinary ip command installed in that older set-up, I don I found out just before leaving office that connection did not recover after unplugging and plugging again. It could come from the fact that I did not fix "CONFLICT|UNBIND|STOP" branch of avahi-autoipd.action script that seems also having these "scope link" statements. I'll check that tomorrow > > You might try setting the "never-default" option in the VPN > connection's config to "true", to indicate that the VPN shouldn't grab > the default route. > I'll check this tomorrow. Thanks, Matti ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: How to avoid using policy kit with openvpn
On Thu, 2016-12-15 at 15:14 +0200, matti kaasinen wrote: > Ping started to work after executing command: > > > *route add default dev eth0 metric 99* > So, everything is fine! That implies that the default route was not set up correctly beforehand. What's the output of "ip route" before you add that default route? You might try setting the "never-default" option in the VPN connection's config to "true", to indicate that the VPN shouldn't grab the default route. Dan > Cheers, > Matti > > 2016-12-13 11:37 GMT+02:00 matti kaasinen : > > > > > Lubomir, Dan, > > I found what triggers this issue. I don't know what the reason is, > > though! > > It has nothing to do with NetworkManager. > > > > The trigger: > > 1) I load openvpn cert as zipped tar archive to root. > > 2) I uncompress/untar the archive that creates /etc/openvpn > > directory with > > openvpn cert/config files, user = original user. > > There is no way back at this point. Whole system is corrupted. It > > does not > > help deleting /etc/openvpn directory and note that it is not needed > > to > > start openvpn service to get this triggered. Only way I have found > > to > > recover is re-install whole system! > > > > I'm somewhat worried how easily one can corrupt whole Linux system > > - just > > load files to /etc whose user is not a proper user of the > > installation! > > They can be loaded to other place, change owner there and load then > > tho > > /etc. Anyhow this is none of your worry, I suppose. > > > > Cheers, > > Matti > > > > 2016-12-09 16:35 GMT+02:00 matti kaasinen > >: > > > > > > > > Lubo, > > > It took some time before I had change to get to this issue again. > > > I got > > > new board and it did not start at all, so I had to study u-boot > > > in between.. > > > Anyhow, answers to your comments: > > > > > > 2016-11-25 18:15 GMT+02:00 Lubomir Rintel : > > > > > > > > > > > That sounds very strange. > > > > > > > > Please enable eavesdropping on the system bus: > > > > https://wiki.ubuntu.com/DebuggingDBus#How_to_monitor_the_system > > > > _bus > > > > > > > > And then monitor the actual bus traffic before starting the > > > > "openvpn > > > > service" (is that the NM VPN plugin?) and after starting it and > > > > look > > > > out for what changed. > > > > > > > No. That is coming from Yocto/meta-openembedded/meta-networking > > > layer. > > > Just pure openvpn binary and systemd unit file for starting > > > service. > > > Only (main) difference I noticed from dbus-monitor log was that > > > before > > > openvpn I got following errors: > > > > > > string "Could not get owner of name > > > 'org.freedesktop.nm_avahi_autoipd': > > > no such name" > > > string "Could not get owner of name > > > 'org.fedoraproject.FirewallD1': > > > no such name" > > > string "Could not get owner of name 'org.freedesktop.login1': > > > no such > > > name" > > > string "Could not get owner of name 'org.bluez': no such name" > > > string "Could not get owner of name > > > 'org.freedesktop.ModemManager1': > > > no such name" > > > string "Could not get owner of name 'org.bluez': no such name" > > > string "Could not get owner of name > > > 'org.freedesktop.nm_dispatcher': > > > no such name" > > > > > > And after enabling openvpn service I got: > > > > > > string "Could not get owner of name > > > 'org.freedesktop.nm_avahi_autoipd': > > > no such name" > > > string "Could not get owner of name > > > 'org.fedoraproject.FirewallD1': > > > no such name" > > > string "Could not get owner of name 'org.freedesktop.login1': > > > no such > > > name" > > > string "Could not get owner of name 'org.bluez': no such name" > > > string "Could not get owner of name > > > 'org.freedesktop.PolicyKit1': no > > > such name" > > > string "Could not get owner of name &#x
Re: How to avoid using policy kit with openvpn
Ping started to work after executing command: *route add default dev eth0 metric 99* So, everything is fine! Cheers, Matti 2016-12-13 11:37 GMT+02:00 matti kaasinen : > Lubomir, Dan, > I found what triggers this issue. I don't know what the reason is, though! > It has nothing to do with NetworkManager. > > The trigger: > 1) I load openvpn cert as zipped tar archive to root. > 2) I uncompress/untar the archive that creates /etc/openvpn directory with > openvpn cert/config files, user = original user. > There is no way back at this point. Whole system is corrupted. It does not > help deleting /etc/openvpn directory and note that it is not needed to > start openvpn service to get this triggered. Only way I have found to > recover is re-install whole system! > > I'm somewhat worried how easily one can corrupt whole Linux system - just > load files to /etc whose user is not a proper user of the installation! > They can be loaded to other place, change owner there and load then tho > /etc. Anyhow this is none of your worry, I suppose. > > Cheers, > Matti > > 2016-12-09 16:35 GMT+02:00 matti kaasinen : > >> Lubo, >> It took some time before I had change to get to this issue again. I got >> new board and it did not start at all, so I had to study u-boot in between.. >> Anyhow, answers to your comments: >> >> 2016-11-25 18:15 GMT+02:00 Lubomir Rintel : >> >>> That sounds very strange. >>> >>> Please enable eavesdropping on the system bus: >>> https://wiki.ubuntu.com/DebuggingDBus#How_to_monitor_the_system_bus >>> >>> And then monitor the actual bus traffic before starting the "openvpn >>> service" (is that the NM VPN plugin?) and after starting it and look >>> out for what changed. >>> >> No. That is coming from Yocto/meta-openembedded/meta-networking layer. >> Just pure openvpn binary and systemd unit file for starting service. >> Only (main) difference I noticed from dbus-monitor log was that before >> openvpn I got following errors: >> >>string "Could not get owner of name 'org.freedesktop.nm_avahi_autoipd': >> no such name" >>string "Could not get owner of name 'org.fedoraproject.FirewallD1': >> no such name" >>string "Could not get owner of name 'org.freedesktop.login1': no such >> name" >> string "Could not get owner of name 'org.bluez': no such name" >>string "Could not get owner of name 'org.freedesktop.ModemManager1': >> no such name" >>string "Could not get owner of name 'org.bluez': no such name" >>string "Could not get owner of name 'org.freedesktop.nm_dispatcher': >> no such name" >> >> And after enabling openvpn service I got: >> >>string "Could not get owner of name 'org.freedesktop.nm_avahi_autoipd': >> no such name" >>string "Could not get owner of name 'org.fedoraproject.FirewallD1': >> no such name" >>string "Could not get owner of name 'org.freedesktop.login1': no such >> name" >>string "Could not get owner of name 'org.bluez': no such name" >>string "Could not get owner of name 'org.freedesktop.PolicyKit1': no >> such name" >>string "Could not get owner of name 'org.bluez': no such name" >>string "Could not get owner of name 'org.freedesktop.nm_dispatcher': >> no such name" >> >> So, policy kit has vanished. >> >> I'm not sure at all that I could concentrate on the correct details of >> these logs, though. So, I would really appreciate any suggestions. >> >> What I noticed from systemd journal regarding ntp synchronization was: >> >> Dec 09 15:08:47 cpr3 systemd[1]: Starting Network Time Synchronization... >> Dec 09 15:08:47 cpr3 systemd-timesyncd[467]: [[0;1;31mFailed to allocate >> manager: Permission denied[[0m >> Dec 09 15:08:47 cpr3 systemd[1]: [[0;1;39msystemd-timesyncd.service: >> Main process exited, code=exited, status=1/FAILURE[[0m >> Dec 09 15:08:47 cpr3 systemd[1]: [[0;1;31mFailed to start Network Time >> Synchronization.[[0m >> Dec 09 15:08:47 cpr3 systemd[1]: [[0;1;39msystemd-timesyncd.service: >> Unit entered failed state.[[0m >> Dec 09 15:08:47 cpr3 systemd[1]: [[0;1;39msystemd-timesyncd.service: >> Failed with result 'exit-code'.[[0m >> Dec 09 15:08:47 cpr3 systemd[1]: systemd-timesyncd.service: Service has >
Re: How to avoid using policy kit with openvpn
Lubomir, Dan, I found what triggers this issue. I don't know what the reason is, though! It has nothing to do with NetworkManager. The trigger: 1) I load openvpn cert as zipped tar archive to root. 2) I uncompress/untar the archive that creates /etc/openvpn directory with openvpn cert/config files, user = original user. There is no way back at this point. Whole system is corrupted. It does not help deleting /etc/openvpn directory and note that it is not needed to start openvpn service to get this triggered. Only way I have found to recover is re-install whole system! I'm somewhat worried how easily one can corrupt whole Linux system - just load files to /etc whose user is not a proper user of the installation! They can be loaded to other place, change owner there and load then tho /etc. Anyhow this is none of your worry, I suppose. Cheers, Matti 2016-12-09 16:35 GMT+02:00 matti kaasinen : > Lubo, > It took some time before I had change to get to this issue again. I got > new board and it did not start at all, so I had to study u-boot in between.. > Anyhow, answers to your comments: > > 2016-11-25 18:15 GMT+02:00 Lubomir Rintel : > >> That sounds very strange. >> >> Please enable eavesdropping on the system bus: >> https://wiki.ubuntu.com/DebuggingDBus#How_to_monitor_the_system_bus >> >> And then monitor the actual bus traffic before starting the "openvpn >> service" (is that the NM VPN plugin?) and after starting it and look >> out for what changed. >> > No. That is coming from Yocto/meta-openembedded/meta-networking layer. > Just pure openvpn binary and systemd unit file for starting service. > Only (main) difference I noticed from dbus-monitor log was that before > openvpn I got following errors: > >string "Could not get owner of name 'org.freedesktop.nm_avahi_autoipd': > no such name" >string "Could not get owner of name 'org.fedoraproject.FirewallD1': no > such name" >string "Could not get owner of name 'org.freedesktop.login1': no such > name" >string "Could not get owner of name 'org.bluez': no such name" >string "Could not get owner of name 'org.freedesktop.ModemManager1': > no such name" >string "Could not get owner of name 'org.bluez': no such name" >string "Could not get owner of name 'org.freedesktop.nm_dispatcher': > no such name" > > And after enabling openvpn service I got: > >string "Could not get owner of name 'org.freedesktop.nm_avahi_autoipd': > no such name" >string "Could not get owner of name 'org.fedoraproject.FirewallD1': no > such name" >string "Could not get owner of name 'org.freedesktop.login1': no such > name" >string "Could not get owner of name 'org.bluez': no such name" >string "Could not get owner of name 'org.freedesktop.PolicyKit1': no > such name" >string "Could not get owner of name 'org.bluez': no such name" >string "Could not get owner of name 'org.freedesktop.nm_dispatcher': > no such name" > > So, policy kit has vanished. > > I'm not sure at all that I could concentrate on the correct details of > these logs, though. So, I would really appreciate any suggestions. > > What I noticed from systemd journal regarding ntp synchronization was: > > Dec 09 15:08:47 cpr3 systemd[1]: Starting Network Time Synchronization... > Dec 09 15:08:47 cpr3 systemd-timesyncd[467]: [[0;1;31mFailed to allocate > manager: Permission denied[[0m > Dec 09 15:08:47 cpr3 systemd[1]: [[0;1;39msystemd-timesyncd.service: Main > process exited, code=exited, status=1/FAILURE[[0m > Dec 09 15:08:47 cpr3 systemd[1]: [[0;1;31mFailed to start Network Time > Synchronization.[[0m > Dec 09 15:08:47 cpr3 systemd[1]: [[0;1;39msystemd-timesyncd.service: Unit > entered failed state.[[0m > Dec 09 15:08:47 cpr3 systemd[1]: [[0;1;39msystemd-timesyncd.service: > Failed with result 'exit-code'.[[0m > Dec 09 15:08:47 cpr3 systemd[1]: systemd-timesyncd.service: Service has no > hold-off time, scheduling restart. > Dec 09 15:08:47 cpr3 systemd[1]: Stopped Network Time Synchronization. > Dec 09 15:08:47 cpr3 systemd[1]: Starting Network Time Synchronization... > > > Avahi was behaving pretty much the same besides that "Permission denied" > message: > > Dec 09 15:09:01 cpr3 systemd[1]: Starting Avahi mDNS/DNS-SD Stack... > Dec 09 15:09:01 cpr3 systemd[1]: [[0;1;39mavahi-daemon.service: Main > process exited, code=exited, stat
Re: How to avoid using policy kit with openvpn
Lubo, It took some time before I had change to get to this issue again. I got new board and it did not start at all, so I had to study u-boot in between.. Anyhow, answers to your comments: 2016-11-25 18:15 GMT+02:00 Lubomir Rintel : > That sounds very strange. > > Please enable eavesdropping on the system bus: > https://wiki.ubuntu.com/DebuggingDBus#How_to_monitor_the_system_bus > > And then monitor the actual bus traffic before starting the "openvpn > service" (is that the NM VPN plugin?) and after starting it and look > out for what changed. > No. That is coming from Yocto/meta-openembedded/meta-networking layer. Just pure openvpn binary and systemd unit file for starting service. Only (main) difference I noticed from dbus-monitor log was that before openvpn I got following errors: string "Could not get owner of name 'org.freedesktop.nm_avahi_autoipd': no such name" string "Could not get owner of name 'org.fedoraproject.FirewallD1': no such name" string "Could not get owner of name 'org.freedesktop.login1': no such name" string "Could not get owner of name 'org.bluez': no such name" string "Could not get owner of name 'org.freedesktop.ModemManager1': no such name" string "Could not get owner of name 'org.bluez': no such name" string "Could not get owner of name 'org.freedesktop.nm_dispatcher': no such name" And after enabling openvpn service I got: string "Could not get owner of name 'org.freedesktop.nm_avahi_autoipd': no such name" string "Could not get owner of name 'org.fedoraproject.FirewallD1': no such name" string "Could not get owner of name 'org.freedesktop.login1': no such name" string "Could not get owner of name 'org.bluez': no such name" string "Could not get owner of name 'org.freedesktop.PolicyKit1': no such name" string "Could not get owner of name 'org.bluez': no such name" string "Could not get owner of name 'org.freedesktop.nm_dispatcher': no such name" So, policy kit has vanished. I'm not sure at all that I could concentrate on the correct details of these logs, though. So, I would really appreciate any suggestions. What I noticed from systemd journal regarding ntp synchronization was: Dec 09 15:08:47 cpr3 systemd[1]: Starting Network Time Synchronization... Dec 09 15:08:47 cpr3 systemd-timesyncd[467]: [[0;1;31mFailed to allocate manager: Permission denied[[0m Dec 09 15:08:47 cpr3 systemd[1]: [[0;1;39msystemd-timesyncd.service: Main process exited, code=exited, status=1/FAILURE[[0m Dec 09 15:08:47 cpr3 systemd[1]: [[0;1;31mFailed to start Network Time Synchronization.[[0m Dec 09 15:08:47 cpr3 systemd[1]: [[0;1;39msystemd-timesyncd.service: Unit entered failed state.[[0m Dec 09 15:08:47 cpr3 systemd[1]: [[0;1;39msystemd-timesyncd.service: Failed with result 'exit-code'.[[0m Dec 09 15:08:47 cpr3 systemd[1]: systemd-timesyncd.service: Service has no hold-off time, scheduling restart. Dec 09 15:08:47 cpr3 systemd[1]: Stopped Network Time Synchronization. Dec 09 15:08:47 cpr3 systemd[1]: Starting Network Time Synchronization... Avahi was behaving pretty much the same besides that "Permission denied" message: Dec 09 15:09:01 cpr3 systemd[1]: Starting Avahi mDNS/DNS-SD Stack... Dec 09 15:09:01 cpr3 systemd[1]: [[0;1;39mavahi-daemon.service: Main process exited, code=exited, status=255/n/a[[0m Dec 09 15:09:01 cpr3 systemd[1]: [[0;1;31mFailed to start Avahi mDNS/DNS-SD Stack.[[0m Dec 09 15:09:01 cpr3 systemd[1]: [[0;1;39mavahi-daemon.service: Unit entered failed state.[[0m Dec 09 15:09:01 cpr3 systemd[1]: [[0;1;39mavahi-daemon.service: Failed with result 'exit-code'.[[0m Dec 09 15:09:01 cpr3 systemd[1]: avahi-daemon.service: Service hold-off time over, scheduling restart. Dec 09 15:09:01 cpr3 systemd[1]: Stopped Avahi mDNS/DNS-SD Stack. Dec 09 15:09:01 cpr3 systemd[1]: Starting Avahi mDNS/DNS-SD Stack... Any help appreciated, -Matti ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: OpenVPN and avoiding default route
Hi, On Tue, 2016-11-29 at 17:48 +0100, Anders Blomdell wrote: > On 2016-11-29 15:40, Thomas Haller wrote: > > On Tue, 2016-11-29 at 15:03 +0100, Anders Blomdell wrote: > > > > > > > > > First attempt of OpenVPN pull request in the RFE. > > > > NetworkManager should probably be modified to parse "redirect- > > > > gateway/redirect-private" > > > > while importing .ovpn files, pointer to the code that does this > > > > would be appreciated. > > > > > > I have started to look into the config parsing and settings > > > handling, > > > is it an intended > > > behavior that NetworkManager brings up the IPv6/IPv4 that OpenVPN > > > provides, regardless of > > > the state of the GUI 'IPv4/IPv6 On/Off' settings? > > > > > > Hi Anders, > > > > I would expect, that if the connection has IPvX disabled, that NM > > doesn't configure any IPvX addresses, regardless of what it > > received > > from the server. If that is different, it sounds like a bug. > > It enables everything it gets from the server, I also consider it a > bug, > hence the question. > > > The logic for that is entirely in the server (NMVpnConnection). The > > plugin collets the data from the environment and sends it back to > > the > > server. There, NMVpnConnection merges the event data with other > > configuration (from NMConnection). > > So it's not nm-openvpn-service-openvpn-helper.c that should check > On/Off > (as given by method=disabled (IPv4)/method=ignore (IPv6) in > /etc/NetworkManager/system-connections/some_vpnconf)? Correct. Because nm-openvpn-service-openvpn-helper doesn't even have the connection to know that the configuration is disabled. NM spawns nm-openvpn-service and sends it the current NMConnection via D-Bus. Based on that, nm-openvpn-service spawns openvpn with some arguments. Eventually, the openvpn process connects and calls back to nm-openvpn- service-openvpn-helper. That one gathers information from argv and the environment variables, and sends the via D-Bus back to nm-openvpn- service (SetConfig call). nm-openvpn-service then emits a "Config" signal, which is received by NetworkManager core... ending up in nm_vpn_connection_config_get(). Then, NM goes through the config that it received and applies it, such as IP addresses. It especially should thereby also consider the configuration in the corresponding NMConnection. 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: OpenVPN and avoiding default route
On 2016-11-29 15:40, Thomas Haller wrote: > On Tue, 2016-11-29 at 15:03 +0100, Anders Blomdell wrote: > >> >>> First attempt of OpenVPN pull request in the RFE. >>> NetworkManager should probably be modified to parse "redirect- >>> gateway/redirect-private" >>> while importing .ovpn files, pointer to the code that does this >>> would be appreciated. >> >> I have started to look into the config parsing and settings handling, >> is it an intended >> behavior that NetworkManager brings up the IPv6/IPv4 that OpenVPN >> provides, regardless of >> the state of the GUI 'IPv4/IPv6 On/Off' settings? > > > Hi Anders, > > I would expect, that if the connection has IPvX disabled, that NM > doesn't configure any IPvX addresses, regardless of what it received > from the server. If that is different, it sounds like a bug. It enables everything it gets from the server, I also consider it a bug, hence the question. > The logic for that is entirely in the server (NMVpnConnection). The > plugin collets the data from the environment and sends it back to the > server. There, NMVpnConnection merges the event data with other > configuration (from NMConnection). So it's not nm-openvpn-service-openvpn-helper.c that should check On/Off (as given by method=disabled (IPv4)/method=ignore (IPv6) in /etc/NetworkManager/system-connections/some_vpnconf)? > Not sure I understand your question though... And I'm not quite clear of the architecture/order of events yet, so please bear with me... /Anders -- Anders Blomdell Email: anders.blomd...@control.lth.se Department of Automatic Control Lund University Phone:+46 46 222 4625 P.O. Box 118 Fax: +46 46 138118 SE-221 00 Lund, Sweden ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: OpenVPN and avoiding default route
On Tue, 2016-11-29 at 15:03 +0100, Anders Blomdell wrote: > > > First attempt of OpenVPN pull request in the RFE. > > NetworkManager should probably be modified to parse "redirect- > > gateway/redirect-private" > > while importing .ovpn files, pointer to the code that does this > > would be appreciated. > > I have started to look into the config parsing and settings handling, > is it an intended > behavior that NetworkManager brings up the IPv6/IPv4 that OpenVPN > provides, regardless of > the state of the GUI 'IPv4/IPv6 On/Off' settings? Hi Anders, I would expect, that if the connection has IPvX disabled, that NM doesn't configure any IPvX addresses, regardless of what it received from the server. If that is different, it sounds like a bug. The logic for that is entirely in the server (NMVpnConnection). The plugin collets the data from the environment and sends it back to the server. There, NMVpnConnection merges the event data with other configuration (from NMConnection). Not sure I understand your question though... 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: OpenVPN and avoiding default route
On 2016-11-28 18:13, Anders Blomdell wrote:
>
>
> On 2016-11-28 14:21, Anders Blomdell wrote:
>>
>>
>> On 2016-11-25 18:42, Thomas Haller wrote:
>>> On Fri, 2016-11-25 at 17:08 +0100, Anders Blomdell wrote:
>>>> Would it make sense to let the OpenVPN server disable default-routing
>>>> in network manager, for instance
>>>> by checking if a 'push "route-gateway x.y.z.w"' has been done from
>>>> the server?
>>>>
>>>> I mean something like this, (nm-openvpn-service-openvpn-helper.c):
>>>>
>>>> /* Internal VPN subnet gateway */
>>>>tmp = getenv ("route_vpn_gateway");
>>>>if (tmp == NULL) {
>>>>val = g_variant_new_boolean (TRUE);
>>>>g_variant_builder_add (&ip4builder, "{sv}",
>>>> NM_VPN_PLUGIN_IP4_CONFIG_NEVER_DEFAULT, val);
>>>>}
>>>
>>> Hi,
>>>
>>> This sounds like RFE https://bugzilla.gnome.org/show_bug.cgi?id=762911
>> Indeed it does, further investigation indicates that openvpn has to be
>> modified
>> to propagate redirect-gateway/redirect-private to the up-script. Will try to
>> look
>> into this and add my findings to the RFE.
> First attempt of OpenVPN pull request in the RFE.
> NetworkManager should probably be modified to parse
> "redirect-gateway/redirect-private"
> while importing .ovpn files, pointer to the code that does this would be
> appreciated.
I have started to look into the config parsing and settings handling, is it an
intended
behavior that NetworkManager brings up the IPv6/IPv4 that OpenVPN provides,
regardless of
the state of the GUI 'IPv4/IPv6 On/Off' settings?
/Anders
--
Anders Blomdell Email: anders.blomd...@control.lth.se
Department of Automatic Control
Lund University Phone:+46 46 222 4625
P.O. Box 118 Fax: +46 46 138118
SE-221 00 Lund, Sweden
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: OpenVPN and avoiding default route
On 2016-11-28 14:21, Anders Blomdell wrote:
>
>
> On 2016-11-25 18:42, Thomas Haller wrote:
>> On Fri, 2016-11-25 at 17:08 +0100, Anders Blomdell wrote:
>>> Would it make sense to let the OpenVPN server disable default-routing
>>> in network manager, for instance
>>> by checking if a 'push "route-gateway x.y.z.w"' has been done from
>>> the server?
>>>
>>> I mean something like this, (nm-openvpn-service-openvpn-helper.c):
>>>
>>> /* Internal VPN subnet gateway */
>>> tmp = getenv ("route_vpn_gateway");
>>> if (tmp == NULL) {
>>> val = g_variant_new_boolean (TRUE);
>>> g_variant_builder_add (&ip4builder, "{sv}",
>>> NM_VPN_PLUGIN_IP4_CONFIG_NEVER_DEFAULT, val);
>>> }
>>
>> Hi,
>>
>> This sounds like RFE https://bugzilla.gnome.org/show_bug.cgi?id=762911
> Indeed it does, further investigation indicates that openvpn has to be
> modified
> to propagate redirect-gateway/redirect-private to the up-script. Will try to
> look
> into this and add my findings to the RFE.
First attempt of OpenVPN pull request in the RFE.
NetworkManager should probably be modified to parse
"redirect-gateway/redirect-private"
while importing .ovpn files, pointer to the code that does this would be
appreciated.
/Anders
--
Anders Blomdell Email: anders.blomd...@control.lth.se
Department of Automatic Control
Lund University Phone:+46 46 222 4625
P.O. Box 118 Fax: +46 46 138118
SE-221 00 Lund, Sweden
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: OpenVPN and avoiding default route
On 2016-11-25 18:42, Thomas Haller wrote:
> On Fri, 2016-11-25 at 17:08 +0100, Anders Blomdell wrote:
>> Would it make sense to let the OpenVPN server disable default-routing
>> in network manager, for instance
>> by checking if a 'push "route-gateway x.y.z.w"' has been done from
>> the server?
>>
>> I mean something like this, (nm-openvpn-service-openvpn-helper.c):
>>
>> /* Internal VPN subnet gateway */
>> tmp = getenv ("route_vpn_gateway");
>> if (tmp == NULL) {
>> val = g_variant_new_boolean (TRUE);
>> g_variant_builder_add (&ip4builder, "{sv}",
>> NM_VPN_PLUGIN_IP4_CONFIG_NEVER_DEFAULT, val);
>> }
>
> Hi,
>
> This sounds like RFE https://bugzilla.gnome.org/show_bug.cgi?id=762911
Indeed it does, further investigation indicates that openvpn has to be modified
to propagate redirect-gateway/redirect-private to the up-script. Will try to
look
into this and add my findings to the RFE.
/Anders
--
Anders Blomdell Email: anders.blomd...@control.lth.se
Department of Automatic Control
Lund University Phone:+46 46 222 4625
P.O. Box 118 Fax: +46 46 138118
SE-221 00 Lund, Sweden
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM 1.2.4: Problem with OpenVPN DNS lookups after Ubuntu 16.10 upgrade
On Fri, 2016-11-25 at 16:44 -0500, Paul Smith wrote: > Can anyone tell me how to investigate / debug this issue? My > /etc/resolv.conf has: > > # Dynamic resolv.conf(5) file for glibc resolver(3) generated by > resolvconf(8) > # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE > OVERWRITTEN > nameserver 127.0.1.1 Hi, /etc/resolv.conf is written by resolvconf, but with input provided by NetworkManager. Probably, your /etc/NetworkManager/NetworkManager.conf has something like [main] dns=dnsmasq rc-manager=resolvconf (possibly in some configuration snippets in /var/lib/NetworkManager/conf.d or /etc/NetworkManager/conf.d). this might be a fine configuration, and it leaves you with several options how to tweak the configuration. > gone > are the days where the DNS servers simply sat in /etc/resolv.conf, or > else in simple DHCP lease files. If you just dislike the caching DNS server (nameserver 127.0.0.1), then disable it. Configure "main.dns=default" in NetworkManager.conf followed by `killall -SIGHUP NetworkManager`. If you don't like to use resolvconf, change "rc-manager" setting to something else, like "symlink". See `man NetworkManager.conf`. DNS configuration was never done via DHCP lease files. But if you want to see the DHCP options, try $ nmcli -f all device show $DEVICE If you continue to use dns=dnsmasq (which sounds sensible), then you can: 1) put dnsmasq configuration snippets to /etc/NetworkManager/dnsmasq.d 2) add some per-connection DNS configuration according to your needs. 3) overwrite all per-connection configuration via global configuration in NetworkManager.conf (see GLOBAL-DNS and GLOBAL-DNS-DOMAIN in `man NetworkManager.conf` Sounds like 2) would be best, see the ipv4.dns* per-connection settings, for example `nmcli connection show $NAME | grep ipv..dns`. > so clearly something is taking over DNS. I expect it's this dnsmasq: > > /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts \ > --bind-interfaces --pid- > file=/var/run/NetworkManager/dnsmasq.pid \ > --listen-address=127.0.1.1 --cache-size=0 --conf-file=/dev/null > \ > --proxy-dnssec --enable- > dbus=org.freedesktop.NetworkManager.dnsmasq \ > --conf-dir=/etc/NetworkManager/dnsmasq.d > > but I've looked in those directories and I can't find anything that > looks like it might be a DHCP lease file or whatever that might tell > the > system what DNS servers to use (in fact /etc/NetworkManager/dnsmasq.d > is > empty) this dnsmasq instance is spawned by NetworkManager and configured via D-Bus. You can however extend the configuration by putting files to /etc/NetworkManager/dnsmasq.d. If you want to see the DNS configuration done by NetworkManager, enable debug logging: `sudo nmcli general logging level TRACE` and look at the logfiles. You can force NM to rewrite your DNS configuration via SIGHUP signal (killall). best, 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
NM 1.2.4: Problem with OpenVPN DNS lookups after Ubuntu 16.10 upgrade
Hi all. I recently upgraded to Ubuntu 16.10 and have been having intermittent issues with DNS lookups ever since. Unfortunately the infrastructure on my system has surpassed my ability to debug it: gone are the days where the DNS servers simply sat in /etc/resolv.conf, or else in simple DHCP lease files. My system is a desktop system, on a LAN, but I use openvpn to connect to work and I also have kvm/qemu installed for running virtual machines, which does its own playing with resolv.conf and its own dnsmasq in order to enable virtual LAN facilities. network-manager 1.2.4-0ubuntu1 network-manager-gnome 1.2.4-0ubuntu2 network-manager-openvpn 1.2.6-2ubuntu1 network-manager-openvpn-gnome 1.2.6-2ubuntu1 network-manager-pptp 1.2.2-1 network-manager-pptp-gnome1.2.2-1 I've configured my system to use Google DNS servers by default and normal access to the internet works fine. The problem is that when I start my VPN, I can't look up any hosts on that network's internal LAN. The local DNS servers are not getting queried. The VPN is working fine: if I edit my /etc/hosts with hostnames I'm interested in then I can reach them just fine. My IPv4 settings for the VPN are all automatic DHCP, DNS, Routes, and I do check the "Use this connection only for resources on its network". When I first upgraded to Ubuntu 16.10 and rebooted I had this problem, but then I rebooted again and it went away so I figured it was an upgrade glitch. But now it's back and I'd like to get to the bottom of it. Can anyone tell me how to investigate / debug this issue? My /etc/resolv.conf has: # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 127.0.1.1 so clearly something is taking over DNS. I expect it's this dnsmasq: /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts \ --bind-interfaces --pid-file=/var/run/NetworkManager/dnsmasq.pid \ --listen-address=127.0.1.1 --cache-size=0 --conf-file=/dev/null \ --proxy-dnssec --enable-dbus=org.freedesktop.NetworkManager.dnsmasq \ --conf-dir=/etc/NetworkManager/dnsmasq.d but I've looked in those directories and I can't find anything that looks like it might be a DHCP lease file or whatever that might tell the system what DNS servers to use (in fact /etc/NetworkManager/dnsmasq.d is empty) Help! ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: OpenVPN and avoiding default route
On Fri, 2016-11-25 at 17:08 +0100, Anders Blomdell wrote:
> Would it make sense to let the OpenVPN server disable default-routing
> in network manager, for instance
> by checking if a 'push "route-gateway x.y.z.w"' has been done from
> the server?
>
> I mena smething like this, (nm-openvpn-service-openvpn-helper.c):
>
> /* Internal VPN subnet gateway */
> tmp = getenv ("route_vpn_gateway");
> if (tmp == NULL) {
> val = g_variant_new_boolean (TRUE);
> g_variant_builder_add (&ip4builder, "{sv}",
> NM_VPN_PLUGIN_IP4_CONFIG_NEVER_DEFAULT, val);
> }
Hi,
This sounds like RFE https://bugzilla.gnome.org/show_bug.cgi?id=762911
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
OpenVPN and avoiding default route
Would it make sense to let the OpenVPN server disable default-routing in
network manager, for instance
by checking if a 'push "route-gateway x.y.z.w"' has been done from the server?
I mena smething like this, (nm-openvpn-service-openvpn-helper.c):
/* Internal VPN subnet gateway */
tmp = getenv ("route_vpn_gateway");
if (tmp == NULL) {
val = g_variant_new_boolean (TRUE);
g_variant_builder_add (&ip4builder, "{sv}",
NM_VPN_PLUGIN_IP4_CONFIG_NEVER_DEFAULT, val);
}
/Anders
--
Anders Blomdell Email: anders.blomd...@control.lth.se
Department of Automatic Control
Lund University Phone:+46 46 222 4625
P.O. Box 118 Fax: +46 46 138118
SE-221 00 Lund, Sweden
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: How to avoid using policy kit with openvpn
On Fri, 2016-11-25 at 15:20 +0200, matti kaasinen wrote: > > 2016-11-24 16:03 GMT+02:00 matti kaasinen : > > > To be more exact: service that dos not start anymore after I enable and > > later disable it is avahi-daemon.service. It is told in that unit file that: > > Alias=dbus-org.freedesktop.Avahi.service. > > > > > In fact, it seems that any operations using dbus (NTP, avahi...) have > problems after starting openvpn service and it does not vanish if I stop > it. So, it seems that either openvpn sevice (or possibly NM) creates policy > some policy kit rule that does not vanish when I disable and stop openvpn. That sounds very strange. Please enable eavesdropping on the system bus: https://wiki.ubuntu.com/DebuggingDBus#How_to_monitor_the_system_bus And then monitor the actual bus traffic before starting the "openvpn service" (is that the NM VPN plugin?) and after starting it and look out for what changed. You can use "busctl monitor" or "dbus-monitor --system" to do the monitoring. Be sure to disable eavesdropping afterwards. If it won't be obvious what went wrong then please share the logs (preferably via a pastebin and after making sure you're not leaking your passwords). Regards, Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: How to avoid using policy kit with openvpn
2016-11-24 16:03 GMT+02:00 matti kaasinen : > To be more exact: service that dos not start anymore after I enable and > later disable it is avahi-daemon.service. It is told in that unit file that: > Alias=dbus-org.freedesktop.Avahi.service. > In fact, it seems that any operations using dbus (NTP, avahi...) have problems after starting openvpn service and it does not vanish if I stop it. So, it seems that either openvpn sevice (or possibly NM) creates policy some policy kit rule that does not vanish when I disable and stop openvpn. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: How to avoid using policy kit with openvpn
2016-11-23 19:31 GMT+02:00 matti kaasinen : > BTW, I got a feeling that I got more services failed after I enabled > openvpn.service (like avahi). Also these problems did not disappear when I > disabled openvpn.service and booted card. Same goes with modem problems. > So, does NetworkManager or somebody else keep some data regarding OpenVPN > set-up even though its been disabled. If so, would it be better managing > OpenVPN connection with NetworkManager (-plugin) than using openvpn.service > for that. Also is openvpn-plugin build automatically and get into use if > tun interface is not configured as unmanaged? To be more exact: service that dos not start anymore after I enable and later disable it is avahi-daemon.service. It is told in that unit file that: Alias=dbus-org.freedesktop.Avahi.service. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: How to avoid using policy kit with openvpn
2016-11-23 19:31 GMT+02:00 matti kaasinen : > 2016-11-23 18:13 GMT+02:00 Dan Williams : > >> If these are single-user systems, you can rebuild NM with PolicyKit >> disabled so that it never validates requests against PolicyKit. >> > I'll try rebuilding tomorrow. I suppose (hope) there is clear switch for > disabling it. > I thought I found the configuration switch. I ran build using: --enable-polkit=disabled set-up. >From configuration log I can see: following note NOTE: Running ../NetworkManager-1.0.10/configure --build=x86_64-linux --host=arm-poky-linux-gnueabi --target=arm-poky-linux-gnueabi --prefix=/usr --exec_prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/libexec --datadir=/usr/share --sysconfdir=/etc --sharedstatedir=/com --localstatedir=/var --libdir=/usr/lib --includedir=/usr/include --oldincludedir=/usr/include --infodir=/usr/share/info --mandir=/usr/share/man --disable-silent-rules --disable-dependency-tracking --with-libtool-sysroot=/CPR3/sysroots/am335x-evm --enable-introspection --disable-ifcfg-rh --disable-ifnet --disable-ifcfg-suse --disable-more-warnings --with-iptables=/usr/sbin/iptables --with-tests --with-nmtui=yes --disable-static --enable-nls --enable-polkit=disabled--disable-bluez5-dun --with-libsoup=no --with-dhclient=/sbin/dhclient --with-dnsmasq=/usr/bin/dnsmasq --enable-ifupdown --with-modem-manager-1=yes --with-netconfig=yes --with-crypto=nss --disable-ppp --disable-qt --with-systemdsystemunitdir=/lib/systemd/system --with-session-tracking=systemd --enable-polkit --enable-wifi=no But later on there is also checking for POLKIT... yes and als Platform: session tracking: systemd suspend/resume: systemd policykit: yes (restrictive modify.system) (default=yes) polkit agent: yes selinux: no Also I got similar error message when trying to access SIM. >> > Could you 'nmcli g log level debug' on a problem machine and grab some >> log output from before and after the error? >> > I don't have access to that machine now, but I'll do that tomorrow. > Please find the NetworkManager journal with above nmcli executed before (would attachment be better?) Read config: /etc/NetworkManager/NetworkManager.conf Loaded settings plugin keyfile: (c) 2007 - 2015 Red Hat, Inc. To report bugs please use the NetworkManager mailing list. keyfile: new connection /etc/NetworkManager/system-connections/eth0 (5769be4a-ee83-4674-890a-f19e96b6c31e,"eth0") monitoring kernel firmware directory '/lib/firmware'. Loaded device plugin: NMVxlanFactory (internal) Loaded device plugin: NMVlanFactory (internal) Loaded device plugin: NMVethFactory (internal) Loaded device plugin: NMTunFactory (internal) Loaded device plugin: NMMacvlanFactory (internal) Loaded device plugin: NMInfinibandFactory (internal) Loaded device plugin: NMGreFactory (internal) Loaded device plugin: NMEthernetFactory (internal) Loaded device plugin: NMBridgeFactory (internal) Loaded device plugin: NMBondFactory (internal) Loaded device plugin: NMWwanFactory (/usr/lib/NetworkManager/libnm-device-plugin-wwan.so) Loaded device plugin: NMBluezManager (/usr/lib/NetworkManager/libnm-device-plugin-bluetooth.so) WiFi enabled by radio killswitch; enabled by state file WWAN enabled by radio killswitch; enabled by state file WiMAX enabled by radio killswitch; enabled by state file Networking is enabled by state file (lo): link connected (lo): new Generic device (carrier: ON, driver: 'unknown', ifindex: 1) (eth0): new Ethernet device (carrier: OFF, driver: 'cpsw', ifindex: 2) (eth0): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2] ModemManager available in the bus (eth0): link connected (eth0): device state change: unavailable -> disconnected (reason 'carrier-changed') [20 30 40] Auto-activating connection 'eth0'. (eth0): Activation: starting connection 'eth0' (5769be4a-ee83-4674-890a-f19e96b6c31e) (eth0): device state change: disconnected -> prepare (reason 'none') [30 40 0] NetworkManager state is now CONNECTING (eth0): device state change: prepare -> config (reason 'none') [40 50 0] (eth0): device state change: config -> ip-config (reason 'none') [50 70 0] Activation (eth0) Beginning DHCPv4 transaction (timeout in 45 seconds) address 192.168.3.1 plen 22 expires in 600 seconds gateway 192.168.1.2 nameserver '192.168.1.2' domain name 'sitecno.fi' (eth0): DHCPv4 state changed unknown -> bound (eth0): device state change: ip-config -> ip-check (reason 'none') [70 80 0] (eth0): device state change: ip-check -> secondaries (reason 'none') [80 90 0] (eth0): device state change: secondaries -> activated (reason 'none') [90 100 0] NetworkManager state is now CONNECTED_LOCAL NetworkManager state is now CONNECTED_GLOBAL Policy set 'eth0' (eth0) as default for IPv4 routing a
Re: How to avoid using policy kit with openvpn
2016-11-23 18:13 GMT+02:00 Dan Williams : > If these are single-user systems, you can rebuild NM with PolicyKit > disabled so that it never validates requests against PolicyKit. > I'll try rebuilding tomorrow. I suppose (hope) there is clear switch for disabling it. > > Could you 'nmcli g log level debug' on a problem machine and grab some > log output from before and after the error? > I don't have access to that machine now, but I'll do that tomorrow. BTW, I got a feeling that I got more services failed after I enabled openvpn.service (like avahi). Also these problems did not disappear when I disabled openvpn.service and booted card. Same goes with modem problems. So, does NetworkManager or somebody else keep some data regarding OpenVPN set-up even though its been disabled. If so, would it be better managing OpenVPN connection with NetworkManager (-plugin) than using openvpn.service for that. Also is openvpn-plugin build automatically and get into use if tun interface is not configured as unmanaged? -Matti ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: How to avoid using policy kit with openvpn
On Wed, 2016-11-23 at 17:25 +0200, matti kaasinen wrote: > Version information: > OpenVPN: 2.3.8 > NetworkManager: 1.0.10 > ModemManager 1.4.12 > Dbus-daemon:1.10.6 If these are single-user systems, you can rebuild NM with PolicyKit disabled so that it never validates requests against PolicyKit. Could you 'nmcli g log level debug' on a problem machine and grab some log output from before and after the error? Dan > > 2016-11-23 16:37 GMT+02:00 matti kaasinen : > > > > > Hi! > > > > I do have kind of manager of NetworkManager who amongst of other > > things > > tries to connect modem automatically because my devices are > > embedded cards > > located somewhere in nowhere. These cards communicate to server > > through > > OpenVpn tunnel. This modem connection process worked quite well > > untill I > > tried using it with OpenVpn. It seems that I can't use > > AddAndActivateConnection method anymore (python api) as I do get > > now "Got > > "PolicyKit authorization failed" error message at the point where I > > try to > > access PIN. This does not happen if OpenVpn is not activated. I > > tried to > > use following option in NetworkManager.conf file: > > > > [keyfile] > > unmanaged-devices=interface-name:tun* > > > > Any suggestions appreciated! > > > > Thanks, > > Matti > > > > > ___ > 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: How to avoid using policy kit with openvpn
Version information: OpenVPN: 2.3.8 NetworkManager: 1.0.10 ModemManager 1.4.12 Dbus-daemon:1.10.6 2016-11-23 16:37 GMT+02:00 matti kaasinen : > Hi! > > I do have kind of manager of NetworkManager who amongst of other things > tries to connect modem automatically because my devices are embedded cards > located somewhere in nowhere. These cards communicate to server through > OpenVpn tunnel. This modem connection process worked quite well untill I > tried using it with OpenVpn. It seems that I can't use > AddAndActivateConnection method anymore (python api) as I do get now "Got > "PolicyKit authorization failed" error message at the point where I try to > access PIN. This does not happen if OpenVpn is not activated. I tried to > use following option in NetworkManager.conf file: > > [keyfile] > unmanaged-devices=interface-name:tun* > > Any suggestions appreciated! > > Thanks, > Matti > > ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
How to avoid using policy kit with openvpn
Hi! I do have kind of manager of NetworkManager who amongst of other things tries to connect modem automatically because my devices are embedded cards located somewhere in nowhere. These cards communicate to server through OpenVpn tunnel. This modem connection process worked quite well untill I tried using it with OpenVpn. It seems that I can't use AddAndActivateConnection method anymore (python api) as I do get now "Got "PolicyKit authorization failed" error message at the point where I try to access PIN. This does not happen if OpenVpn is not activated. I tried to use following option in NetworkManager.conf file: [keyfile] unmanaged-devices=interface-name:tun* Any suggestions appreciated! Thanks, Matti ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
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
[network-manager-openvpn] Problem adding vpn file from my provider FrootVPN.
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: "" Attachment screenshot and ovpn file. Thanks for your attention. client dev tun resolv-retry infinite nobind persist-key persist-tun auth-user-pass ns-cert-type server cipher AES-256-CBC auth SHA384 server-poll-timeout 3 -BEGIN CERTIFICATE- MIIEwTCCA6mgAwIBAgIJANtGjxbsxYjTMA0GCSqGSIb3DQEBBQUAMIGbMQswCQYD VQQGEwJTRTELMAkGA1UECBMCUVExEjAQBgNVBAcTCUZyb290VG93bjERMA8GA1UE ChMIRnJvb3RPcmcxETAPBgNVBAsTCGNoYW5nZW1lMREwDwYDVQQDEwhjaGFuZ2Vt ZTERMA8GA1UEKRMIY2hhbmdlbWUxHzAdBgkqhkiG9w0BCQEWEG1haWxAaG9zdC5k b21haW4wHhcNMTQwNTA5MjEwMjIxWhcNMjQwNTA2MjEwMjIxWjCBmzELMAkGA1UE BhMCU0UxCzAJBgNVBAgTAlFRMRIwEAYDVQQHEwlGcm9vdFRvd24xETAPBgNVBAoT CEZyb290T3JnMREwDwYDVQQLEwhjaGFuZ2VtZTERMA8GA1UEAxMIY2hhbmdlbWUx ETAPBgNVBCkTCGNoYW5nZW1lMR8wHQYJKoZIhvcNAQkBFhBtYWlsQGhvc3QuZG9t YWluMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvjn066eoAeLZdypK u2parz/ZLyoiTvzR9zfysLn3gLRp9DZjLmdWw5CSdJHou9n2mS/Mgtk76VgwrwKu I8lg6fAdvGBLZ3CaTUz4qpsCIBoJtfZGO4ipSFK1SEytFX1TvD9GgMAJIqk4ixxF +wyGahmB01BvVewdYBvUyHwFgPELiPqrNZ0rrx2WyFNHqlqeBWcTxjG3rWL4wG9W rK5d2QWymlU4309XYTuVuT001eM1zbSjkmLKhFfvBOWP5XmopBBPy3Q5rqzGJCO4 qrgIvtxYBidgPDSI4AXZQevFzMCs5zZqVQkkQOZ/3IKN4Odji4wNf7Ncg30ZpYCv kSPSgwIDAQABo4IBBDCCAQAwHQYDVR0OBBYEFJnNEWNacY+/pBIcRkrKn9jBiSFr MIHQBgNVHSMEgcgwgcWAFJnNEWNacY+/pBIcRkrKn9jBiSFroYGhpIGeMIGbMQsw CQYDVQQGEwJTRTELMAkGA1UECBMCUVExEjAQBgNVBAcTCUZyb290VG93bjERMA8G A1UEChMIRnJvb3RPcmcxETAPBgNVBAsTCGNoYW5nZW1lMREwDwYDVQQDEwhjaGFu Z2VtZTERMA8GA1UEKRMIY2hhbmdlbWUxHzAdBgkqhkiG9w0BCQEWEG1haWxAaG9z dC5kb21haW6CCQDbRo8W7MWI0zAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBBQUA A4IBAQA/cd7eXInNxSoZMZNLmwP54defRQDclqpRVigUdZppoY/FSq6zCOMjn386 RYhk3wmkl5Retw9wIUNYNmB+3TikBeT5eMCGws/pxGIPELPcYDmVE9hete5EIRX/ 1seLzzcLSjg/M+9DOt8tvUPcY8U+JIWU5PICYFQUU7K3BcNICVWIlsus3ilqkbqe vBHDrs5Z6FQEm1EEYYCtiM3NeZ/GhfgIfVh2x8Tylgsck6s/DKHGi6lAycKMBo1C yuZl5Gl/pQK76QzxO/p6hzLLRdYec8WQRX4DxpvpNAnLkpryt7XmxzSg8XPTqyN4 r5CdYXeKObGdzsQNY3AxLKsnNuPG -END CERTIFICATE- -BEGIN CERTIFICATE- MIIFBTCCA+2gAwIBAgIBAjANBgkqhkiG9w0BAQUFADCBmzELMAkGA1UEBhMCU0Ux CzAJBgNVBAgTAlFRMRIwEAYDVQQHEwlGcm9vdFRvd24xETAPBgNVBAoTCEZyb290 T3JnMREwDwYDVQQLEwhjaGFuZ2VtZTERMA8GA1UEAxMIY2hhbmdlbWUxETAPBgNV BCkTCGNoYW5nZW1lMR8wHQYJKoZIhvcNAQkBFhBtYWlsQGhvc3QuZG9tYWluMB4X DTE0MDYxNDE3NTMwNloXDTI0MDYxMTE3NTMwNlowgZkxCzAJBgNVBAYTAlNFMQsw CQYDVQQIEwJRUTESMBAGA1UEBxMJRnJvb3RUb3duMREwDwYDVQQKEwhGcm9vdE9y ZzERMA8GA1UECxMIY2hhbmdlbWUxDzANBgNVBAMTBmNsaWVudDERMA8GA1UEKRMI Y2hhbmdlbWUxHzAdBgkqhkiG9w0BCQEWEG1haWxAaG9zdC5kb21haW4wggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDftRDk9EbrSEH2gAuSeBUiQXHECZ/K flM1tWRo4DMwNsXuMM5WnqPln38svypE9a5BKGO8ZEsM5LAfOik5yPYcLGilslYs bowcRsnnrhOkPp2AJDrZzcJCXjdQsCDpapErCzyon58T6Vuc27TW369cUTk40Hz3 uBOkYNMmYqhePu3EwKXzMjy8o0qaFlO+8Y6qNEPv8AGhljIwo0Q70xQjDrNxwSBM vKnYOvjtvH0HlgXYWTQ7Y8/hy8wUnJZg3UX/+7TC2ks+sj3wSDB4CyU+v9lauChq frdJR2ziXXi/b/CNNfDuuqAWya70/ABdsfG0E583jPxh7VuwnrYrbm51AgMBAAGj ggFSMIIBTjAJBgNVHRMEAjAAMC0GCWCGSAGG+EIBDQQgFh5FYXN5LVJTQSBHZW5l cmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFMpYLs4OTz/0wAm7TB1wwZAOkmDg MIHQBgNVHSMEgcgwgcWAFJnNEWNacY+/pBIcRkrKn9jBiSFroYGhpIGeMIGbMQsw CQYDVQQGEwJTRTELMAkGA1UECBMCUVExEjAQBgNVBAcTCUZyb290VG93bjERMA8G A1UEChMIRnJvb3RPcmcxETAPBgNVBAsTCGNoYW5nZW1lMREwDwYDVQQDEwhjaGFu Z2VtZTERMA8GA1UEKRMIY2hhbmdlbWUxHzAdBgkqhkiG9w0BCQEWEG1haWxAaG9z dC5kb21haW6CCQDbRo8W7MWI0zATBgNVHSUEDDAKBggrBgEFBQcDAjALBgNVHQ8E BAMCB4AwDQYJKoZIhvcNAQEFBQADggEBAITvsT/pdb8nPmMRnawoJcp7R9fGE1dE jtrF2w96V0kTAy5Jrkiss6ilJXz/56pSoM4vk5XIMhUPWOP2Q0Or+b3EMGuEDRWT 3FTxz5p+eTYDaGwA6mR54M3s4A7pXAB+zgHrbKIAY5EgYQ4kimh1ILDcZm4AJxHZ 6gsijNKVo7bfVqZxysvQgG0JYmj9fvrV449DKUhR7/fHalnHI1EqS8P/OLjqq8jb /XE8/LT7fj6UklBJ9yYOO0Co4kFlgZ4hYLm8k7ccj12vMcvR/sw9f9t66v64lPin pcrFLwaO6Nymr4oC8q57w5flTct1aNYuqmXLbZF7D7QpSu5p/HYECl8= -END CERTIFICATE- -BEGIN PRIVATE KEY- MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQDftRDk9EbrSEH2 gAuSeBUiQXHECZ/KflM1tWRo4DMwNsXuMM5WnqPln38svypE9a5BKGO8ZEsM5LAf Oik5yPYcLGilslYsbowcRsnnrhOkPp2AJDrZzcJCXjdQsCDpapErCzyon58T6Vuc 27TW369cUTk40Hz3uBOkYNMmYqhePu3EwKXzMjy8o0qaFlO+8Y6qNEPv8AGhljIw o0Q70xQjDrNxwSBMvKnYOvjtvH0HlgXYWTQ7Y8/hy8wUnJZg3UX/+7TC2ks+sj3w SDB4CyU+v9lauChqfrdJR2ziXXi/b/CNNfDuuqAWya70/ABdsfG0E583jPxh7Vuw nrYrbm51AgMBAAECggEADOgAWoUxVj+r9pG6mS+uYHSQILRBcMhK+q1FZruQmHaA gtZ0ARFT+VpzVtyMjr/x1raC0oqivdKvyo1rdXb/o+539x9L03JpSPRYj7I+Vdp6 8bqlXo19aKDQ5inTLERGrcoPLNdQsTBkZa9TRpZPIq9Y8ssseoo3L+OaKvvEJPO2 0nv9un2kfPU/JvN2taV6D/6atEmXDIMIXumTJCSCfU2hq513nZjEVccS691Oug87 siKi5NyqNloq6iinVLvhSGOQ+gt68iZ0G1McH2jnJIXnpRXM0UpjMAYtfRYUh6ow 4bOxHxcTf6UCt0rY1KwSfjS/hd7NFgqcuzwEM6yXfQKBgQD8v0NtnW2AUE32uvDd Et67Wg5p3w4cRZZ2wXQvsoyuotBS+deo8CN113bdYJel3CtqdxdTkY20j5Xmf2sq NkBE+lGMfSxLph40bqIUEQ4dp4EXsVOwz1XeNmGYAwQ2PRGZ+H3QrEjZOcrqKLTI uvy+MuV6vGWFdkdH6esenhr5ZwKBgQDilh+zzMWvc1M4o9xuROAh9ObE8t5I4bb0 g9aVZtX1zBE309lEx8CuUAXwbRpfpFgBDQHkfS38PhNqeC0OXbe/Qq3J6j6Nq5Ou Y00uceMyJk6FVeEwpJ/
Re: two dhcp-option (openvpn)
On Tue, 2016-07-19 at 16:46 +0200, Xen wrote: > A user reported having two dhcp-option in his config, either pushed > by > the server or local, I don't know yet. > > One of the dhcp-option was faulty, it was 10.8.0.1 but there was no > response from that server apparently. > > The order given was: > > public internet DNS > private VPN DNS > > In the log from NetworkManager only the second one shows up as being > added to DNSmasq via dbus. As a consequence, since the local > resolv.conf > points to 127.0.1.1, his names do not resolve. > > Using OpenVPN directly caused the connection to succeed as normal > with > two elements written to /etc/resolv.conf apparently. Using OpenVPN > through NetworkManager caused the above described behaviour. > > Is this correct behaviour, a bug, or a lacking feature? I'm trying > to > have him change his VPN config, but I cannot influence what > NetworkManager is going to do, myself. > > Version of NM is probably going to be around 1.2.0. Can you get debug information out of the nm-openvpn-service process for the attempt? We need to see what openvpn is sending to NM. You can do this by: killall -TERM nm-openvpn-service /path/to/nm-openvpn-service --debug --persist (path will be different depending on your distro, like /usr/libexec or /usr/lib or whatever LIBEXECDIR is defined as during the build) and then connect the VPN. A lot of information will be dumped to the terminal here, *INCLUDING PASSWORDS* so please strip those out before sending. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
two dhcp-option (openvpn)
A user reported having two dhcp-option in his config, either pushed by the server or local, I don't know yet. One of the dhcp-option was faulty, it was 10.8.0.1 but there was no response from that server apparently. The order given was: public internet DNS private VPN DNS In the log from NetworkManager only the second one shows up as being added to DNSmasq via dbus. As a consequence, since the local resolv.conf points to 127.0.1.1, his names do not resolve. Using OpenVPN directly caused the connection to succeed as normal with two elements written to /etc/resolv.conf apparently. Using OpenVPN through NetworkManager caused the above described behaviour. Is this correct behaviour, a bug, or a lacking feature? I'm trying to have him change his VPN config, but I cannot influence what NetworkManager is going to do, myself. Version of NM is probably going to be around 1.2.0. Regards. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: OpenVPN connection loses static route after SIGUSR1
On Mon, 2016-06-20 at 19:41 +0200, Samuel Casa wrote: > Hi! > I am using the NetworkManager 1.0.12 to configure a VPN connection as > a 'secondary'. > If I bring the connection manually down and up using nmcli, the > static > route pushed by the server is added successfully on the client [0]. > If I send a SIGUSR1 (forced server ping-restart trigger) to the > openvpn process, the static route pushed by the server is missing in > the clients route configuration [1]. > > The static route is pushed in both cases by the server, I can verify > this on client and on server side. > > Where do we lose this information? > What I can see is that the helper application > nm-openvpn-service-openvpn-helper is called with the arguments init > (up / down) and restart (SIGUSR1). > The route information should be in the process environment at this > time, but it seems to be missing. > > How to debug this in the best way? Hi, this sounds like an unknown issue to me. Try https://wiki.gnome.org/Projects/NetworkManager/Debugging#Debugging_NetworkManager-openvpn Maybe it's also helpful to replace the helper with a wrapper script. 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
OpenVPN connection loses static route after SIGUSR1
Hi! I am using the NetworkManager 1.0.12 to configure a VPN connection as a 'secondary'. If I bring the connection manually down and up using nmcli, the static route pushed by the server is added successfully on the client [0]. If I send a SIGUSR1 (forced server ping-restart trigger) to the openvpn process, the static route pushed by the server is missing in the clients route configuration [1]. The static route is pushed in both cases by the server, I can verify this on client and on server side. Where do we lose this information? What I can see is that the helper application nm-openvpn-service-openvpn-helper is called with the arguments init (up / down) and restart (SIGUSR1). The route information should be in the process environment at this time, but it seems to be missing. How to debug this in the best way? Samuel [0] IPv4 config after manual restart Jun 20 17:21:59 host NetworkManager[9885]: VPN connection 'VPN0' (IP Config Get) reply received. Jun 20 17:21:59 host NetworkManager[9885]: VPN connection 'VPN0' (IP4 Config Get) reply received. Jun 20 17:21:59 host NetworkManager[9885]: VPN Gateway: 192.168.10.14 Jun 20 17:21:59 host NetworkManager[9885]: Tunnel Device: tun0 Jun 20 17:21:59 host NetworkManager[9885]: IPv4 configuration: Jun 20 17:21:59 host NetworkManager[9885]: Internal Gateway: 10.42.0.69 Jun 20 17:21:59 host NetworkManager[9885]: Internal Address: 10.42.0.70 Jun 20 17:21:59 host NetworkManager[9885]: Internal Prefix: 32 Jun 20 17:21:59 host NetworkManager[9885]: Internal Point-to-Point Address: 10.42.0.69 Jun 20 17:21:59 host NetworkManager[9885]: Maximum Segment Size (MSS): 0 Jun 20 17:21:59 host NetworkManager[9885]: Static Route: 10.42.0.1/32 Next Hop: 10.42.0.69 Jun 20 17:21:59 host NetworkManager[9885]: Forbid Default Route: yes Jun 20 17:21:59 host NetworkManager[9885]: DNS Domain: '(none)' [1] IPv4 config after SIGUSR1 forced restart Mon Jun 20 17:11:17 2016 us=21176 SIGUSR1[hard,] received, process restarting Mon Jun 20 17:11:23 2016 us=149248 PUSH: Received control message: 'PUSH_REPLY,route 10.42.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.42.0.70 10.42.0.69' Mon Jun 20 17:11:23 2016 us=152854 /usr/lib/networkmanager-openvpn/nm-openvpn-service-openvpn-helper --tun -- tun0 1500 1542 10.42.0.70 10.42.0.69 restart Jun 20 17:11:23 host NetworkManager[9885]: VPN connection 'VPN0' (IP Config Get) reply received. Jun 20 17:11:23 host NetworkManager[9885]: VPN connection 'VPN0' (IP4 Config Get) reply received. Jun 20 17:11:23 host NetworkManager[9885]: VPN Gateway: 192.168.10.14 Jun 20 17:11:23 host NetworkManager[9885]: Tunnel Device: tun0 Jun 20 17:11:23 host NetworkManager[9885]: IPv4 configuration: Jun 20 17:11:23 host NetworkManager[9885]: Internal Gateway: 10.42.0.69 Jun 20 17:11:23 host NetworkManager[9885]: Internal Address: 10.42.0.70 Jun 20 17:11:23 host NetworkManager[9885]: Internal Prefix: 32 Jun 20 17:11:23 host NetworkManager[9885]: Internal Point-to-Point Address: 10.42.0.69 Jun 20 17:11:23 host NetworkManager[9885]: Maximum Segment Size (MSS): 0 Jun 20 17:11:23 host NetworkManager[9885]: Forbid Default Route: yes Jun 20 17:11:23 host NetworkManager[9885]: DNS Domain: '(none)' ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: openvpn cmdline communication to NM
On Tue, Jun 14, 2016 at 10:57 AM, Thomas Haller wrote: > It would need a more elaborate scheme to report warnings back to the > calling application. I can report that, as an end-user, NM is a complete mystery when anything doesn't work. So +1000 votes for some feedback facility :-) VPNs are specially hard to debug, but pretty much any problem is a dog to diagnose. I have experience with NM diagnosis (from my OLPC years, where we ran a patched NM, mesh networking, all sorts of fun stuff), and I get stumped like a newbie. I say this with lots of love and affection for NM and dev team. There's been huge progress and many things Just Work; and that's amazing. cheers. m -- martin.langh...@gmail.com - ask interesting questions ~ http://linkedin.com/in/martinlanghoff - don't be distracted~ http://github.com/martin-langhoff by shiny stuff ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: openvpn cmdline communication to NM
On Tue, 2016-06-14 at 10:47 -0400, Martin Langhoff wrote: > On Tue, Jun 14, 2016 at 10:33 AM, Thomas Haller > wrote: > > > > Also, import silently ignores unknown values from the file. > > https://git.gnome.org/browse/network-manager-openvpn/tree/propertie > > s/import-export.c?id=96081a2c2e05f64d89433d150053291516bddd5e#n1409 > > Maybe that is a bug, but fixing it might mean that we fail to > > import a > > lot of connections that we imported previously (and which may > > actually > > work, as it is not clear that the ignored properties are > > essential). > Would logging or being verbose about the ignored values _break_ the > import? The import is done by a plugin (a shared library), usually as part of nm-connection-editor. A library should not just print messages to the stdout/stderr of the calling process. It would need a more elaborate scheme to report warnings back to the calling application. 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: openvpn cmdline communication to NM
On Tue, Jun 14, 2016 at 10:33 AM, Thomas Haller wrote: > Also, import silently ignores unknown values from the file. > https://git.gnome.org/browse/network-manager-openvpn/tree/properties/import-export.c?id=96081a2c2e05f64d89433d150053291516bddd5e#n1409 > Maybe that is a bug, but fixing it might mean that we fail to import a > lot of connections that we imported previously (and which may actually > work, as it is not clear that the ignored properties are essential). Would logging or being verbose about the ignored values _break_ the import? Perhaps it helps diagnosis... cheers, m -- martin.langh...@gmail.com - ask interesting questions ~ http://linkedin.com/in/martinlanghoff - don't be distracted~ http://github.com/martin-langhoff by shiny stuff ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: openvpn cmdline communication to NM
On Tue, 2016-06-14 at 08:22 -0400, Martin Langhoff wrote: > Hi Thomas, > > thanks for the explanation. It generally matches my understanding of > the world :-) > > The odd thing is: this is a vanilla client connection, all the > details > are in ovpn file, I am connecting to OpenVPN servers. Import works, > but the connection fails to connect. Debugging it is, um, nontrivial. > It clearly tries, but it hasn't imported some setting or secret > right. Also, import silently ignores unknown values from the file. https://git.gnome.org/browse/network-manager-openvpn/tree/properties/import-export.c?id=96081a2c2e05f64d89433d150053291516bddd5e#n1409 Maybe that is a bug, but fixing it might mean that we fail to import a lot of connections that we imported previously (and which may actually work, as it is not clear that the ignored properties are essential). > You are right, NM starts the libexec binary. > > I've tried to debug connections in the past, and the best I could do > was to replace /usr/libexec/nm-openvpn-server with a shell wrapper > that logged the debug output. It is a pita if you're not an NM > developer. Another way to debug VPN plugins is https://wiki.gnome.org/Projects/NetworkManager/Debugging#Debugging_NetworkManager-openvpn With (not yet released) 1.4 you will also be able to enable debug logging of the plugin via nmcli general logging level KEEP domains VPN_PLUGIN:TRACE > Is there a way in which openvpn, called from the commandline, can > call > /usr/libexec/nm-openvpn-service-openvpn-helper ? :-) probably not, > and you'll tell me I'm misguided. if you pass --up /usr/libexec/nm-openvpn-service-openvpn-helper to openvpn, then it will act like as started by the plugin. But that wouldn't do you much good, because the helper tries to contact NetworkManager via D-Bus, which isn't expecting the request. From logging (above) or via `ps aux | grep openvpn` you can see the arguments passed to openvpn. You can then retrace what the plugin does and compare the result. 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: openvpn cmdline communication to NM
Hi Thomas, thanks for the explanation. It generally matches my understanding of the world :-) The odd thing is: this is a vanilla client connection, all the details are in ovpn file, I am connecting to OpenVPN servers. Import works, but the connection fails to connect. Debugging it is, um, nontrivial. It clearly tries, but it hasn't imported some setting or secret right. You are right, NM starts the libexec binary. I've tried to debug connections in the past, and the best I could do was to replace /usr/libexec/nm-openvpn-server with a shell wrapper that logged the debug output. It is a pita if you're not an NM developer. Is there a way in which openvpn, called from the commandline, can call /usr/libexec/nm-openvpn-service-openvpn-helper ? :-) probably not, and you'll tell me I'm misguided. :-} cheers, martin On Tue, Jun 14, 2016 at 5:20 AM, Thomas Haller wrote: > On Mon, 2016-06-13 at 12:46 -0400, Martin Langhoff wrote: >> Hi List! >> >> is there a practical way to get openvpn commandline to talk to NM to >> have NM update resolv.conf with the DNS settings coming from the VPN >> endpoint? >> >> I regularly find in the field openvpn setups which refuse to work >> well >> with NM's openvpn support. Sometimes I can file the relevant bugs, >> chase the whole thing down, etc. Sometimes I can't. I am not sure >> what >> complexities prevent a more straightforward import of ovpn files that >> 'just works', I can only bear witness that it has very rarely Just >> Worked for me. >> >> openvpn cli luckily always works. Is there a way to tell it to send >> the right dbus msg? >> >> thank you, > > Hi, > > when you use openvpn directly, you configure all it's options > explicitly, either via command line or .ovpn configration file. > > When you use nm-openvpn plugin, you create a "connection" (profile) via > one of the client tools (nm-connection-editor, nmcli) or via import > from ovpn file. In any case, this does not understand every option, > because some are not implemented and others don't make sense in the > context of NetworkManager (e.g. running as server). Also, NM wants to > configure IP addressing and DNS itself, it does not allow openvpn to do > that. > Then, nm-openvpn spawns openvpn with command line arguments based on > the connection. openvpn doesn't communitcate via D-Bus. It gets > executed by nm-openvpn-service with command line options, and it calls > back to NM via > --up /usr/libexec/nm-openvpn-service-openvpn-helper > > > If something doesn't work, then there is no other way then to open a bug > about it and fix it in nm-openvpn/NetworkManager. > > > That said, import of ovpn file is supposed to just work. What didn't work for > you there? > > > Thomas -- martin.langh...@gmail.com - ask interesting questions ~ http://linkedin.com/in/martinlanghoff - don't be distracted~ http://github.com/martin-langhoff by shiny stuff ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: openvpn cmdline communication to NM
On Mon, 2016-06-13 at 12:46 -0400, Martin Langhoff wrote: > Hi List! > > is there a practical way to get openvpn commandline to talk to NM to > have NM update resolv.conf with the DNS settings coming from the VPN > endpoint? > > I regularly find in the field openvpn setups which refuse to work > well > with NM's openvpn support. Sometimes I can file the relevant bugs, > chase the whole thing down, etc. Sometimes I can't. I am not sure > what > complexities prevent a more straightforward import of ovpn files that > 'just works', I can only bear witness that it has very rarely Just > Worked for me. > > openvpn cli luckily always works. Is there a way to tell it to send > the right dbus msg? > > thank you, Hi, when you use openvpn directly, you configure all it's options explicitly, either via command line or .ovpn configration file. When you use nm-openvpn plugin, you create a "connection" (profile) via one of the client tools (nm-connection-editor, nmcli) or via import from ovpn file. In any case, this does not understand every option, because some are not implemented and others don't make sense in the context of NetworkManager (e.g. running as server). Also, NM wants to configure IP addressing and DNS itself, it does not allow openvpn to do that. Then, nm-openvpn spawns openvpn with command line arguments based on the connection. openvpn doesn't communitcate via D-Bus. It gets executed by nm-openvpn-service with command line options, and it calls back to NM via --up /usr/libexec/nm-openvpn-service-openvpn-helper If something doesn't work, then there is no other way then to open a bug about it and fix it in nm-openvpn/NetworkManager. That said, import of ovpn file is supposed to just work. What didn't work for you there? 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
openvpn cmdline communication to NM
Hi List! is there a practical way to get openvpn commandline to talk to NM to have NM update resolv.conf with the DNS settings coming from the VPN endpoint? I regularly find in the field openvpn setups which refuse to work well with NM's openvpn support. Sometimes I can file the relevant bugs, chase the whole thing down, etc. Sometimes I can't. I am not sure what complexities prevent a more straightforward import of ovpn files that 'just works', I can only bear witness that it has very rarely Just Worked for me. openvpn cli luckily always works. Is there a way to tell it to send the right dbus msg? thank you, m -- martin.langh...@gmail.com - ask interesting questions ~ http://linkedin.com/in/martinlanghoff - don't be distracted~ http://github.com/martin-langhoff by shiny stuff ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Allow Single connection only via networkmanager-openvpn (reuse tun0?)
On Fri, 2016-04-15 at 15:24 +0200, Dave Conroy wrote: > You are right, a Pre Activaition would solve the issue. I spent the > past > 2 hours working with the pre-up and vpn-up statuses and found that > the > tun0 device wouldn't release properly as the openvpn binary is > launched > before the hook is triggered. > > Fun exercise though. However, all is not lost: > > /usr/lib/NetworkManager/VPN/nm-openvpn-service.name > > supports-multiple-connections=false *does* actually enforce a single > connection rule, forcing the user to disconnect from the VPN first > before launching another one. I can live with that. > > Out of curiousity I'm going to try giving latest gnome3 a spin and > see > if I can solve my (perceived) interface quirks. > > Thanks for your time, Which desktop environment are you using? Can you screenshot the place that you think the disconnect option should be showing up but isn't? There are a bunch of different UIs for NM, and only one is actually written by NM developers :) Know which UI would help us direct the bug report to the right place, or fix it ourselves if it's in nm-applet. Thanks! Dan > Dave > > > On 15/04/16 03:09 PM, Thomas Haller wrote: > > > > On Fri, 2016-04-15 at 13:13 +0200, Dave Conroy wrote: > > > > > > Hi Thomas, > > > That explains it, thank you very much - you are correct in what I > > > am > > > looking after. > > > There doesn't seem to be a working disconnect option in my > > > version of > > > NetworkManager (1.193). I will try different GTK themes to see if > > > it > > > is a problem with the theme itself. > > Certainly NetworkManager, its D-Bus API, and `nmcli connection > > disconnect` support disconnecting a VPN connection. If your UI > > doesn't > > allow for that, it's a UI limitation/decision. > > > > I don't think GTK themes help there. Are you using the gnome-shell > > (Gnome3) NetworkManager integration? I am not familiar with how > > that > > works there, maybe there is no disconnect button? That would be > > strange... > > > > > > > > Would there by chance be pre/post hooks that I could utilize to > > > execute before the connection is made? I could write up a script > > > that > > > disconnects any active connection this way. > > There are dispatcher scripts. First, ensure to have the dispatcher > > service running: > > `systemctl enable NetworkManager-dispatcher.service` > > Then place scripts to /etc/NetworkManager/dispatcher.d. > > > > See `man NetworkManager` for the events there. > > > > Note that the events `pre-up` and `pre-down` are special (because > > they > > block the device transition, we only want to call scripts there, > > which > > opt-in for those events. See the manual. > > > > > > Note, that `pre-up` might be a place to disconnect the other > > connection. The problem here is, that the (blocking) pre-up event > > is > > not emited ~before starting with activation~, but before ~declaring > > the > > device/VPN as fully up~ (but at that point, the VPN connection is > > already up for most of the part). > > So, if your VPN connections all want to use tun0, you cannot avoid > > that. > > > > > > > > I guess, it would be a nice feature to have such ~conflicting > > connection`. But well... > > > > An alternative feature would be a "pre-activation" dispatcher > > event... > > > > > > Thomas > > > > > > > > > > Thanks for the prompt response, > > > Dave > > > > > > On 15/04/16 12:15 PM, Thomas Haller wrote: > > > > > > > > Hi Dave, > > > > > > > > > > > > On Fri, 2016-04-15 at 06:04 +0200, Dave Conroy wrote: > > > > > > > > > > I've just subscribed to a VPN service that has multiple > > > > > locations, > > > > > and imported all the necessary .ovpn files into Network > > > > > Manager. > > > > > It seems that I do not have the option to disconnect from the > > > > > VPNs > > > > > when connected, and upon choosing another location it creates > > > > > another > > > > > tun device. > > > > You mean, you would like to have a configuration option in your > > > > VPN > > > > "connection", so that when activating another specific VPN > > > > co
Re: Allow Single connection only via networkmanager-openvpn (reuse tun0?)
You are right, a Pre Activaition would solve the issue. I spent the past 2 hours working with the pre-up and vpn-up statuses and found that the tun0 device wouldn't release properly as the openvpn binary is launched before the hook is triggered. Fun exercise though. However, all is not lost: /usr/lib/NetworkManager/VPN/nm-openvpn-service.name supports-multiple-connections=false *does* actually enforce a single connection rule, forcing the user to disconnect from the VPN first before launching another one. I can live with that. Out of curiousity I'm going to try giving latest gnome3 a spin and see if I can solve my (perceived) interface quirks. Thanks for your time, Dave On 15/04/16 03:09 PM, Thomas Haller wrote: > On Fri, 2016-04-15 at 13:13 +0200, Dave Conroy wrote: >> Hi Thomas, >> That explains it, thank you very much - you are correct in what I am >> looking after. >> There doesn't seem to be a working disconnect option in my version of >> NetworkManager (1.193). I will try different GTK themes to see if it >> is a problem with the theme itself. > Certainly NetworkManager, its D-Bus API, and `nmcli connection > disconnect` support disconnecting a VPN connection. If your UI doesn't > allow for that, it's a UI limitation/decision. > > I don't think GTK themes help there. Are you using the gnome-shell > (Gnome3) NetworkManager integration? I am not familiar with how that > works there, maybe there is no disconnect button? That would be > strange... > >> Would there by chance be pre/post hooks that I could utilize to >> execute before the connection is made? I could write up a script that >> disconnects any active connection this way. > There are dispatcher scripts. First, ensure to have the dispatcher > service running: > `systemctl enable NetworkManager-dispatcher.service` > Then place scripts to /etc/NetworkManager/dispatcher.d. > > See `man NetworkManager` for the events there. > > Note that the events `pre-up` and `pre-down` are special (because they > block the device transition, we only want to call scripts there, which > opt-in for those events. See the manual. > > > Note, that `pre-up` might be a place to disconnect the other > connection. The problem here is, that the (blocking) pre-up event is > not emited ~before starting with activation~, but before ~declaring the > device/VPN as fully up~ (but at that point, the VPN connection is > already up for most of the part). > So, if your VPN connections all want to use tun0, you cannot avoid > that. > > > > I guess, it would be a nice feature to have such ~conflicting > connection`. But well... > > An alternative feature would be a "pre-activation" dispatcher event... > > > Thomas > > >> Thanks for the prompt response, >> Dave >> >> On 15/04/16 12:15 PM, Thomas Haller wrote: >>> Hi Dave, >>> >>> >>> On Fri, 2016-04-15 at 06:04 +0200, Dave Conroy wrote: >>>> I've just subscribed to a VPN service that has multiple >>>> locations, >>>> and imported all the necessary .ovpn files into Network Manager. >>>> It seems that I do not have the option to disconnect from the >>>> VPNs >>>> when connected, and upon choosing another location it creates >>>> another >>>> tun device. >>> You mean, you would like to have a configuration option in your VPN >>> "connection", so that when activating another specific VPN >>> connection, >>> the former gets automatically disconnected? >>> >>> No, NetworkManager doesn't have a concept of ~conflicting~ >>> connections. >>> When you activate connection A, you'd have to manually disconnect >>> connection B. >>> >>> >>>> I've made the change to no success to >>>> /etc/NetworkManager/VPN/openvpn-service.name >>>> supports-multiple-connections=false >>>> Yet it still connects multiple locations without disconnecting >>>> the >>>> previous connection. >>> That shouldn't happen. Did you restart NM after changing the file? >>> But >>> I suspect the file /etc/NetworkManager/VPN/openvpn-service.name is >>> ignored and instead it uses /usr/lib/NetworkManager/VPN/openvpn- >>> service.name. The file in /etc only exists for backward >>> compatibility, >>> in 1.2, the location of this file moved to /usr/lib. >>> >>> Changing supports-multiple-connection=false actually should give >>> you >>> the conflicting behavior, but that doesn't sound like the right &g
Re: Allow Single connection only via networkmanager-openvpn (reuse tun0?)
On Fri, 2016-04-15 at 13:13 +0200, Dave Conroy wrote: > Hi Thomas, > That explains it, thank you very much - you are correct in what I am > looking after. > There doesn't seem to be a working disconnect option in my version of > NetworkManager (1.193). I will try different GTK themes to see if it > is a problem with the theme itself. Certainly NetworkManager, its D-Bus API, and `nmcli connection disconnect` support disconnecting a VPN connection. If your UI doesn't allow for that, it's a UI limitation/decision. I don't think GTK themes help there. Are you using the gnome-shell (Gnome3) NetworkManager integration? I am not familiar with how that works there, maybe there is no disconnect button? That would be strange... > Would there by chance be pre/post hooks that I could utilize to > execute before the connection is made? I could write up a script that > disconnects any active connection this way. There are dispatcher scripts. First, ensure to have the dispatcher service running: `systemctl enable NetworkManager-dispatcher.service` Then place scripts to /etc/NetworkManager/dispatcher.d. See `man NetworkManager` for the events there. Note that the events `pre-up` and `pre-down` are special (because they block the device transition, we only want to call scripts there, which opt-in for those events. See the manual. Note, that `pre-up` might be a place to disconnect the other connection. The problem here is, that the (blocking) pre-up event is not emited ~before starting with activation~, but before ~declaring the device/VPN as fully up~ (but at that point, the VPN connection is already up for most of the part). So, if your VPN connections all want to use tun0, you cannot avoid that. I guess, it would be a nice feature to have such ~conflicting connection`. But well... An alternative feature would be a "pre-activation" dispatcher event... Thomas > Thanks for the prompt response, > Dave > > On 15/04/16 12:15 PM, Thomas Haller wrote: > > Hi Dave, > > > > > > On Fri, 2016-04-15 at 06:04 +0200, Dave Conroy wrote: > > > I've just subscribed to a VPN service that has multiple > > > locations, > > > and imported all the necessary .ovpn files into Network Manager. > > > It seems that I do not have the option to disconnect from the > > > VPNs > > > when connected, and upon choosing another location it creates > > > another > > > tun device. > > You mean, you would like to have a configuration option in your VPN > > "connection", so that when activating another specific VPN > > connection, > > the former gets automatically disconnected? > > > > No, NetworkManager doesn't have a concept of ~conflicting~ > > connections. > > When you activate connection A, you'd have to manually disconnect > > connection B. > > > > > > > I've made the change to no success to > > > /etc/NetworkManager/VPN/openvpn-service.name > > > supports-multiple-connections=false > > > Yet it still connects multiple locations without disconnecting > > > the > > > previous connection. > > That shouldn't happen. Did you restart NM after changing the file? > > But > > I suspect the file /etc/NetworkManager/VPN/openvpn-service.name is > > ignored and instead it uses /usr/lib/NetworkManager/VPN/openvpn- > > service.name. The file in /etc only exists for backward > > compatibility, > > in 1.2, the location of this file moved to /usr/lib. > > > > Changing supports-multiple-connection=false actually should give > > you > > the conflicting behavior, but that doesn't sound like the right > > approach. First of all, openvpn-service.name is not user- > > configuration. > > This setting is here to tell NetworkManager that this plugin is new > > enough to support multiple activations of Openvpn connections > > (simultaneously). It's not here to implement ~conflicting > > connections~. > > > > Before 1.2, VPN plugins did not support to activate more then once > > at a > > time. Old plugins were always supports-multiple-connections=false. > > > > > > > Furthermore, I've set it to specifically use tun0 for my > > > connections > > > yet upon trying to load another connection even after "disabling" > > > the > > > VPN (I use Cinnamon Desktop) it says that it cannot access tun0 > > > as > > > the device is busy. I can disconnect via nmctl > > Yes, you can disconnect with nmcli. > > > > > but was wondering if there was a way that I could force > > > NetworkManaager to
Re: Allow Single connection only via networkmanager-openvpn (reuse tun0?)
Hi Thomas, That explains it, thank you very much - you are correct in what I am looking after. There doesn't seem to be a working disconnect option in my version of NetworkManager (1.193). I will try different GTK themes to see if it is a problem with the theme itself. Would there by chance be pre/post hooks that I could utilize to execute before the connection is made? I could write up a script that disconnects any active connection this way. Thanks for the prompt response, Dave On 15/04/16 12:15 PM, Thomas Haller wrote: > Hi Dave, > > > On Fri, 2016-04-15 at 06:04 +0200, Dave Conroy wrote: >> I've just subscribed to a VPN service that has multiple locations, >> and imported all the necessary .ovpn files into Network Manager. >> It seems that I do not have the option to disconnect from the VPNs >> when connected, and upon choosing another location it creates another >> tun device. > You mean, you would like to have a configuration option in your VPN > "connection", so that when activating another specific VPN connection, > the former gets automatically disconnected? > > No, NetworkManager doesn't have a concept of ~conflicting~ connections. > When you activate connection A, you'd have to manually disconnect > connection B. > > >> I've made the change to no success to >> /etc/NetworkManager/VPN/openvpn-service.name >> supports-multiple-connections=false >> Yet it still connects multiple locations without disconnecting the >> previous connection. > That shouldn't happen. Did you restart NM after changing the file? But > I suspect the file /etc/NetworkManager/VPN/openvpn-service.name is > ignored and instead it uses /usr/lib/NetworkManager/VPN/openvpn- > service.name. The file in /etc only exists for backward compatibility, > in 1.2, the location of this file moved to /usr/lib. > > Changing supports-multiple-connection=false actually should give you > the conflicting behavior, but that doesn't sound like the right > approach. First of all, openvpn-service.name is not user-configuration. > This setting is here to tell NetworkManager that this plugin is new > enough to support multiple activations of Openvpn connections > (simultaneously). It's not here to implement ~conflicting connections~. > > Before 1.2, VPN plugins did not support to activate more then once at a > time. Old plugins were always supports-multiple-connections=false. > > >> Furthermore, I've set it to specifically use tun0 for my connections >> yet upon trying to load another connection even after "disabling" the >> VPN (I use Cinnamon Desktop) it says that it cannot access tun0 as >> the device is busy. I can disconnect via nmctl > Yes, you can disconnect with nmcli. > >> but was wondering if there was a way that I could force >> NetworkManaager to only use one VPN connection at a time, releasing >> back tun0 to be used again. > No, such a concept doesn't exist (up to now). > > >> Error Code: >> ERROR: Cannot ioctl TUNSETIFF tun0: Device or resource busy >> (errno=16) > openvpn said that? Yes, that sounds expected, right? > > > > Thomas -- Dave Conroy (d...@tiredofit.ca) PGP: 0x45C0F342 Pedaling around the world away from a job in Information Technology Tired of I.T! http://www.tiredofit.ca The Book - Now available! http://www.tiredofit.ca/book/ ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Allow Single connection only via networkmanager-openvpn (reuse tun0?)
Hi Dave, On Fri, 2016-04-15 at 06:04 +0200, Dave Conroy wrote: > I've just subscribed to a VPN service that has multiple locations, > and imported all the necessary .ovpn files into Network Manager. > It seems that I do not have the option to disconnect from the VPNs > when connected, and upon choosing another location it creates another > tun device. You mean, you would like to have a configuration option in your VPN "connection", so that when activating another specific VPN connection, the former gets automatically disconnected? No, NetworkManager doesn't have a concept of ~conflicting~ connections. When you activate connection A, you'd have to manually disconnect connection B. > I've made the change to no success to > /etc/NetworkManager/VPN/openvpn-service.name > supports-multiple-connections=false > Yet it still connects multiple locations without disconnecting the > previous connection. That shouldn't happen. Did you restart NM after changing the file? But I suspect the file /etc/NetworkManager/VPN/openvpn-service.name is ignored and instead it uses /usr/lib/NetworkManager/VPN/openvpn- service.name. The file in /etc only exists for backward compatibility, in 1.2, the location of this file moved to /usr/lib. Changing supports-multiple-connection=false actually should give you the conflicting behavior, but that doesn't sound like the right approach. First of all, openvpn-service.name is not user-configuration. This setting is here to tell NetworkManager that this plugin is new enough to support multiple activations of Openvpn connections (simultaneously). It's not here to implement ~conflicting connections~. Before 1.2, VPN plugins did not support to activate more then once at a time. Old plugins were always supports-multiple-connections=false. > Furthermore, I've set it to specifically use tun0 for my connections > yet upon trying to load another connection even after "disabling" the > VPN (I use Cinnamon Desktop) it says that it cannot access tun0 as > the device is busy. I can disconnect via nmctl Yes, you can disconnect with nmcli. > but was wondering if there was a way that I could force > NetworkManaager to only use one VPN connection at a time, releasing > back tun0 to be used again. No, such a concept doesn't exist (up to now). > Error Code: > ERROR: Cannot ioctl TUNSETIFF tun0: Device or resource busy > (errno=16) openvpn said that? Yes, that sounds expected, right? 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
Allow Single connection only via networkmanager-openvpn (reuse tun0?)
I've just subscribed to a VPN service that has multiple locations, and imported all the necessary .ovpn files into Network Manager. It seems that I do not have the option to disconnect from the VPNs when connected, and upon choosing another location it creates another tun device. I've made the change to no success to /etc/NetworkManager/VPN/openvpn-service.name supports-multiple-connections=false Yet it still connects multiple locations without disconnecting the previous connection. Furthermore, I've set it to specifically use tun0 for my connections yet upon trying to load another connection even after "disabling" the VPN (I use Cinnamon Desktop) it says that it cannot access tun0 as the device is busy. I can disconnect via nmctl but was wondering if there was a way that I could force NetworkManaager to only use one VPN connection at a time, releasing back tun0 to be used again. Error Code: ERROR: Cannot ioctl TUNSETIFF tun0: Device or resource busy (errno=16) ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: OpenVPN isolation using NetworkNamespaces
On 02.04.2016 23:16, Thomas Haller wrote: > On Sat, 2016-04-02 at 21:49 +0200, Stjepan Groš wrote: >> I have one problem now. Namely, function _is_root in NMNetns doesn't >> work, or am I doing something wrong? When constructing >> NMNetnsController object the first NMNetns is created and that one >> should be for root network namespace. I'm using _is_root() to skip >> device initialization (for root that is done by NMManager now) but >> _is_root() returns FALSE? > Hi Stjepan, > > > The NMPNetns instance that represents the root namespace > is nmp_netns_get_initial(). You don't create that one, it's always > there. > > > You change to call > priv->nmp_netns = nmp_netns_new(); > is wrong. > This creates a new namespace and switches to it. When you switch > namespace at a certain moment, you *must* switch back before you return > from the function; that is, you must always call nmp_netns_pop() before > your function returns. > > The reason for that is, that at any point it must be known which > namespace is currently active. If you call a function and that function > switchs namespace, that function is required to restore the callers > namespace before returning. > > > For that reason, I think it's better that nm_netns_new() / > nm_netns_init() does *not* call nmp_netns_new() to create a new > namespace. > Instead, it seems more logical that it takes over the *current* > namespace nmp_netns_get_current(). So it's the job of the caller of > nm_netns_new() -- create_new_namespace() -- to prepare the namespace. > > Then, when creating the NMNetns instance for the root namespace, the > caller just does not call nmp_netns_new() but stays on the root > namespace. At that point, nmp_netns_get_currenty() equals > nmp_netns_get_initial() and it just works. > > > > Does that make sense? Yes, it makes sense. I tried it and it passed the problem I had. SG > > Thomas > > > > > >> The code with my changes to your branch is on the following URL: >> >> https://github.com/sgros/NETNS_NetworkManager >> >> SG signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: OpenVPN isolation using NetworkNamespaces
On Sat, 2016-04-02 at 21:49 +0200, Stjepan Groš wrote: > On 30.03.2016 17:26, Thomas Haller wrote: > > Hi, > > > > > > > > > 6. Certain aspects of NMManager are global for every network > > > > > namespace, others are not. For example, sleeping state (or > > > > > should > > > > > it > > > > > be separate for every network namespace so that some network > > > > > namespaces can be suspended?). > > > > > > > > > > 7. Related to 7, the best approach would be to refactor > > > > > NMManager > > > > > itself, but that would make very hard to keep HEAD and MIF > > > > > branches > > > > > in sync. > > > > Right, this was the biggest confusion I had. Your NMNetns takes > > > > over > > > > some work of NMManager, while NMManager is global. I guess that > > > > makes > > > > sense. > > > > But currently it's unclear which instance (NMManager, > > > > NMNetnsController, NMNetns, NMPolicy) does what, and how the > > > > interact > > > > with namespaces. > > > > > > > > I think this is difficult to get right. I think that NMNetns > > > > should > > > > be > > > > as simple as possible and more tell NMManager what to do. > > > > > > If you make NMNetns as simple as possible then NMManager must > > > take > > > care of network related changes within different network > > > namespaces, > > > i.e. new devices, IP addresses,etc. This, in turn, migh require > > > all > > > the methods from NMManager to be extended with additional > > > argument - > > > network namespace - which could possibly complicate things. > > > > > > It seems to me that it is lot easier to basically transform > > > NMManager > > > into NMNetns because root network namespace is just one possible > > > network namespace. All the current functionality done by > > > NMManager > > > within root network namespace should be done in every network > > > namespace. Of course, NMManager should stay, but only with the > > > functionality common to all network namespaces. > > > > Now, it could be that the approach of making NMNetns as simple as > > possible is better approach, but only way to find out is to try to > > make it so - which I think is non-trivial. > So NMNetns is basically becoming what NMManager is with all the per- > namespace responsibilities. Makes sense. > > NMManager stays to be a global manager (intra-namespace). > > I dislike that the name "NMNetns" is a prefix of "NMNetnsController", > but why is NMNetnsController a separate object? It doesn't have much > code and it also has it's own D-Bus path. Maybe those properties and > functions should be merged into the NMManager object. > > > Moving large parts of NMManager to NMNetns is probably the right > solution, but a bit hard to develop in parallel as master progresses. > > If that is done, then there is no need for NMNetnsController because > its functionality should be implemented in NMManager. > > I have one problem now. Namely, function _is_root in NMNetns doesn't > work, or am I doing something wrong? When constructing > NMNetnsController object the first NMNetns is created and that one > should be for root network namespace. I'm using _is_root() to skip > device initialization (for root that is done by NMManager now) but > _is_root() returns FALSE? Hi Stjepan, The NMPNetns instance that represents the root namespace is nmp_netns_get_initial(). You don't create that one, it's always there. You change to call priv->nmp_netns = nmp_netns_new(); is wrong. This creates a new namespace and switches to it. When you switch namespace at a certain moment, you *must* switch back before you return from the function; that is, you must always call nmp_netns_pop() before your function returns. The reason for that is, that at any point it must be known which namespace is currently active. If you call a function and that function switchs namespace, that function is required to restore the callers namespace before returning. For that reason, I think it's better that nm_netns_new() / nm_netns_init() does *not* call nmp_netns_new() to create a new namespace. Instead, it seems more logical that it takes over the *current* namespace nmp_netns_get_current(). So it's the job of the caller of nm_netns_new() -- create_new_namespace() -- to prepare the namespace. Then, when creating the NMNetns instance for the root namespace, the caller just does not call nmp_netns_new() but stays on the root namespace. At that point, nmp_netns_get_currenty() equals nmp_netns_get_initial() and it just works. Does that make sense? Thomas > > The code with my changes to your branch is on the following URL: > > https://github.com/sgros/NETNS_NetworkManager > > SG > 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: OpenVPN isolation using NetworkNamespaces
On 30.03.2016 17:26, Thomas Haller wrote: > Hi, > > 6. Certain aspects of NMManager are global for every network namespace, others are not. For example, sleeping state (or should it be separate for every network namespace so that some network namespaces can be suspended?). 7. Related to 7, the best approach would be to refactor NMManager itself, but that would make very hard to keep HEAD and MIF branches in sync. >>> Right, this was the biggest confusion I had. Your NMNetns takes >>> over >>> some work of NMManager, while NMManager is global. I guess that >>> makes >>> sense. >>> But currently it's unclear which instance (NMManager, >>> NMNetnsController, NMNetns, NMPolicy) does what, and how the >>> interact >>> with namespaces. >>> >>> I think this is difficult to get right. I think that NMNetns should >>> be >>> as simple as possible and more tell NMManager what to do. >> >> If you make NMNetns as simple as possible then NMManager must take >> care of network related changes within different network namespaces, >> i.e. new devices, IP addresses,etc. This, in turn, migh require all >> the methods from NMManager to be extended with additional argument - >> network namespace - which could possibly complicate things. >> >> It seems to me that it is lot easier to basically transform NMManager >> into NMNetns because root network namespace is just one possible >> network namespace. All the current functionality done by NMManager >> within root network namespace should be done in every network >> namespace. Of course, NMManager should stay, but only with the >> functionality common to all network namespaces. >> Now, it could be that the approach of making NMNetns as simple as >> possible is better approach, but only way to find out is to try to >> make it so - which I think is non-trivial. > So NMNetns is basically becoming what NMManager is with all the per- > namespace responsibilities. Makes sense. > > NMManager stays to be a global manager (intra-namespace). > > I dislike that the name "NMNetns" is a prefix of "NMNetnsController", > but why is NMNetnsController a separate object? It doesn't have much > code and it also has it's own D-Bus path. Maybe those properties and > functions should be merged into the NMManager object. > > > Moving large parts of NMManager to NMNetns is probably the right > solution, but a bit hard to develop in parallel as master progresses. If that is done, then there is no need for NMNetnsController because its functionality should be implemented in NMManager. I have one problem now. Namely, function _is_root in NMNetns doesn't work, or am I doing something wrong? When constructing NMNetnsController object the first NMNetns is created and that one should be for root network namespace. I'm using _is_root() to skip device initialization (for root that is done by NMManager now) but _is_root() returns FALSE? The code with my changes to your branch is on the following URL: https://github.com/sgros/NETNS_NetworkManager SG signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: OpenVPN isolation using NetworkNamespaces
Hi,
On Wed, 2016-03-30 at 16:22 +0200, Stjepan Groš wrote:
> On 29.03.2016 14:10, Thomas Haller wrote:
> > On Tue, 2016-03-29 at 13:13 +0200, Stjepan Groš wrote:
> > > On 29.03.2016 12:52, Thomas Haller wrote:
> > > > On Sat, 2016-02-27 at 09:34 +0100, Stjepan Groš wrote:
> > > > > Hi!
> > > > Hi Stjepan,
> > > >
> > > > after the changes done to master, I took your MIF branch, and
> > > > re-
> > > > merged
> > > > master into it. The result is here:
> > > >
> > > > https://cgit.freedesktop.org/NetworkManager/NetworkManager/log/
> > > > ?h=t
> > > > h/mif
> > > >
> > > > I didn't actually test it, so don't expect it to work.
> > > >
> > > >
> > > > Anyway, I hope it might be useful for you.
> > > > Thomas
> > >
> > > Hi Thomas,
> > >
> > > thanks for the merge. I'll take a look at it.
> > >
> > > In the last few days I also managed to merge HEAD with MIF branch
> > > and
> > > to remove some stuff that probably will not be needed (like
> > > activating specific network namespaces from within
> > > NMNetnsController). I have to admit that on several occasions I
> > > was
> > > thinking of throwing everything away and starting from scratch,
> > > but
> > > that wouldn't take me far...
> > I think for prototyping this is fine. We should identify places
> > that
> > can be individually fixed on master to prepare master for namespace
> > support. Kinda making small steps on master to move it towards the
> > namespace branch.
> >
> > > Anyway, I just pushed all the changes I have to GitHub. Quick
> > > test
> > > shows that NM works.
> > >
> > > I hit the following obstacles/problems/things:
> > Oh, I see.
> >
> >
> >
> > > 1. I have yet to try to figure out how did you intend
> > > NMPlatform/NMPNetns to work in order to better integrate that
> > > into
> > > MIF Branch. (maybe your merge will help here)
> > >
> > > 2. You create singleton NMPlatform object while network namespace
> > > support needs many. So, how/where/what to do.
> > Currently on master there is only one NM_PLATFORM_GET instance. But
> > in
> > your branch, you will create multiple platform instances.
>
> I already did that, there is still NM_PLATFORM_GET for NMManager
> object.
>
> >
> >
> > > 3. How to create new network namespace from outside of NMPlatform
> > > object.
> > There are two separate things: NMPNetns and NMNetns.
> >
> > NMPNetns is a very simple object to hold the file descriptor of the
> > namespace, it does setns() and you can use nmp_netns_new() to
> > create a
> > new namespace (unshare).
>
> I think nmp_netns_new() has to accept name of network namespace that
> will be created in /var/run/netns directory.
That would be possible. But I'd rather leave it to the caller (the one
who creates the NMPNetns instance) to bind-mount the namespace to
whatever file he wants.
Also, NMPNetns exists so that NMPlatform, NMRDisc, etc. can switch to
their namespace as needed. They don't need any bind-mounted file for
that.
In case of th/netns branch, this is done by nm_netns_setup() by calling
nmp_netns_bind_to_path().
>
> >
> > NMNetns is a higher level object to represent the namespace. It is
> > not
> > concerned with unshare()/setns() or the file descriptor. It
> > consists of
> > instances of NMPNetns, NMPlatform, NMRouteManager, NMPolicy(?),
> > etc.
> > As in your branch, it also takes over some work from NMManager.
> >
> > On the higher layer you don't need to switch to a namespace --
> > that's
> > why I dropped nm_netns_controller_activate_netns(). When a lower
> > layer
> > object does something for which it needs a certain namespace, it
> > must
> > switch itself (via its NMPNetns instance).
> >
> >
> > > 4. When creating new network namespace in NMPlatform NETLINK
> > > sockets
> > > are created, but before they are created network namespace has to
> > > be
> > > switched.
> > NMPlatform *
> > _create_new_platform_in_new_namespace ()
> > {
> > NMPNetns
> > *netnsp;
> > NMPlatform *platoform;
> >
> > /* create a new namespace and switch to it */
> > netnsp = nmp_netns_new ();
> > if (!netnsp)
> > return NULL;
> >
> > /* create a new platform instance in the new namespace */
> > platform = nm_linux_platform_new();
> >
> > /* return to the previous namespace: */
> > nmp_netns_pop (netnsp);
> >
> > /* The namespace is also referenced by the platform instance.
> > Depending on what we want, we can drop our reference at
> > this
> > point. It's still accessible via nm_platform_netns_get(). */
> > g_object_unref (netnsp);
> > return platform;
> > }
>
> Yes, something like that.
>
> >
> >
> >
> > > 5. NMPolicy isn't singleton any more, and it is not tied to
> > > NMManager
> > > object but to the NMNetns object.
> > I didn't really understand what to do with policy. NMPolicy is
> > mostly
> > concerned about the default-route and resolv.conf. Do you even need
> > that in other namespaces? Maybe it should only exist
Re: OpenVPN isolation using NetworkNamespaces
On 29.03.2016 14:10, Thomas Haller wrote:
> On Tue, 2016-03-29 at 13:13 +0200, Stjepan Groš wrote:
>> On 29.03.2016 12:52, Thomas Haller wrote:
>>> On Sat, 2016-02-27 at 09:34 +0100, Stjepan Groš wrote:
Hi!
>>> Hi Stjepan,
>>>
>>> after the changes done to master, I took your MIF branch, and re-
>>> merged
>>> master into it. The result is here:
>>>
>>> https://cgit.freedesktop.org/NetworkManager/NetworkManager/log/?h=t
>>> h/mif
>>>
>>> I didn't actually test it, so don't expect it to work.
>>>
>>>
>>> Anyway, I hope it might be useful for you.
>>> Thomas
>>
>> Hi Thomas,
>>
>> thanks for the merge. I'll take a look at it.
>>
>> In the last few days I also managed to merge HEAD with MIF branch and
>> to remove some stuff that probably will not be needed (like
>> activating specific network namespaces from within
>> NMNetnsController). I have to admit that on several occasions I was
>> thinking of throwing everything away and starting from scratch, but
>> that wouldn't take me far...
> I think for prototyping this is fine. We should identify places that
> can be individually fixed on master to prepare master for namespace
> support. Kinda making small steps on master to move it towards the
> namespace branch.
>
>> Anyway, I just pushed all the changes I have to GitHub. Quick test
>> shows that NM works.
>>
>> I hit the following obstacles/problems/things:
> Oh, I see.
>
>
>
>> 1. I have yet to try to figure out how did you intend
>> NMPlatform/NMPNetns to work in order to better integrate that into
>> MIF Branch. (maybe your merge will help here)
>>
>> 2. You create singleton NMPlatform object while network namespace
>> support needs many. So, how/where/what to do.
> Currently on master there is only one NM_PLATFORM_GET instance. But in
> your branch, you will create multiple platform instances.
I already did that, there is still NM_PLATFORM_GET for NMManager object.
>
>
>> 3. How to create new network namespace from outside of NMPlatform
>> object.
> There are two separate things: NMPNetns and NMNetns.
>
> NMPNetns is a very simple object to hold the file descriptor of the
> namespace, it does setns() and you can use nmp_netns_new() to create a
> new namespace (unshare).
I think nmp_netns_new() has to accept name of network namespace that
will be created in /var/run/netns directory.
>
> NMNetns is a higher level object to represent the namespace. It is not
> concerned with unshare()/setns() or the file descriptor. It consists of
> instances of NMPNetns, NMPlatform, NMRouteManager, NMPolicy(?), etc.
> As in your branch, it also takes over some work from NMManager.
>
> On the higher layer you don't need to switch to a namespace -- that's
> why I dropped nm_netns_controller_activate_netns(). When a lower layer
> object does something for which it needs a certain namespace, it must
> switch itself (via its NMPNetns instance).
>
>
>> 4. When creating new network namespace in NMPlatform NETLINK sockets
>> are created, but before they are created network namespace has to be
>> switched.
> NMPlatform *
> _create_new_platform_in_new_namespace ()
> {
> NMPNetns
> *netnsp;
> NMPlatform *platoform;
>
> /* create a new namespace and switch to it */
> netnsp = nmp_netns_new ();
> if (!netnsp)
> return NULL;
>
> /* create a new platform instance in the new namespace */
> platform = nm_linux_platform_new();
>
> /* return to the previous namespace: */
> nmp_netns_pop (netnsp);
>
> /* The namespace is also referenced by the platform instance.
>Depending on what we want, we can drop our reference at this
>point. It's still accessible via nm_platform_netns_get(). */
> g_object_unref (netnsp);
> return platform;
> }
Yes, something like that.
>
>
>
>> 5. NMPolicy isn't singleton any more, and it is not tied to NMManager
>> object but to the NMNetns object.
> I didn't really understand what to do with policy. NMPolicy is mostly
> concerned about the default-route and resolv.conf. Do you even need
> that in other namespaces? Maybe it should only exist in the main
> namespace.
You definitely need separate resolv.conf in network namespace in order
to be able to have different DNS servers.
"ip netns exec" bind mounts resolv.conf from /etc/netns/ if
it exists over /etc/resolv.conf.
>
>> 6. Certain aspects of NMManager are global for every network
>> namespace, others are not. For example, sleeping state (or should it
>> be separate for every network namespace so that some network
>> namespaces can be suspended?).
>>
>> 7. Related to 7, the best approach would be to refactor NMManager
>> itself, but that would make very hard to keep HEAD and MIF branches
>> in sync.
> Right, this was the biggest confusion I had. Your NMNetns takes over
> some work of NMManager, while NMManager is global. I guess that makes
> sense.
> But currently it's unclear which instance (NMManager,
> NMNetnsController, NMNetns, NMPolicy) does what, and how the interact
> w
Re: OpenVPN isolation using NetworkNamespaces
On Tue, 2016-03-29 at 13:13 +0200, Stjepan Groš wrote:
> On 29.03.2016 12:52, Thomas Haller wrote:
> > On Sat, 2016-02-27 at 09:34 +0100, Stjepan Groš wrote:
> > > Hi!
> > Hi Stjepan,
> >
> > after the changes done to master, I took your MIF branch, and re-
> > merged
> > master into it. The result is here:
> >
> > https://cgit.freedesktop.org/NetworkManager/NetworkManager/log/?h=t
> > h/mif
> >
> > I didn't actually test it, so don't expect it to work.
> >
> >
> > Anyway, I hope it might be useful for you.
> > Thomas
>
> Hi Thomas,
>
> thanks for the merge. I'll take a look at it.
>
> In the last few days I also managed to merge HEAD with MIF branch and
> to remove some stuff that probably will not be needed (like
> activating specific network namespaces from within
> NMNetnsController). I have to admit that on several occasions I was
> thinking of throwing everything away and starting from scratch, but
> that wouldn't take me far...
I think for prototyping this is fine. We should identify places that
can be individually fixed on master to prepare master for namespace
support. Kinda making small steps on master to move it towards the
namespace branch.
>
> Anyway, I just pushed all the changes I have to GitHub. Quick test
> shows that NM works.
>
> I hit the following obstacles/problems/things:
Oh, I see.
> 1. I have yet to try to figure out how did you intend
> NMPlatform/NMPNetns to work in order to better integrate that into
> MIF Branch. (maybe your merge will help here)
>
> 2. You create singleton NMPlatform object while network namespace
> support needs many. So, how/where/what to do.
Currently on master there is only one NM_PLATFORM_GET instance. But in
your branch, you will create multiple platform instances.
> 3. How to create new network namespace from outside of NMPlatform
> object.
There are two separate things: NMPNetns and NMNetns.
NMPNetns is a very simple object to hold the file descriptor of the
namespace, it does setns() and you can use nmp_netns_new() to create a
new namespace (unshare).
NMNetns is a higher level object to represent the namespace. It is not
concerned with unshare()/setns() or the file descriptor. It consists of
instances of NMPNetns, NMPlatform, NMRouteManager, NMPolicy(?), etc.
As in your branch, it also takes over some work from NMManager.
On the higher layer you don't need to switch to a namespace -- that's
why I dropped nm_netns_controller_activate_netns(). When a lower layer
object does something for which it needs a certain namespace, it must
switch itself (via its NMPNetns instance).
> 4. When creating new network namespace in NMPlatform NETLINK sockets
> are created, but before they are created network namespace has to be
> switched.
NMPlatform *
_create_new_platform_in_new_namespace ()
{
NMPNetns
*netnsp;
NMPlatform *platoform;
/* create a new namespace and switch to it */
netnsp = nmp_netns_new ();
if (!netnsp)
return NULL;
/* create a new platform instance in the new namespace */
platform = nm_linux_platform_new();
/* return to the previous namespace: */
nmp_netns_pop (netnsp);
/* The namespace is also referenced by the platform instance.
Depending on what we want, we can drop our reference at this
point. It's still accessible via nm_platform_netns_get(). */
g_object_unref (netnsp);
return platform;
}
> 5. NMPolicy isn't singleton any more, and it is not tied to NMManager
> object but to the NMNetns object.
I didn't really understand what to do with policy. NMPolicy is mostly
concerned about the default-route and resolv.conf. Do you even need
that in other namespaces? Maybe it should only exist in the main
namespace.
> 6. Certain aspects of NMManager are global for every network
> namespace, others are not. For example, sleeping state (or should it
> be separate for every network namespace so that some network
> namespaces can be suspended?).
>
> 7. Related to 7, the best approach would be to refactor NMManager
> itself, but that would make very hard to keep HEAD and MIF branches
> in sync.
Right, this was the biggest confusion I had. Your NMNetns takes over
some work of NMManager, while NMManager is global. I guess that makes
sense.
But currently it's unclear which instance (NMManager,
NMNetnsController, NMNetns, NMPolicy) does what, and how the interact
with namespaces.
I think this is difficult to get right. I think that NMNetns should be
as simple as possible and more tell NMManager what to do.
> Anyway, I got to the step where I can invoke D-Bus method to create
> new network namespace and I have to debug that use case now.
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: OpenVPN isolation using NetworkNamespaces
On 29.03.2016 12:52, Thomas Haller wrote: > On Sat, 2016-02-27 at 09:34 +0100, Stjepan Groš wrote: >> Hi! > Hi Stjepan, > > after the changes done to master, I took your MIF branch, and re-merged > master into it. The result is here: > > https://cgit.freedesktop.org/NetworkManager/NetworkManager/log/?h=th/mif > > I didn't actually test it, so don't expect it to work. > > > Anyway, I hope it might be useful for you. > Thomas Hi Thomas, thanks for the merge. I'll take a look at it. In the last few days I also managed to merge HEAD with MIF branch and to remove some stuff that probably will not be needed (like activating specific network namespaces from within NMNetnsController). I have to admit that on several occasions I was thinking of throwing everything away and starting from scratch, but that wouldn't take me far... Anyway, I just pushed all the changes I have to GitHub. Quick test shows that NM works. I hit the following obstacles/problems/things: 1. I have yet to try to figure out how did you intend NMPlatform/NMPNetns to work in order to better integrate that into MIF Branch. (maybe your merge will help here) 2. You create singleton NMPlatform object while network namespace support needs many. So, how/where/what to do. 3. How to create new network namespace from outside of NMPlatform object. 4. When creating new network namespace in NMPlatform NETLINK sockets are created, but before they are created network namespace has to be switched. 5. NMPolicy isn't singleton any more, and it is not tied to NMManager object but to the NMNetns object. 6. Certain aspects of NMManager are global for every network namespace, others are not. For example, sleeping state (or should it be separate for every network namespace so that some network namespaces can be suspended?). 7. Related to 7, the best approach would be to refactor NMManager itself, but that would make very hard to keep HEAD and MIF branches in sync. Anyway, I got to the step where I can invoke D-Bus method to create new network namespace and I have to debug that use case now. SG signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: OpenVPN isolation using NetworkNamespaces
On Sat, 2016-02-27 at 09:34 +0100, Stjepan Groš wrote: > Hi! Hi Stjepan, after the changes done to master, I took your MIF branch, and re-merged master into it. The result is here: https://cgit.freedesktop.org/NetworkManager/NetworkManager/log/?h=th/mif I didn't actually test it, so don't expect it to work. Anyway, I hope it might be useful for 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
OpenVPN isolation using NetworkNamespaces
Hi! I just commited to my repository (https://github.com/sgros/MIF_NetworkManager) functionality that allows VPN's with virtual devices to be isolated within a separate network namespace. For that purpose there are the following parameters within connection section of VPN configuration file: netns-isolate=[true|false] => if "true" VPN connection will be isolated netns-persistent=[true|false] => should network namespace be removed (false) when VPN connection is terminated or not (true) netns-name=[uuid|name|] => the name of the network namespace. uuid and name take connection uuid and ID respectively, while anything else is taken as is netns-timeout=ms => how long to wait for virtual device to be switched from source network namespace to the target network namespace. namely, due to the sequence of events that should occur while moving device between network namespaces (event of new device, event of removal of existing device) this process must be asynchronous and so we have to wait. this parameter defines the maximum wait time. Trygin this with OpenVPN works for me. But, as usuall, this is very likely full of bugs and there are lot of missing features. Few ideas/TODOs for the follow up: 1. Expose method to move devices (nm_netns_take_device) via D-Bus (exists, but it's an old design and should be reworked). 2. Modify NMActRequest to also allow isolation the same way as VPN connections. 3. Add method to allow device cloning (e.g. macvlan or veth) that will allow a same connection in multipe network namespaces. This will also allow VPNs without virtual interfaces to be isolated. Then, I suppose, I have all the mechanism to proceed to PvD manipulation. SG signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
