This is expected, because eth0 is not managed by NetworkManager.  If the device isnt' managed by NM, you obviously can't use NetworkManager-openvpn with that device.  If you haven't let NM manage your eth0, then NM doesn't know the details about eth0's configuration, and can't get events when configuration of eth0 changes, or when eth0's default routes change, or when eth0 goes up or down or DHCP renews and the address changes, etc.  All those details are necesary for the VPN integration, and that means letting NM manage the device that your VPN will use.

Any particular reason why you can't let NM manage your default internet connection?

I don't think it's obvious.  I'm pretty sure openvpn works atop connections managed by ifupdown, after all.

It's not that I *can't* put eth0 under NM control, it's that doing so would create unnecessary (and unwelcome) special cases for administration.  All of the linux boxes at my site use ifupdown.  Our administrators know ifupdown.  Our system config scripts and tools work with ifupdown.  Does NetworkManager even *have* a command line interface?  Even if it does, forcing the people and tools that manage our systems to accommodate NM's way of doing things in addition to the standard way would add unnecessary complexity, and is therefore impractical.  That's why ifupdown and /etc/network/interfaces are not going away any time soon, and why NetworkManger's "unmanaged" mode is necessary.

At the same time, NetworkManager is very practical and convenient for the more dynamic network connections like wireless, USB NICs, and VPNs, which can exist alongside the traditionally managed ones I described above.  When someone is sitting at a machine's console and wants to do some secure remote work, it would be *really* nice to bring up a temporary VPN with a couple of mouse clicks instead of mucking about with man pages to remember how to do it from the command line.  The eth0 routes and addresses aren't going to change on these boxes, and even if they did, we computer users would understand that it might interfere with an established VPN.  Sadly, NetworkManager-openvpn is unable to function atop a network connection that openvpn can use just fine, so it's back to the stone age for the console users.  No nm-vpn love for us.

Would you consider reopening this as an enhancement request instead of a bug?

I'm a fellow NetworkManager sufferer who just spent the last six (6) hours trying to get NetworkManager to start an OpenVPN connection, and I'd like to try to convince Dan that he's not entirely correct about this bug / missing feature.

Despite Dan's statement, I see a fair amount of evidence that NM users DO NOT EXPECT this behavior. It's hard to say for sure, given the ambiguities between "static" and "manual" interface configuration, but I see a decent number of people suffering in dealing with this (or similar) issues. Here are some Launchpad bug reports that might be interesting:

 * https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/145107
 * https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/323904

The Ubuntu docs on setting up VPNs via NM explicitly point out this issue, too.

Why would people be confused about what NM is expected to do? Based on my own experience this evening, the problem is the nm-applet UI. NetworkManager doesn't bother to tell us WHY we can't enable our VPNs. It gives almost zero desktop-interactive feedback, just "graying out" the VPN connections, and there's nothing whatsoever in the logs. I saw a cryptic, nonspecific Dbus error, and that it. Pretty frustrating, really.

Maybe call it a UI bug, then, instead of a "broken feature" bug. At the very least, we could save people some time and frustration. But for the record, there are still plenty of situations where I can't let NM manage my interfaces, mostly due to missing features. I run into at least one of these situations in a working week:

 * Bridged interfaces:  Lately, because Libvirt/KVM and virtual bridges are getting so much more common, this is becoming more of a problem.
 * Tagged VLAN ports:  Also a big Libvirt/KVM hangup.
 * Bonded interfaces.
 * Large numbers of IP aliases:  NM lets me alias multiple IPs, one-by-one, but that won't fly for dozens or 100s of IPs.
 * Mixed static/DHCP IP setups:  NM can handle DHCP addressing w/ static route and DNS, but not the reverse, nor static route with DNS from DHCP, etc. It also can't mix DHCP and static addresses.
 * Custom routing policies ("ip rule ...").
 * Nonstandard (multiple) routing tables ("ip route ... table XYZ").

Some of this stuff is exotic, but less so than you might think. As Linux gets more popular, the Deep End of the Networking Swimming Pool gets more and more crowded. People actually want to use these capabilities on a daily basis, on desktop machines and laptops, and they'd like to get NetworkManager in the mix where possible.

I know that developer time is a limited resource, so don't take this as a complaint about the missing bits. My gripe, here, is that NetworkManager won't cooperate nicely with anything it doesn't support. It seems so arbitrary that NM can't just call 'ip addr' and 'ip route' to get the unmanaged interface parameters, so it can start OpenVPN.