NetworkManager does not auto-connect to VPNs marked "Connect Automatically"

Bug #280571 reported by Biji on 2008-10-09
This bug affects 95 people
Affects Status Importance Assigned to Milestone
Fix Released
network-manager (Debian)
Fix Released
network-manager-openvpn (Ubuntu)

Bug Description

VPN connections marked "Connect Automatically" are not activated when a wired or wireless network becomes available.

Fixed upstream in commit:

commit ece5e209cdc409a21e249dacbdbc953a1db4c6b7
Author: Jiří Klimeš <email address hidden>
Date: Tue Aug 21 17:49:41 2012 +0200

    core: VPN autoconnect feature (bgo #560471) (rh #483120)

    We go through the SECONDARIES state where we check if there are some
    (VPN or other) UUIDs that are to be activated before progressing to
    In case of an error with a secondary UUID or its activation, the base
    can't activate successfully.

Alexander Sack (asac) wrote :

could you please test the latest intrepid packages and if that doesnt help post a bug about this at and drop the bug id you get there here? Thanks.

Changed in network-manager:
importance: Undecided → Low
status: New → Incomplete
Alexander Sack (asac) wrote :

also state what vpn you are trying to connect to. attach your complete syslog as well.

Biji (biji) wrote :

Here is versions:

ii network-manager 0.7~~svn20081008t224042-0ubuntu3 network management framework daemon
ii network-manager-gnome 0.7~~svn20081012t133407-0ubuntu1 network management framework (GNOME frontend
ii network-manager-openvpn 0.7~~svn20081008t224042-0ubuntu1 network management framework (OpenVPN plugin
ii network-manager-pptp 0.7~~svn20081008t224042-0ubuntu1 network management framework (PPTP plugin)

vpn using openvpn to connect using Password-ed type of VPN

Tristan Hill (stan) wrote :

Possible duplicate of .

The "related:" comment from appears to talk about this - although no apparent mention of the "Connect Automatically" checkbox (which may have been added since that bug was created)

Gabriel Bauman (gabrielbauman) wrote :

I've tested using an OpenVPN connection on latest 8.10. Reconnecting to wireless or any other network does not cause the VPN to autoconnect, with the VPN's "connect automatically" option checked.

 o network-manager:

 o network-manager-openvpn:

Gabriel Bauman (gabrielbauman) wrote :

Here's the syslog.

description: updated
Changed in network-manager:
status: Incomplete → Confirmed
Alexander Sack (asac) wrote :

please open a bug in for this issue as its best dealt there. Please give us the bug id you get there. Thanks!

Changed in network-manager:
importance: Low → Medium
status: Confirmed → Triaged
Alexander Sack (asac) wrote :

also please attach the complete syslog.

Thanks you Hugo. Linking the bug to the package.

Changed in network-manager:
importance: Undecided → Unknown
status: New → Unknown
Changed in network-manager:
status: Unknown → Confirmed
Gabriel Bauman (gabrielbauman) wrote :

Still broken, years later. Lucid is about to be released and this was reported in the Hardy era. The upstream bug appears stalled.

Christoph Langner (chrissss) wrote :

I can confirm that this is still an issue in Lucid. Trying a pptp vpn here.

Do I understand correctly that even though there is a "Connect Automatically" checkbox for VPN connection profiles in network-manager, it simply does not work? And this is known and understood upstream?

As a temporary workaround, until this can be properly addressed upstream (and since we're so close to release), please consider using the script suggested in

On Wed, 2010-04-28 at 12:29 +0000, Mathieu Trudel wrote:
> As a temporary workaround, until this can be properly addressed upstream
> (and since we're so close to release), please consider using the script
> suggested in

Or, given the bugginess of network-manager[1], I can just cast it aside
and configure /etc/network/interfaces and /etc/openvpn/*.

[1] For example, the OpenVPN connection editor wants a key file, a
certificate file and a CA certificate file and it has a file chooser to
select each one, and I do, but by the time it saves those to gconf, they
are completely different names in the same directory. I can't imagine
for the life of me how that got through even the most basic of QA.


I understand your frustration, but we do need your help in identifying such issues, which often vary greatly between users and expectations :)

Have you filed a bug regarding this specific issue you're describing, or did you look for one that was already filed? It would be very helpful if you could either search quickly and add information to a bug that describes *exactly* the issue you're experiencing, or file a new bug so that we can focus on just that issue and/or mark it as duplicate if we later find a master bug. If you have a bug number, please post it here or email me directly with it so we can follow up.


On Wed, 2010-04-28 at 13:26 +0000, Mathieu Trudel wrote:
> Brian,

Hi Mathieu,

> Have you filed a bug regarding this specific issue you're describing,

Nope. I do file bugs but I have not filed this one (yet). TBH, I get
tired of filing bugs only to see problems persist across multiple
releases of Ubuntu Linux. Frequently bugs don't even get acknowledged
(or they get ignored after it becomes clear that it's not a 5 second
fix) and 6-12 months later the first acknowledgement is "hey, the new
release is coming out, is this bug still present in that release?",
which among other things presumes I am willing to upgrade to a

> or
> did you look for one that was already filed?

Again, nope (net yet). TBH, about this particular issue, I don't see
the point. It's clear that NM is quite buggy, that such a basic issue
exists in it. And even if I did find a bug filed about it already, what
would that solve for me? It wouldn't fix the issue I have in Lucid
currently and even if it did, and if there was a fix, through the whole
complicated process it takes to get an update into Ubuntu now, it would
likely not show up for months. I can't wait months. It's just easier
to push a buggy piece of software aside (when you can) and carry on with
things they way they were before the buggy software showed up, like
using /etc/network/interfaces and /etc/openvpn/*.

> It would be very helpful if
> you could either search quickly

I am sorry, but I really don't have the time. I already spend way too
much of my life reading, following and helping with other bugs in so
many other pieces of software that I don't have time to add yet another
one -- one for which I can work-around quite easily.

I'm sorry to be so unhelpful on this, but while it's an annoyance, it
has an easy work-around and I can spend my time working on other things
that don't have such easy work-arounds, or with even spend some time my
family, etc.

Again, sorry to be so unhelpful, but I am already stretched way too

Changed in network-manager:
importance: Unknown → Wishlist

On Thu, 2010-09-16 at 02:46 +0000, Bug Watch Updater wrote:
> ** Changed in: network-manager
> Importance: Unknown => Wishlist

Look, I realize that there is some (likely completely fruitless -- will
changing a bunch of labels actually result in any of the thousands of
bugs filed being fixed? i doubt it) automated task of categorizing all
bugs from Unknown to something else, however this one needs another

The title of this bug is 'NetworkManager does not auto-connect to VPNs
marked "Connect Automatically"'

How do you define a report that something does not do what it says it's
supposed to be doing as a "wishlist"? If something is described to do
something and it doesn't do it it's a bug, not a "wishlist".

elijah (elijah) wrote :

On 09/16/2010 01:14 PM, Brian J. Murrell wrote:

> How do you define a report that something does not do what it says it's
> supposed to be doing as a "wishlist"?

I could not agree more. Current network manager support for VPN is
really half-baked. Considering the increased use of VPNs, this is really
a problem for linux adoption.


Robert Buhren (weelkin) wrote :

Maybe the next update of network-manager remove the "Connect Automatically" checkbox and change the status of this bug back to "wishlist" :)

Hope this gets fixed someday but i guess since this bug is open since 2008, it will not be fixed soon...


Just wanting to confirm the problem. I checked and unchecked the option several times, and already spend considerable time trying, before I came here to see that this is known since Oct 2008.

Having checkboxes in the GUI that do simply not work *IS* annoying, and it *WILL* harm Ubuntu's reputation.

Felix (apoapo) wrote :

Harm reputation is the most correct way to describe it!
Such small showstoppers have to be fixed. Its about the overall feeling using an OS.
And this bug is not a new one..

Reported by Biji on 2008-10-09

There are even programs like vpnautoconnect on SF that try to fix this. So this "bug" has not as low priority than it is treated here...

Felix (apoapo) wrote :

Btw as workaround:

Put this script (for me worked the 1. not modified script):

Into this folder:


centx (centx) wrote :

Just wanted to share the application "vpnautoconnect" as apo mentioned above.

Maybe someone could incorporate the ideas from here into NM's autoconnect or something. I've had this problem for years, and now it seems, that with this rather clunky program, it finally works.

Changed in debian:
status: Unknown → New
Dmitry Savin (envelsavinds) wrote :

Still reproduced. It is not a 'wishlist' because there's a checkbox 'auto reconnect' that actually doesn't work.

On 11-06-23 01:25 PM, Envel wrote:
> Still reproduced. It is not a 'wishlist' because there's a checkbox
> 'auto reconnect' that actually doesn't work.

It actually still is a wishlist item. Just like the zillion other bugs
I "wish" would get fixed. :-)

+1 Bug needs fixing...

James Shackleford (tshack) wrote :


Bug needs fixing or checkbox needs to be removed.

bebugz (bebugz) wrote :

It hits the reputation, I'm installing that to newbies from Windows realm and they told - "Okay this is really great OS, we'll stay here, but... it was so easy to autoconnect to internet from Win, why it is not the case here?"

Felix (apoapo) wrote :

I always wonder if there is any department in the ubuntu team which is dedicated to the "reputation". There are quite a lot of bugs out there that hurt newbies.

This one is easy to fix, even fixed actually as we see in my previous post and the "vpnautoconnect" programm available somewhere. But no one patches the network manager or whatever to do this the easy way for newbies actually. (Wwho added the option to the GUI?? Why ist it still there when there is no code behind it?!)

(Same goes for the nvidia driver for old nvdidia cards. The full release cycle of Natty was without support for my gf's gfx card. How can i tell her that Ubuntu rocks, when flash, video, even desktop laggs?! )

As you said, it hits the reputation. Sometimes i wish i was a skilled programmer. I would surely dedicate my free time to bugs like this one.

Please do not take this as a flame but as my anxiety concerning the welfare of ubuntu.

Felix (apoapo) wrote :

Johannes Storm wrote a very tiny script. Is anyone able to prepare the patch here? I don't know where to start in the sources. NM is much to complicated for me to start helping with patches :(

For the meantime, his script for /etc/NetworkManager/dispatcher.d/:

#! /bin/bash


activ_con=$(nmcli con status | grep "${REQUIRED_CONNECTION_NAME}")
activ_vpn=$(nmcli con status | grep "${VPN_CONNECTION_NAME}")
if [ "${activ_con}" -a ! "${activ_vpn}" ];
    nmcli con up id "${VPN_CONNECTION_NAME}"

Billie Thompson (billiecodes) wrote :

Still broken 3 years later. Could we at least get the checkbox removed?

Martin Maiwald (mm-maiwald) wrote :


I've not been able to help myself running Ubuntu 11.10, I'm a Noob, though...

I've tried to compile the vpnautoconnect solution from sourceforge but even though in- and reinstalling all recquired packages I could not get it to configure because it does not find pcap.h
The python script somehow does nothing for me even though I gave it full rights.

If anybody has had the same problem with pcap.h and has solved it please let me know.


Domen Kožar (ielectric+) wrote :

Following script works with NM 0.9, goals:

    * if VPN connection is not disconnected by user himself, reconnect (configurable max_attempts)
    * on new active network connection, activate VPN

This is still not fixed for 12.04, 4 years this has been open.

Surely within 4 years someone could either fix the bug or at least remove the 'connect automatically' checkbox?

Hugo created a bug report here:

Which I can see has been reported as a dup of: (which this bug is now assigned to), however, this bug is titled ' [enh] automatically reconnect VPN if dropped ' which is not the same as the orginal bug, therefore I don't think it's a duplicate.

We are talking about auto connecting at startup, not reconnecting when the line drops.

If think we're waiting for the wrong bug to be fixed, maybe that's why it has taken so long?

Also at (which this bug is assigned to), Michael Biebl says

"Currently, VPN connection can not be autostarted. So I guess this option should
be greyed out."

... so maybe it can't be fixed?

I'm a novice at ubuntu development so I hope someone more experience can take another look at this



Felix (apoapo) wrote :

Necessary Code is already provided some posts before. I think no related programmer is watching this bug. Ubuntu needs a quality assurance team imo.

100 papercuts could be a project to fix this bug.

@Adam Bruce:
The way I see it - there is no someone should. If no one steps up to the open tasks then that's how it is
and that's how it works with cooperative projects.

It still sucks - yes - and the policy of expiring bugs someone took the time and effort to report is
also demotivating in my opinion - but then again that's how it is done at the moment.

Colan Schwartz (colan) wrote :

To get this moving, it wouldn't hurt to start a bounty for this over at or .

Andreas Wesik (ezel) wrote :

Still a BUG (not wishlist).

On Windows I could leave my computer on over nights running torrents over VPN. If it failed it would reconnect as soon as it could.

If I leave Ubuntu to do this task I will wake up in the morning and it might have uploaded/downloaded 100kb of data during that whole night. Windows got Ubuntu beat by a mile in VPN-handling. How sad.. .

Marius B. Kotsbak (mariusko) wrote :

I didn't think Windows had support for VPN at all. Last time I checked I thought you needed some third party VPN client from e.g. Cisco.

You could try another client in Ubuntu as well, like kvpn. It could have more options for reconnection.

Ansus (neptunia) wrote :

Windows has PPTP VPN support starting from Windows 95.

Marius B. Kotsbak (mariusko) wrote :

PPTP has security issues:

and is primarily used for Windows out of box compatibility. Cisco VPNs is not supported in other modes:

Thomas Hood (jdthood) on 2012-07-24
tags: added: precise

Could someone start by un-assigning this from gnome-bugs #349151, as this is definately not the same bug. And remove the Wishlist tag as this is not a wishlist item.

debbugs #589533 is the correct bug so I'm going to post over there and see if we can get some feedback on this.


Changed in network-manager:
importance: Wishlist → Undecided
status: Confirmed → New
Marius B. Kotsbak (mariusko) wrote :

Done (no special permission needed for that). Could you please report this bug upstream, where it must be fixed:

affects: debian → network-manager (Debian)

This bug is being worked on at so I've linked this report to that one

Changed in network-manager:
importance: Undecided → Unknown
status: New → Unknown

Should 'network-manager (Debian)' and 'network-manager (Ubuntu)' be assigned to that gnome bug report as well? As that is where it will be fixed?

I'm quite new to launchpad and reporting bugs, but I'm learning!

Marius B. Kotsbak (mariusko) wrote :

Nope, it must be done by the Ubuntu and Debian package maintainers by importing a new upstream release after it has been fixed or by backporting the needed patches, so it is fine how it is now.

Changed in network-manager:
importance: Unknown → Wishlist
status: Unknown → Confirmed

I can report that this "bug" is still present in 12.10 Beta. Not sure if "bug" is the right "open sore" might be better. Can't believe this has been open since 2008! Reading the comments has raised a smile at the very least,I feel your pain...

Ansus (neptunia) wrote :

It is easier to switch to openSUSE where you can set up VPN via Yast and it will be up in every session automatically, even in console session and different desktops.

James Cuzella (trinitronx) wrote :

Confirmed still in network-manager-vpnc on Ubuntu 12.04.1 LTS (Precise Pangolin).

Would be really nice if connect automatically checkbox would actually work! I think it's about time someone who knows about this piece, and where to look in order to fix it took it into consideration again ^_^

tags: added: quantal

I tried to get this sorted out over at Gnome.

Basically the short answer is 'Connect Automatically' does not work which is why this is marked as 'wishlist'.

I'll see if we can get the checkbox removed which is the main issue now

Marius B. Kotsbak (mariusko) wrote :

I guess we quite easily could have done a patch to remove the autoconnect box until it is working.

Well the guy at Gnome seems a little hostile to be honest. He said he'd prefer if it was fixed, but I don't see that happening anytime soon as this has been a bug since 2008 and I doubt it will be fixed for Quantal.

If we want it sorted for Quantal, I guess we should just patch it ourselves and remove the checkbox

Strange Fox (kero-05h) wrote :

This really shouldn't be downgraded to wishlist.

Auto-connecting to a VPN is a standard and I dare-say critical feature for many VPN users.

If upstream isn't willing to fix the issue, then the community should take it up. I god, this bug has been around since the Hardy area. That's 9 release cycles ago.

Changed in network-manager:
importance: Wishlist → Undecided
status: Confirmed → New
Nick Leverton (nick-leverton) wrote :

Still broken in Quantal (12.10).

This is not a wishlist, this is a feature supposedly offered by the software - the VPN tab has a "Connect automatically" checkbox and it does not work.

Nick Leverton (nick-leverton) wrote :

Actually I apologise for being snarky yesterday. I've read the full upstream bug now and whilst it is a complex set of needs to make VPNs work in all use cases (mine being relatively simple), it looks like NM with this check box is up to its usual tricks of claiming features that just don't work in even the simplest use case.

This being so, I agree - patch the option out until upstream gets around to fixing it, if ever.

Marius B. Kotsbak (mariusko) wrote :

Someone has messed up the bug link. This bug _has_ actually been fixed upstream and you should expect a fix in the next version of Ubuntu.

Changed in network-manager:
importance: Undecided → Unknown
status: New → Unknown
Marius B. Kotsbak (mariusko) wrote :

You also might be talking about bug #344455.

description: updated
Domen Kožar (ielectric+) wrote :

What is the actual bug link_

Marius B. Kotsbak (mariusko) wrote :

The upstream bug report is found at:

The fix is in a single commit, so it should be possible to backport to Precise LTS.

Ansus (neptunia) wrote :

In the future I suggest people to report bugs directly to Red Hat. Otherwise you may wait for a fix indefinitely cause Canonical has no developers upstream.

Strange Fox (kero-05h) wrote :

So how do we begin the SRU process?

Ansus; it doesn't mean we can't send patches. I can't possibly see every comment of every bug, there's just too many.

This can't be shipped as SRU; it depends on rather intrusive changes to NM and would furthermore need changes to nm-applet (including new strings that would have to be translated) to be useful in any way. It's actually many commits (at least two) with a pretty high chance of introducing regressions.

It's now shipping in ubuntu raring (what will be 13.04) though, so I'm closing this as Fix Released.

Changed in network-manager (Ubuntu):
status: Triaged → Fix Released
Marius B. Kotsbak (mariusko) wrote :

@Ansus, the bug is reported and fixed upstream: If you can reproduce a bug in Fedora, of course you can report it there too and maybe be more likely it is fixed upstream, but reporting it in the upstream bug tracker should be sufficient.

Changed in network-manager (Debian):
status: New → Fix Released
Changed in network-manager:
importance: Unknown → Wishlist
status: Unknown → Fix Released
iGadget (igadget) wrote :

So I understand this bug has been fixed upstream over 5 months ago. Now how long will it take for this fix to trickle down into Precise? Anything I can do to speed it up?

Marius B. Kotsbak (mariusko) wrote :

My best solution is either to wait for the next LTS in some months or use a backport (I'm not sure there is one now that contains the fix).

Minosone (menno-pleijster) wrote :

Please advice: I'm having a bug in Ubuntu Trusty Tahr 14.04 LTS that is very much related to this bug, but it might not be quite the same. So I can either file a new bug report or reopen this one.

The issue I'm having is that although the VPN auto-connects for connections that are marked as such. It only does so when connecting to the particular connection manually. e.g. I select the wireless network in the network-manager.

It however does not auto-connect when wireless is enabled or if the network comes into range. It connects and authenticates fine with the wireless network, but then fails to connect the vpn. It returns the following error in syslog:

<error> [1401130450.367538] [nm-vpn-connection.c:1374] get_secrets_cb(): Failed to request VPN secrets #2: (6) No agents were available for this request.

Should I reopen this bug or file a new one?

Stephan Springer (geryon) wrote :

It is always better to file a new bug if in doubt.

Minosone (menno-pleijster) wrote :

I have filed bug #1323594.

affects: network-manager (Ubuntu) → network-manager-openvpn (Ubuntu)
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.