Mike, > So to be completely clear, there is no bug if you are using the stable > version of NetworkManager? You can connect once from a clean reboot > using OpenConnect 7.06-2 command line and everything works perfectly?
Affirmative. > The bug that you've described is that the VPN tunnel is not configured > correctly, but only on the first connection attempt after a reboot, and > only when running NetworkManager 1.0.6? Affirmative. > If I've understood that right, then it seems like the variable and > likely culprit is NetworkManager 1.0.6. > > Have you been able to tell which property of your VPN link is not > configured right when you say you are not "able to reach any address"? > Is it the routing table, DNS, MTU? Yes, problem appears when using NetworkManager 1.0.6 and opencconect 7.06-2+b1 Routing table and MTU remain the same between the reconnects. Only thing that changes is DNS. this example of resolv.conf looks like after reconnect, before that it only has one (different) nameserver entry: --- #@VPNC_GENERATED@ -- this file is generated by vpnc # and will be overwritten by vpnc # as long as the above mark is intact # Generated by NetworkManager nameserver IP1 nameserver IP2 search domain1, domain2, domain3, domain4, domain5, domain6, domain7, domain7 --- > Can you perhaps test in an unstable container or VM with a simple static > IP config and no NetworkManager? > > But this is only to eliminate or implicate NM. If we already think NM is > implicated, then nevermind. When using fully unstable environment, everything works as expected. No need to reconnect. ------------------------------------------ Distributor ID: Debian Description: Debian GNU/Linux unstable (sid) Release: unstable Codename: sid --- network-manager (1.0.6-1) openconnect (7.06-2+b1) ------------------------------------------ syslog: Sep 9 10:31:06 sid NetworkManager[460]: <info> (tun0): new Tun device (carrier: OFF, driver: 'tun', ifindex: 3) Sep 9 10:31:06 sid kernel: [ 9924.422719] tun: Universal TUN/TAP device driver, 1.6 Sep 9 10:31:06 sid kernel: [ 9924.422722] tun: (C) 1999-2004 Max Krasnyansky <m...@qualcomm.com> Sep 9 10:31:06 sid NetworkManager[460]: <info> devices added (path: /sys/devices/virtual/net/tun0, iface: tun0) Sep 9 10:31:06 sid NetworkManager[460]: <info> device added (path: /sys/devices/virtual/net/tun0, iface: tun0): no ifupdown configuration found. Sep 9 10:31:06 sid NetworkManager[460]: <info> (tun0): link connected Sep 9 10:31:06 sid NetworkManager[460]: <info> keyfile: add connection in-memory (7518566c-321e-48e6-842e-3d4e079d4083,"tun0") Sep 9 10:31:06 sid NetworkManager[460]: <info> (tun0): device state change: unmanaged -> unavailable (reason 'connection-assumed') [10 20 41] Sep 9 10:31:06 sid NetworkManager[460]: <info> (tun0): device state change: unavailable -> disconnected (reason 'connection-assumed') [20 30 41] Sep 9 10:31:06 sid NetworkManager[460]: <info> (tun0): Activation: starting connection 'tun0' (7518566c-321e-48e6-842e-3d4e079d4083) Sep 9 10:31:06 sid NetworkManager[460]: <info> (tun0): device state change: disconnected -> prepare (reason 'none') [30 40 0] Sep 9 10:31:06 sid NetworkManager[460]: <info> (tun0): device state change: prepare -> config (reason 'none') [40 50 0] Sep 9 10:31:06 sid NetworkManager[460]: <info> (tun0): device state change: config -> ip-config (reason 'none') [50 70 0] Sep 9 10:31:06 sid NetworkManager[460]: <info> (tun0): device state change: ip-config -> ip-check (reason 'none') [70 80 0] Sep 9 10:31:06 sid NetworkManager[460]: <info> (tun0): device state change: ip-check -> secondaries (reason 'none') [80 90 0] Sep 9 10:31:06 sid NetworkManager[460]: <info> (tun0): device state change: secondaries -> activated (reason 'none') [90 100 0] Sep 9 10:31:06 sid NetworkManager[460]: <info> (tun0): Activation: successful, device activated. Sep 9 10:31:06 sid dbus[455]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service' Sep 9 10:31:06 sid systemd[1]: Starting Network Manager Script Dispatcher Service... Sep 9 10:31:06 sid NetworkManager[460]: <info> NetworkManager state is now CONNECTED_LOCAL Sep 9 10:31:06 sid NetworkManager[460]: <info> NetworkManager state is now CONNECTED_GLOBAL Sep 9 10:31:06 sid NetworkManager[460]: <info> Policy set 'tun0' (tun0) as default for IPv4 routing and DNS. Sep 9 10:31:06 sid dbus[455]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher' Sep 9 10:31:06 sid systemd[1]: Started Network Manager Script Dispatcher Service. Sep 9 10:31:06 sid nm-dispatcher: Dispatching action 'up' for tun0 Sep 9 10:31:06 sid avahi-daemon[457]: Got SIGTERM, quitting. Sep 9 10:31:06 sid systemd[1]: Stopping Avahi mDNS/DNS-SD Stack... Sep 9 10:31:06 sid avahi-daemon[457]: Leaving mDNS multicast group on interface eth0.IPv6 with address fe80::a00:27ff:feba:8991. Sep 9 10:31:06 sid avahi-daemon[457]: Leaving mDNS multicast group on interface eth0.IPv4 with address 10.0.2.15. Sep 9 10:31:06 sid avahi-daemon[457]: avahi-daemon 0.6.31 exiting. Sep 9 10:31:06 sid systemd[1]: Stopped Avahi mDNS/DNS-SD Stack. Sep 9 10:31:06 sid nm-dispatcher[1377]: Warning: Stopping avahi-daemon.service, but it can still be activated by: Sep 9 10:31:06 sid nm-dispatcher[1377]: avahi-daemon.socket Sep 9 10:31:06 sid avahi: Avahi detected that your currently configured local DNS server serves Sep 9 10:31:06 sid avahi: a domain .local. This is inherently incompatible with Avahi and thus Sep 9 10:31:06 sid avahi: Avahi disabled itself. If you want to use Avahi in this network, please Sep 9 10:31:06 sid avahi: contact your administrator and convince him to use a different DNS domain, Sep 9 10:31:06 sid avahi: since .local should be used exclusively for Zeroconf technology. Sep 9 10:31:06 sid avahi: For more information, see http://avahi.org/wiki/AvahiAndUnicastDotLocal Sep 9 10:31:06 sid systemd[1]: Reloading OpenBSD Secure Shell server. Sep 9 10:31:06 sid systemd[1]: Reloaded OpenBSD Secure Shell server. Sep 9 10:31:16 sid NetworkManager[460]: <info> NetworkManager state is now CONNECTED_LOCAL Sep 9 10:31:16 sid NetworkManager[460]: <info> NetworkManager state is now CONNECTED_GLOBAL Sep 9 10:31:16 sid NetworkManager[460]: <info> Policy set 'Wired connection 1' (eth0) as default for IPv4 routing and DNS. Sep 9 10:31:16 sid NetworkManager[460]: <info> (tun0): device state change: activated -> unmanaged (reason 'removed') [100 10 36] Sep 9 10:31:16 sid NetworkManager[460]: <warn> (tun0): failed to disable userspace IPv6LL address handling Sep 9 10:31:16 sid nm-dispatcher: Dispatching action 'down' for tun0 Sep 9 10:31:16 sid gnome-session[957]: Gjs-Message: JS LOG: Removing a network device that was not added Sep 9 10:31:16 sid NetworkManager[460]: <info> devices removed (path: /sys/devices/virtual/net/tun0, iface: tun0) Sep 9 10:31:16 sid systemd[1]: Starting Avahi mDNS/DNS-SD Stack... Sep 9 10:31:16 sid avahi-daemon[1545]: Process 457 died: No such process; trying to remove PID file. (/var/run/avahi-daemon//pid) Sep 9 10:31:16 sid avahi-daemon[1545]: Found user 'avahi' (UID 105) and group 'avahi' (GID 110). Sep 9 10:31:16 sid avahi-daemon[1545]: Successfully dropped root privileges. Sep 9 10:31:16 sid avahi-daemon[1545]: avahi-daemon 0.6.31 starting up. Sep 9 10:31:16 sid systemd[1]: Started Avahi mDNS/DNS-SD Stack. Sep 9 10:31:16 sid avahi-daemon[1545]: Successfully called chroot(). Sep 9 10:31:16 sid avahi-daemon[1545]: Successfully dropped remaining capabilities. Sep 9 10:31:16 sid avahi-daemon[1545]: No service file found in /etc/avahi/services. Sep 9 10:31:16 sid avahi-daemon[1545]: Joining mDNS multicast group on interface eth0.IPv6 with address fe80::a00:27ff:feba:8991. Sep 9 10:31:16 sid avahi-daemon[1545]: New relevant interface eth0.IPv6 for mDNS. Sep 9 10:31:16 sid avahi-daemon[1545]: Joining mDNS multicast group on interface eth0.IPv4 with address 10.0.2.15. Sep 9 10:31:16 sid avahi-daemon[1545]: New relevant interface eth0.IPv4 for mDNS. Sep 9 10:31:16 sid avahi-daemon[1545]: Network interface enumeration completed. Sep 9 10:31:16 sid avahi-daemon[1545]: Registering new address record for fe80::a00:27ff:feba:8991 on eth0.*. Sep 9 10:31:16 sid avahi-daemon[1545]: Registering new address record for 10.0.2.15 on eth0.IPv4. Sep 9 10:31:16 sid avahi-daemon[1545]: Registering HINFO record with values 'X86_64'/'LINUX'. ------------------------------------------ However, I really don't want to upgrade my whole environment to unstable, as this is my production notebook. David, > And if the only thing that NM is accused of is not working well when > you try to set network devices up behind its back, then nevermind > indeed. > > It would be nice to have Juniper support which *does* work properly > with NetworkManager. It's possible for now just by building > libopenconnect with Juniper as the default, instead of AnyConnect. > > Before I support it for real, I really want to sort out the HTML > authentication forms (letting the UI render real HTML instead of the > hack I currently have to parse the known forms and fail on anything non > -standard). Having Juniper support with openconnect is the first proper solution on Linux. Other options are to use a browser, or to use various (third party) scripts to establish the connection. It would be nice to get it working using my current set-up. Which is APT Pinning with base system on stable with network-manager/openconnect from testing/unstable. Other option is to fully upgrade to unstable and then everything will work as expected. But, I'm not sure a lot of people want this on their (possibly production) environments on unstable. Third option is to backport openconnect 7.x to Jessie, but taking in consideration all its dependencies, this might be a bit complicated task. Either way, please let me know if either of you have any additional ideas or input you need from my side. Regards, Adnan On Wed, Sep 9, 2015 at 12:58 AM, Mike Miller <mtmil...@debian.org> wrote: > On Mon, Sep 07, 2015 at 20:10:47 +0200, Adnan Hodzic wrote: > > Using openconnect (7.06-2) from unstable with network-manager from stable > > (0.9.10.0-7) will work as expected. Connection with VPN will immediately > be > > established, and there won't be need to reconnect. > > So to be completely clear, there is no bug if you are using the stable > version of NetworkManager? You can connect once from a clean reboot > using OpenConnect 7.06-2 command line and everything works perfectly? > > The bug that you've described is that the VPN tunnel is not configured > correctly, but only on the first connection attempt after a reboot, and > only when running NetworkManager 1.0.6? > > If I've understood that right, then it seems like the variable and > likely culprit is NetworkManager 1.0.6. > > Have you been able to tell which property of your VPN link is not > configured right when you say you are not "able to reach any address"? > Is it the routing table, DNS, MTU? > > > No, if I stop network-manager, I will lose all connectivity and > openconnect > > will fail to establish a connection. > > Can you perhaps test in an unstable container or VM with a simple static > IP config and no NetworkManager? > > But this is only to eliminate or implicate NM. If we already think NM is > implicated, then nevermind. > > -- > mike >
