connecting to vpn fails with could not find source connection

Bug #1426840 reported by Michael Tsang on 2015-03-01
This bug affects 7 people
Affects Status Importance Assigned to Milestone
network-manager-openconnect (Ubuntu)

Bug Description

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)

lo Link encap:Local Loopback
          inet addr: Mask:
          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
          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 has address has IPv6 address 2001:470:19:a87::9308:ae03 mail is handled by 10 mail is handled by 50
michael@laptop-ubuntu:~$ ping6 -c 4
PING 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

--- 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
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)

Michael Tsang (miklcct) wrote :
Launchpad Janitor (janitor) wrote :

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

Changed in network-manager-openconnect (Ubuntu):
status: New → Confirmed
Changed in network-manager-openconnect (Ubuntu):
importance: Undecided → High
Thomas Hood (jdthood) wrote :

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

Changed in network-manager-openconnect (Ubuntu):
status: Confirmed → Incomplete


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

openconnect doesn't work with

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

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) wrote :

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) wrote :

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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers