connecting to vpn fails with could not find source connection

[Michael Tsang]

I am trying to connect to the VPN of my department. However, it fails with "could not find source connection". However, there is no problem in my Internet connectivity and the VPN server can be reached.

michael@laptop-ubuntu:~$ ifconfig
eth0 Link encap:Ethernet HWaddr e8:11:32:9b:03:49
          UP BROADCAST MULTICAST MTU:1500 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
          Interrupt:16

lo Link encap:Local Loopback
          inet addr:127.0.0.1 Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING MTU:65536 Metric:1
          RX packets:189 errors:0 dropped:0 overruns:0 frame:0
          TX packets:189 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:14294 (14.2 KB) TX bytes:14294 (14.2 KB)

wlan0 Link encap:Ethernet HWaddr 90:a4:de:3c:5e:6d
          inet6 addr: 2001:470:fab7:1:92a4:deff:fe3c:5e6d/64 Scope:Global
          inet6 addr: 2001:470:fab7:1:907b:b196:403:91ca/128 Scope:Global
          inet6 addr: 2001:470:fab7:1:c01d:7af9:8c49:1d3e/64 Scope:Global
          inet6 addr: fe80::92a4:deff:fe3c:5e6d/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:10344 errors:0 dropped:1 overruns:0 frame:0
          TX packets:8347 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:8453922 (8.4 MB) TX bytes:1473179 (1.4 MB)

michael@laptop-ubuntu:~$ host vpn.cs.hku.hk
vpn.cs.hku.hk has address 147.8.174.3
vpn.cs.hku.hk has IPv6 address 2001:470:19:a87::9308:ae03
vpn.cs.hku.hk mail is handled by 10 ns.cs.hku.hk.
vpn.cs.hku.hk mail is handled by 50 cs.hku.hk.
michael@laptop-ubuntu:~$ ping6 -c 4 vpn.cs.hku.hk
PING vpn.cs.hku.hk(2001:470:19:a87::9308:ae03) 56 data bytes
64 bytes from 2001:470:19:a87::9308:ae03: icmp_seq=1 ttl=244 time=8.47 ms
64 bytes from 2001:470:19:a87::9308:ae03: icmp_seq=2 ttl=244 time=17.1 ms
64 bytes from 2001:470:19:a87::9308:ae03: icmp_seq=3 ttl=244 time=83.0 ms
64 bytes from 2001:470:19:a87::9308:ae03: icmp_seq=4 ttl=244 time=14.4 ms

--- vpn.cs.hku.hk ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3002ms
rtt min/avg/max/mdev = 8.477/30.782/83.006/30.315 ms

ProblemType: Bug
DistroRelease: Ubuntu 14.10
Package: network-manager-openconnect 0.9.8.6-1ubuntu2
ProcVersionSignature: Ubuntu 3.16.0-31.41-generic 3.16.7-ckt5
Uname: Linux 3.16.0-31-generic x86_64
ApportVersion: 2.14.7-0ubuntu8.2
Architecture: amd64
CurrentDesktop: KDE
Date: Sun Mar 1 17:22:03 2015
InstallationDate: Installed on 2015-01-25 (34 days ago)
InstallationMedia: Ubuntu-Server 14.10 "Utopic Unicorn" - Release amd64 (20141022.2)
SourcePackage: network-manager-openconnect
UpgradeStatus: No upgrade log present (probably fresh install)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Thomas Hood (jdthood)]

Michael, have you made any progress in figuring out the cause of this bug?

[lours974 Vitry David Gilbert (david-vitry)]

Bonjour,

With managed=false in /etc/NetworkManager/NetworkManager.conf, and configuration of eth0 in /etc/network/interfaces

openconnect doesn't work with

<pre>
juil. 03 05:54:03 lours gnome-session[4516]: (gnome-shell:4665): libnm-glib-WARNING **: Device activation failed: (32) Could not find source connection.
</pre>

[Julius Schwartzenberg (jschwart)]

I've got the same issue on Xenial. On a system where NM probably does manage the uplink connection, this problem does not occur.

[Mike Miller (mtmiller)]

So it seems to me there is no bug here. If the OP is still following, is the wlan0 device managed by NM or not? If the base connection is not managed by NM, then NM will not be able to bring up VPNs either.

[Chad Miller (cmiller)]

I don't agree with mtm that there is no bug here.

The availability of VPN should not have to depend on another interface being managed by Network Manager. Detection of the other device's state should be enough, and full administration should be unnecessary.

[Jan Groenewald (jan-aims)]

I am running into similar issue with network-manager-fortisslvpn. A computer lab has many wired machines not managed by Network Manager, but some guests need to use a VPN to connect to their home institution.

[Luís Infante da Câmara (luis220413)]

I do not know how to manually expire a bug task. Therefore, I am setting the status of the Ubuntu bug task to Invalid.