*** Bug 1019949 has been marked as a duplicate of this bug. ***

*** Bug 1013200 has been marked as a duplicate of this bug. ***

*** Bug 1016829 has been marked as a duplicate of this bug. ***

I get much the same as the above the above, and definitely have:

NetworkManager[8973]: <error> [1383175785.850234] [platform/nm-linux-platform.c:1109] add_object(): Netlink error: Unspecific failure
NetworkManager[8973]: <warn> VPN connection '********' did not receive valid IP config information.

in common.

Worked fine in F19, only just upgraded to F20 and now it fails.

openvpn-2.3.2-4.fc20.x86_64
NetworkManager-openvpn-0.9.8.2-3.fc20.x86_64
NetworkManager-openvpn-gnome-0.9.8.2-3.fc20.x86_64

It would seem from the code snippet below that add_kernel_object returns neither -NLE_SUCCESS nor -NLE_EXIST

   -------------------------------------

"/usr/src/debug/NetworkManager-0.9.9.0/src/platform/nm-linux-platform.c" line 1092

add_object (NMPlatform *platform, struct nl_object *obj)
{
        auto_nl_object struct nl_object *object = obj;
        NMLinuxPlatformPrivate *priv = NM_LINUX_PLATFORM_GET_PRIVATE (platform);
        int nle;

        nle = add_kernel_object (priv->nlh, object);

        /* NLE_EXIST is considered equivalent to success to avoid race conditions. You
         * never know when something sends an identical object just before
         * NetworkManager.
         */
        switch (nle) {
        case -NLE_SUCCESS:
        case -NLE_EXIST:
                break;
        default:
                error ("Netlink error: %s", nl_geterror (nle));
                return FALSE;
        }

btw. l2tp seems to be affected by a similar issue here.

Specifically it is failing adding a route, but I can't parse the priv->nlh and object data types to tell which one.

(gdb) bt
#0  add_object (platform=platform@entry=0x7fae092dd890, obj=0x7fae09387960) at platform/nm-linux-platform.c:1109
#1  0x00007fae08d49737 in ip4_route_add (platform=0x7fae092dd890, ifindex=<optimized out>, network=10, plen=<optimized out>, gateway=151063306, 
    metric=<optimized out>, mss=0) at platform/nm-linux-platform.c:2352
#2  0x00007fae08d4ed6f in nm_platform_ip4_route_add (ifindex=ifindex@entry=14, network=10, plen=23, gateway=151063306, metric=1024, mss=0)
    at platform/nm-platform.c:1368
#3  0x00007fae08d4f3ff in nm_platform_ip4_route_sync (ifindex=ifindex@entry=14, known_routes=known_routes@entry=0x7fae0931c6a0) at platform/nm-platform.c:1507
#4  0x00007fae08d6a68c in nm_ip4_config_commit (config=0x7fae09394080, ifindex=14, priority=priority@entry=0) at nm-ip4-config.c:185
#5  0x00007fae08db8f7e in nm_vpn_connection_apply_config (connection=0x7fae0939f190) at vpn-manager/nm-vpn-connection.c:659
#6  nm_vpn_connection_config_maybe_complete (connection=connection@entry=0x7fae0939f190, success=success@entry=1) at vpn-manager/nm-vpn-connection.c:710
#7  0x00007fae08dba574 in nm_vpn_connection_ip4_config_get (proxy=<optimized out>, config_hash=<optimized out>, user_data=<optimized out>)
    at vpn-manager/nm-vpn-connection.c:965

hope that helps.

Can people check their log output and report whether the "point-to-point" address shown here:

Internal Point-to-Point Address: 10.***.***.***

is the "next hop" address in any of the static routes pushed to your client here:

Oct 10 13:40:14 x230 NetworkManager[533]: <info> Static Route: 10.***.***.***/16 Next Hop: 10.***.***.***

Thanks!

Not for me.

Nov  8 22:26:41 pacas NetworkManager[3544]: <info>   Internal Point-to-Point Address: 10.11.1.9
Nov  8 22:26:41 pacas NetworkManager[3544]: <info>   Static Route: 10.0.0.0/23   Next Hop: 10.0.0.0
Nov  8 22:26:41 pacas NetworkManager[3544]: <info>   Static Route: 10.10.0.0/16   Next Hop: 10.10.0.0
Nov  8 22:26:41 pacas NetworkManager[3544]: <info>   Static Route: 4.*.*.*/27   Next Hop: 4.*.*.*
Nov  8 22:26:41 pacas NetworkManager[3544]: <info>   Static Route: 65.*.*.*/27   Next Hop: 65.*.*.*
Nov  8 22:26:41 pacas NetworkManager[3544]: <info>   Static Route: 173.*.*.*/28   Next Hop: 173.*.*.*
Nov  8 22:26:41 pacas NetworkManager[3544]: <info>   Static Route: 10.11.1.1/32   Next Hop: 10.11.1.1

But none of those next hops except the last would seem to be able to be applied directly.  Those are next hops from the OpenVPN server.

not the case here either.

Created attachment 822683 [details]
/var/log/messages for failing NM and output of openvpn

It don't think it has been reported on this report, but it works (for me) when running openvpn directly. The output of both (with some search'n'replace applied) is attached - comparing them might tell you something.

Nov 15 07:39:49 towerdoom NetworkManager[542]: <info>   Internal Gateway: 10.150.1.5
Nov 15 07:39:49 towerdoom NetworkManager[542]: <info>   Internal Address: 10.150.1.6
Nov 15 07:39:49 towerdoom NetworkManager[542]: <info>   Internal Prefix: 32
Nov 15 07:39:49 towerdoom NetworkManager[542]: <info>   Internal Point-to-Point Address: 10.150.1.5
Nov 15 07:39:49 towerdoom NetworkManager[542]: <info>   Maximum Segment Size (MSS): 0
Nov 15 07:39:49 towerdoom NetworkManager[542]: <info>   Static Route: 10.150.1.1/32   Next Hop: 10.150.1.1
Nov 15 07:39:49 towerdoom NetworkManager[542]: <info>   Forbid Default Route: no
Nov 15 07:39:49 towerdoom NetworkManager[542]: <info>   Internal DNS: 209.222.18.222
Nov 15 07:39:49 towerdoom NetworkManager[542]: <info>   Internal DNS: 209.222.18.218
Nov 15 07:39:49 towerdoom NetworkManager[542]: <info>   DNS Domain: '(none)'
Nov 15 07:39:49 towerdoom nm-openvpn[8707]: Initialization Sequence Completed
Nov 15 07:39:49 towerdoom NetworkManager[542]: <info> No IPv6 configuration
Nov 15 07:39:49 towerdoom NetworkManager[542]: <info> (tun0): link connected
Nov 15 07:39:49 towerdoom NetworkManager[542]: <error> [1384519189.328437] [platform/nm-linux-platform.c:1109] add_object(): Netlink error: Unspecific failure
Nov 15 07:39:49 towerdoom NetworkManager[542]: <warn> VPN connection 'Jersey' did not receive valid IP config information.
Nov 15 07:39:49 towerdoom NetworkManager[542]: ** Message: Terminated openvpn daemon with PID 8707.
Nov 15 07:39:49 towerdoom avahi-daemon[403]: Withdrawing workstation service for tun0.
Nov 15 07:39:49 towerdoom NetworkManager[542]: refresh_object: assertion 'kernel_object' failed
Nov 15 07:39:49 towerdoom NetworkManager[542]: <error> [1384519189.334723] [platform/nm-linux-platform.c:1142] delete_object(): Netlink error: No such device
Nov 15 07:39:49 towerdoom nm-openvpn[8707]: SIGTERM[hard,] received, process exiting

I'm reluctant to speculate on whether my issue here is the same as the others, but as I see a trend of other issues being closed as a duplicate of this, I'm going to post my information here.  I upgrade to F20 a couple of weeks ago, and my VPN was working fine until yesterday.  The thing that changed on my system was that I was now running a virtual machine on the system.  Rebooting the system and retrying the VPn connection with no virtual machine running worked for me.  The difference in the connection log was that the successful started with this:

NetworkManager[872]: <info> (tun0): carrier is OFF
NetworkManager[872]: <info> (tun0): new Tun device (driver: 'unknown' ifindex: 25)
NetworkManager[872]: <info> (tun0): exported as /org/freedesktop/NetworkManager/Devices/23
NetworkManager[872]: <info> (tun0): No existing connection detected.
NetworkManager[872]: <info> VPN connection '***' (IP4 Config Get) reply received from old-style plugin.

whereas the failed connection started with:

NetworkManager[872]: <info> (tun0): carrier is OFF
NetworkManager[872]: <info> (tun0): carrier is OFF
NetworkManager[872]: <info> VPN connection '***' (IP4 Config Get) reply received from old-style plugin.

After that, the logs are the same until the successful one logs:

NetworkManager[872]: <info> (tun0): link connected

While the failed attempt logs:

NetworkManager[872]: <error> [1384477403.525529] [platform/nm-linux-platform.c:1441] link_change(): Netlink error: No such device
NetworkManager[872]: <error> [1384477403.525581] [platform/nm-linux-platform.c:1142] delete_object(): Netlink error: No such device
NetworkManager[872]: <error> [1384477296.219346] [platform/nm-linux-platform.c:1109] add_object(): Netlink error: No such device
NetworkManager[872]: <error> [1384477296.219944] [platform/nm-linux-platform.c:1109] add_object(): Netlink error: No such device
NetworkManager[872]: <warn> VPN connection '***' did not receive valid IP config information.

Is it possible that connecting VMs to the virtual bridge device could somehow be conflicting with NM's tun device setup for VPN?

I have the same problem, but not VM related. I do have IPv6 disabled though.

Same here. Manually starting openvpn from command line works.
Imported config in NM fails.

nm-openvpn[20687]: Initialization Sequence Completed
NetworkManager[868]: <info>   DNS Domain: '(none)'
NetworkManager[868]: <info> No IPv6 configuration
NetworkManager[868]: <info> (tun0): link connected
Netlink error: Unspecific failure
NetworkManager[868]: <warn> VPN connection 'home' did not receive valid IP config information.
NetworkManager: inet 172.30.42.0/24 table main
NetworkManager: priority 0x400
NetworkManager: nexthop via 172.30.42.197 dev 11
NetworkManager: ** Message: Terminated openvpn daemon with PID 20687.

https://admin.fedoraproject.org/updates/NetworkManager-0.9.9.0-18.git20131003.fc20 contains a fix to a bug in the VPN info logging; it does not fix the "can't connect" bug, but it may make it easier for us to debug it

Created attachment 825797 [details]
Journal logs from connection attempt using NetworkManager-openvpn

The attachment I just added was the output of the system journal from my connection attempt, while using the latest NetworkManager build posted in comment 17 by Dan Winship.

I hope that helps with the debugging.

*** Bug 1032265 has been marked as a duplicate of this bug. ***

The same problem occurs in a PPTP VPN set up via NetworkManager.

I'm surprised that this is not a blocker bug. I can connect to VPN using openvpn fine but NetworkManager continues to fail and gives no real clear indication of why. When a connection is made with openvpn tun0 device gets an ifindex when attempting to connect with nm-plasma I see failed to get device ifindex, invalid IPconfiguration...

marked it as a blocker using the info outlined in https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process

I think there are several of us here who can't use F20 properly until it is fixed.

Please consider this bug as an Fedora 20 Final release blocker under the following criteria:

https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria#Default_panel_functionality

"I'm surprised that this is not a blocker bug."

No one had nominated it, and it's not particularly clear-cut. Last time I checked, I could connect to the RH VPN just fine using NM+OpenVPN, and this system is a VM host. It's pretty hard to decide whether the bug should be a blocker without a clear understanding of what's going on and how many people it's likely to affect.

Adam: does the RH OpenVPN support IPv6?  In all the cases I've seen of this so far the server OpenVPN server does not support IPv6.  From what I can tell from reading about the patches for this (elsewhere) it appears to be down to a problem setting up IPv6 even if you have IPv6 disabled in the OpenVPN config.

I've no idea, but that would be useful information if confirmed. Do other reporters confirm their servers don't support IPv6? Dans, does the IPv6 thing sound like a plausible candidate for the trigger?

I have this problem on a server with IPv4 support only (no IPv6).

I can't check now, but as per comment 15, I have ipv6 disabled.

I have a growing population of Fedora based laptops and they need OpenVPN so I will have to stick at F19 until this is fixed.

I can also confirm that IPv6 is disabled.

I have this problem with multiple IPv4 only servers. Enabling/disabling IPv6 via sysctl or Network Manager does not make a difference.

My server is ipv4 only,too.

Affects me as well, Please consider this as a final blocker.

I'd like to sum up the comments. The problem is not related to IPv6 nor to a virtual machine.

The issue is that NM fails to add a static route received from VPN server (or manually configured) on some circumstances. The error is indicated by "add_object(): Netlink error: Unspecific failure". NM builds with release >= 18 logs the problematic route entry.

The "Unspecified failure" most probably is ENETUNREACH errno here. It means that a route cannot be added due to bad (unreachable gateway (next hop).
#define ENETUNREACH     101     /* Network is unreachable */
Unfortunately libnl doesn't help us much, because it translates errno to its own code and returns  "Unspecific failure" for errors it doesn't recognize:
recvmsgs():
http://git.infradead.org/users/tgr/libnl.git/blob/HEAD:/lib/nl.c#l894
nl_syserr2nlerr():
http://git.infradead.org/users/tgr/libnl.git/blob/HEAD:/lib/error.c#l84

Nonetheless, it seems to me that affected are only setups where VPN returns prefix of 32
 <info>   Internal Gateway: 10.2.3.89
 <info>   Internal Address: 10.2.3.90
 <info>   Internal Prefix: 32          <====
as opposed to (a working setup) e.g.
 <info>   Internal Gateway: 10.3.113.1
 <info>   Internal Address: 10.3.113.91
 <info>   Internal Prefix: 24

NM first adds the Internal Address to the (tun0) interface. If Prefix is < 32, libnl automatically installs a route to the network. However for prefix=32, the route is not automatically installed. And later, when adding static routes, "Network is unreachable" is returned and the VPN connection fails.
So, I think NM should fix the prefix=32 case.

(
Try (replace eth5 with an interface on your machine):
# ip addr add 10.3.113.91/24 dev eth5
# ip route
...
10.3.113.0/24 dev eth5  proto kernel  scope link  src 10.3.113.91
...

and

# ip addr add 10.2.3.90/32 dev eth5 peer 10.2.3.89
# ip route
...
10.2.3.89 dev eth5  proto kernel  scope link  src 10.2.3.90
...
)

Excerpts from logs:
From comment 12:
----------------
Nov 12 00:45:09 localhost NetworkManager[588]: <info> IPv4 configuration:
Nov 12 00:45:09 localhost NetworkManager[588]: <info>   Internal Gateway: 10.2.3.89
Nov 12 00:45:09 localhost NetworkManager[588]: <info>   Internal Address: 10.2.3.90
Nov 12 00:45:09 localhost NetworkManager[588]: <info>   Internal Prefix: 32
Nov 12 00:45:09 localhost NetworkManager[588]: <info>   Internal Point-to-Point Address: 10.2.3.89
Nov 12 00:45:09 localhost NetworkManager[588]: <info>   Maximum Segment Size (MSS): 0
Nov 12 00:45:09 localhost NetworkManager[588]: <info>   Static Route: 1.1.1.1/32   Next Hop: 1.1.1.1
Nov 12 00:45:09 localhost NetworkManager[588]: <info>   Static Route: 2.2.2.2/32   Next Hop: 2.2.2.2
Nov 12 00:45:09 localhost NetworkManager[588]: <info>   Static Route: 3.3.3.3/32   Next Hop: 3.3.3.3
Nov 12 00:45:09 localhost NetworkManager[588]: <info>   Static Route: 10.1.1.0/24   Next Hop: 10.1.1.0
Nov 12 00:45:09 localhost NetworkManager[588]: <info>   Static Route: 10.37.1.0/24   Next Hop: 10.37.1.0
...
Here, Next Hops seem wrong. Have they been edited?

running openvpn manually:
Tue Nov 12 00:45:42 2013 /usr/sbin/ip addr add dev tun0 local 10.2.3.90 peer 10.2.3.89
Tue Nov 12 00:45:44 2013 /usr/sbin/ip route add 1.1.1.1/32 via 10.2.3.89
Tue Nov 12 00:45:44 2013 /usr/sbin/ip route add 2.2.2.2/32 via 10.2.3.89
Tue Nov 12 00:45:44 2013 /usr/sbin/ip route add 3.3.3.3/32 via 10.2.3.89
Tue Nov 12 00:45:44 2013 /usr/sbin/ip route add 10.1.1.0/24 via 10.2.3.89
Tue Nov 12 00:45:44 2013 /usr/sbin/ip route add 10.37.1.0/24 via 10.2.3.89
...


From comment 13:
----------------
Nov 15 07:39:49 towerdoom NetworkManager[542]: <info>   Internal Gateway: 10.150.1.5
Nov 15 07:39:49 towerdoom NetworkManager[542]: <info>   Internal Address: 10.150.1.6
Nov 15 07:39:49 towerdoom NetworkManager[542]: <info>   Internal Prefix: 32
Nov 15 07:39:49 towerdoom NetworkManager[542]: <info>   Internal Point-to-Point Address: 10.150.1.5
Nov 15 07:39:49 towerdoom NetworkManager[542]: <info>   Maximum Segment Size (MSS): 0
Nov 15 07:39:49 towerdoom NetworkManager[542]: <info>   Static Route: 10.150.1.1/32   Next Hop: 10.150.1.1
...

From comment 18:
----------------
Nov 18 14:11:23 localhost.localdomain NetworkManager[10879]: <info>   Internal Gateway: 10.50.11.141
Nov 18 14:11:23 localhost.localdomain NetworkManager[10879]: <info>   Internal Address: 10.50.11.142
Nov 18 14:11:23 localhost.localdomain NetworkManager[10879]: <info>   Internal Prefix: 32
Nov 18 14:11:23 localhost.localdomain NetworkManager[10879]: <info>   Internal Point-to-Point Address: 10.50.11.141
Nov 18 14:11:23 localhost.localdomain NetworkManager[10879]: <info>   Maximum Segment Size (MSS): 0
Nov 18 14:11:23 localhost.localdomain NetworkManager[10879]: <info>   Static Route: 10.0.96.0/20   Next Hop: 10.50.11.141
Nov 18 14:11:23 localhost.localdomain NetworkManager[10879]: <info>   Static Route: 10.0.80.0/20   Next Hop: 10.50.11.141
...

Nov 18 14:11:23 localhost.localdomain NetworkManager[10879]: <error> [1384801883.843491] [platform/nm-linux-platform.c:1116] add_object(): Netlink error: Unspecific failure
Nov 18 14:11:23 localhost.localdomain NetworkManager[10879]: inet 10.0.96.0/20 table main
Nov 18 14:11:23 localhost.localdomain NetworkManager[10879]: priority 0x400
Nov 18 14:11:23 localhost.localdomain NetworkManager[10879]: nexthop via 10.50.11.141 dev 9
Nov 18 14:11:23 localhost.localdomain NetworkManager[10879]: <warn> VPN connection 'Example' did not receive valid IP config information.
...

Oh, actually I was just looking at this too. The problem is that the broken configs all use point-to-point addressing, while the working ones (like RH's) don't. And NMPlatform doesn't implement ptp (presumably accidentally).

(In reply to Dan Winship from comment #35)
> Oh, actually I was just looking at this too. The problem is that the broken
> configs all use point-to-point addressing, while the working ones (like
> RH's) don't. And NMPlatform doesn't implement ptp (presumably accidentally).

So from this it would seem that the current released version never was going to support OpenVPN and PPTP. Might be a plan to include these two on the list of things to test before release.

(In reply to Andrew Meredith from comment #36)
> (In reply to Dan Winship from comment #35)
> > Oh, actually I was just looking at this too. The problem is that the broken
> > configs all use point-to-point addressing, while the working ones (like
> > RH's) don't. And NMPlatform doesn't implement ptp (presumably accidentally).
> 
> So from this it would seem that the current released version never was going
> to support OpenVPN and PPTP. Might be a plan to include these two on the
> list of things to test before release.

Many OpenVPN configurations use the "subnet" topology, so it's inaccurate to say "never going to support OpenVPN".  Whether PPTP was broken or not also depends on what address it returns for the remote side via IPCP.

But yes, OpenVPN's "p2p" topology should be added to a testing list to ensure this doesn't happen again.

please try the test packages at http://koji.fedoraproject.org/koji/taskinfo?taskID=6247978 (i686 is done now, x86_64 should finish shortly).

I don't have a p2p OpenVPN setup, so it's untested (other than making sure that it doesn't break anything else).

(In reply to Dan Williams from comment #37)
> Many OpenVPN configurations use the "subnet" topology, so it's inaccurate to
> say "never going to support OpenVPN".  Whether PPTP was broken or not also
> depends on what address it returns for the remote side via IPCP.
> 
> But yes, OpenVPN's "p2p" topology should be added to a testing list to
> ensure this doesn't happen again.

Am I right in thinking that most workstation/laptop dial-in configurations will be point-to-point rather that network-to-network. Certainly we didn't do anything apparently unusual in setting up the OpenVPN layout concerned. Just the usual FAQ fodder.

Dan: installed it (x86_64), restarted NetworkManager.  OpenVPN connection now working great :)

It is working for me as well. 
"Automatically connect to this network when available" is always checked and not editable in connection editor.

OK, dcbw or someone, can you review danw/ptp-address?

(In reply to Dan Winship from comment #38)
> please try the test packages at
> http://koji.fedoraproject.org/koji/taskinfo?taskID=6247978 (i686 is done
> now, x86_64 should finish shortly).

works fine here with multiple ipv4 openvpn servers.

Discussed at 2013-12-02 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-12-02/f20-blocker-review-%234.2013-12-02-17.02.log.txt . Rejected as a blocker as it doesn't directly violate any criteria, and in most cases could be acceptably fixed with an update. It's expected that people who require VPN access in order to get any network access at all are not a huge subset, and would be able to work around the issue (perhaps by connecting with openvpn directly).

Accepted as a freeze exception issue, though, as it is obviously affecting quite a few people and it would be much nicer if we can fix it for final and avoid a bad experience for people who hit this. Dans, it would help a lot if we can have an update for this in Bodhi today, or at worst tomorrow. thanks!

Dans: in case you're unaware of the process, 'accepted freeze exception' means this fix can go through the freeze into F20 final, and indeed we'd very much like to take it. TC4 will be built today, so if we could get an update with the fix submitted to Bodhi soon, that'd be great and we could include it in TC4. Thanks!

I can confirm the updated package fixes the issue for me as well.

I have installed the test packages from Koji:

# rpm -qa "NetworkManager*" | grep "0\.9\.9" | sort
NetworkManager-0.9.9.0-20.git20131003.fc20.x86_64
NetworkManager-config-server-0.9.9.0-20.git20131003.fc20.x86_64
NetworkManager-debuginfo-0.9.9.0-20.git20131003.fc20.x86_64
NetworkManager-devel-0.9.9.0-20.git20131003.fc20.x86_64
NetworkManager-glib-0.9.9.0-20.git20131003.fc20.i686
NetworkManager-glib-0.9.9.0-20.git20131003.fc20.x86_64
NetworkManager-glib-devel-0.9.9.0-20.git20131003.fc20.x86_64

My PPTP VPN still fails.

dec 03 10:17:27 localhost.localdomain pppd[2426]: PAP authentication succeeded
dec 03 10:17:27 localhost.localdomain NetworkManager[691]: PAP authentication succeeded
dec 03 10:17:27 localhost.localdomain NetworkManager[691]: ** Message: nm-pptp-ppp-plugin: (nm_phasechange): status 8 / phase 'network'
dec 03 10:17:27 localhost.localdomain pppd[2426]: local  IP address 172.16.x.y
dec 03 10:17:27 localhost.localdomain pppd[2426]: remote IP address 192.168.100.2
dec 03 10:17:27 localhost.localdomain pppd[2426]: primary   DNS address a.b.c.d
dec 03 10:17:27 localhost.localdomain pppd[2426]: secondary DNS address 192.168.5.1
dec 03 10:17:27 localhost.localdomain NetworkManager[691]: <info> VPN connection 'MYVPN' (IP4 Config Get) reply received from old-style plugin.
dec 03 10:17:27 localhost.localdomain NetworkManager[691]: <info> VPN Gateway: e.f.g.h
dec 03 10:17:27 localhost.localdomain NetworkManager[691]: <info> Tunnel Device: ppp0
dec 03 10:17:27 localhost.localdomain NetworkManager[691]: <info> IPv4 configuration:
dec 03 10:17:27 localhost.localdomain NetworkManager[691]: <info>   Internal Address: 172.16.x.y
dec 03 10:17:27 localhost.localdomain NetworkManager[691]: <info>   Internal Prefix: 32
dec 03 10:17:27 localhost.localdomain NetworkManager[691]: <info>   Internal Point-to-Point Address: 192.168.100.2
dec 03 10:17:27 localhost.localdomain NetworkManager[691]: <info>   Maximum Segment Size (MSS): 0
dec 03 10:17:27 localhost.localdomain NetworkManager[691]: <info>   Static Route: 192.168.5.0/24   Next Hop: 192.168.7.1
dec 03 10:17:27 localhost.localdomain NetworkManager[691]: <info>   Static Route: 192.168.3.0/24   Next Hop: 192.168.7.1
dec 03 10:17:27 localhost.localdomain NetworkManager[691]: <info>   Static Route: 172.16.0.0/16   Next Hop: 195.168.7.1
dec 03 10:17:27 localhost.localdomain NetworkManager[691]: <info>   Static Route: 192.168.6.0/24   Next Hop: 192.168.7.1
dec 03 10:17:27 localhost.localdomain NetworkManager[691]: <info>   Forbid Default Route: yes
dec 03 10:17:27 localhost.localdomain NetworkManager[691]: <info>   Internal DNS: 192.168.5.1
dec 03 10:17:27 localhost.localdomain NetworkManager[691]: <info>   DNS Domain: '(none)'
dec 03 10:17:27 localhost.localdomain NetworkManager[691]: <info> No IPv6 configuration
dec 03 10:17:27 localhost.localdomain NetworkManager[691]: <error> [1386062247.818226] [platform/nm-linux-platform.c:1127] add_object(): Netlink error: Unspecific failure
dec 03 10:17:27 localhost.localdomain NetworkManager[691]: <warn> VPN connection 'MYVPN' did not receive valid IP config information.
dec 03 10:17:27 localhost.localdomain pppd[2426]: Terminating on signal 15
dec 03 10:17:27 localhost.localdomain pppd[2426]: Modem hangup
dec 03 10:17:27 localhost.localdomain pppd[2426]: Connect time 0.0 minutes.
dec 03 10:17:27 localhost.localdomain pptp[2435]: nm-pptp-service-2422 log[callmgr_main:pptp_callmgr.c:245]: Closing connection (unhandled)
dec 03 10:17:27 localhost.localdomain pppd[2426]: Sent 0 bytes, received 0 bytes.
dec 03 10:17:27 localhost.localdomain dbus[693]: [system] Rejected send message, 2 matched rules; type="error", sender=":1.82" (uid=0 pid=2422 comm="/usr/libexec/nm-pptp...
dec 03 10:17:27 localhost.localdomain pptp[2435]: nm-pptp-service-2422 log[ctrlp_rep:pptp_ctrl.c:258]: Sent control packet type is 12 'Call-Clear-Request'
dec 03 10:17:27 localhost.localdomain pptp[2435]: nm-pptp-service-2422 log[call_callback:pptp_callmgr.c:84]: Closing connection (call state)
dec 03 10:17:27 localhost.localdomain pppd[2426]: Connection terminated.
dec 03 10:17:27 localhost.localdomain NetworkManager[691]: local  IP address 172.16.x.y
dec 03 10:17:27 localhost.localdomain NetworkManager[691]: remote IP address 192.168.100.2
dec 03 10:17:27 localhost.localdomain NetworkManager[691]: primary   DNS address a.b.c.d
dec 03 10:17:27 localhost.localdomain NetworkManager[691]: secondary DNS address 192.168.5.1
dec 03 10:17:27 localhost.localdomain NetworkManager[691]: ** Message: nm-pptp-ppp-plugin: (nm_phasechange): status 9 / phase 'running'
dec 03 10:17:27 localhost.localdomain NetworkManager[691]: ** Message: nm-pptp-ppp-plugin: (nm_ip_up): ip-up event
dec 03 10:17:27 localhost.localdomain NetworkManager[691]: ** Message: nm-pptp-ppp-plugin: (nm_ip_up): sending Ip4Config to NetworkManager-pptp...
dec 03 10:17:27 localhost.localdomain dbus-daemon[693]: dbus[693]: [system] Rejected send message, 2 matched rules; type="error", sender=":1.82" (uid=0 pid=2422 comm="/u...
dec 03 10:17:27 localhost.localdomain NetworkManager[691]: ** Message: PPTP service (IP Config Get) reply received.
dec 03 10:17:27 localhost.localdomain NetworkManager[691]: inet 192.168.5.0/24 table main
dec 03 10:17:27 localhost.localdomain NetworkManager[691]: priority 0x400
dec 03 10:17:27 localhost.localdomain NetworkManager[691]: nexthop via 192.168.7.1 dev 7
dec 03 10:17:27 localhost.localdomain NetworkManager[691]: ** Message: Terminated ppp daemon with PID 2426.
dec 03 10:17:27 localhost.localdomain NetworkManager[691]: Terminating on signal 15
dec 03 10:17:27 localhost.localdomain NetworkManager[691]: Modem hangup
dec 03 10:17:27 localhost.localdomain NetworkManager[691]: ** Message: nm-pptp-ppp-plugin: (nm_phasechange): status 8 / phase 'network'
dec 03 10:17:27 localhost.localdomain NetworkManager[691]: Connect time 0.0 minutes.
dec 03 10:17:27 localhost.localdomain NetworkManager[691]: Sent 0 bytes, received 0 bytes.
dec 03 10:17:27 localhost.localdomain NetworkManager[691]: ** Message: nm-pptp-ppp-plugin: (nm_phasechange): status 5 / phase 'establish'
dec 03 10:17:27 localhost.localdomain NetworkManager[691]: ** Message: nm-pptp-ppp-plugin: (nm_phasechange): status 11 / phase 'disconnect'
dec 03 10:17:27 localhost.localdomain NetworkManager[691]: Connection terminated.
dec 03 10:17:27 localhost.localdomain avahi-daemon[664]: Withdrawing workstation service for ppp0.
dec 03 10:17:27 localhost.localdomain dbus[693]: [system] Rejected send message, 2 matched rules; type="error", sender=":1.82" (uid=0 pid=2422 comm="/usr/libexec/nm-pptp...
dec 03 10:17:27 localhost.localdomain dbus[693]: [system] Rejected send message, 2 matched rules; type="error", sender=":1.82" (uid=0 pid=2422 comm="/usr/libexec/nm-pptp...
dec 03 10:17:27 localhost.localdomain dbus-daemon[693]: dbus[693]: [system] Rejected send message, 2 matched rules; type="error", sender=":1.82" (uid=0 pid=2422 comm="/u...
dec 03 10:17:27 localhost.localdomain dbus-daemon[693]: dbus[693]: [system] Rejected send message, 2 matched rules; type="error", sender=":1.82" (uid=0 pid=2422 comm="/u...
dec 03 10:17:27 localhost.localdomain NetworkManager[691]: ** Message: nm-pptp-ppp-plugin: (nm_phasechange): status 1 / phase 'dead'
dec 03 10:17:27 localhost.localdomain dbus-daemon[693]: dbus[693]: [system] Rejected send message, 2 matched rules; type="error", sender=":1.82" (uid=0 pid=2422 comm="/u...
dec 03 10:17:27 localhost.localdomain dbus[693]: [system] Rejected send message, 2 matched rules; type="error", sender=":1.82" (uid=0 pid=2422 comm="/usr/libexec/nm-pptp...
dec 03 10:17:27 localhost.localdomain NetworkManager[691]: ** Message: nm-pptp-ppp-plugin: (nm_exit_notify): cleaning up
dec 03 10:17:27 localhost.localdomain pppd[2426]: Exit.
dec 03 10:17:27 localhost.localdomain NetworkManager[691]: ** (nm-pptp-service:2422): WARNING **: pppd exited with error code 16
dec 03 10:17:33 localhost.localdomain NetworkManager[691]: <info> VPN service 'pptp' disappeared

Before anyone asks: I have rebooted after installing the test packages to ensure I get a clear situation.

NetworkManager-0.9.9.0-20.git20131003.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/NetworkManager-0.9.9.0-20.git20131003.fc20

This note is to confirm that NetworkManager-0.9.9.0-20.git20131003.fc20 worked for me.

(In reply to Zoltan Boszormenyi from comment #47)
> My PPTP VPN still fails.

I think this must be a separate bug then; PPTP works for me, even with the unfixed NM package. (Although it also uses point-to-point addressing, the PPP code does something slightly different from what OpenVPN does, so it wasn't broken before.)

I seem to still have this problem with the most recent nm packages installed:

Dec 03 15:40:28 rincewind NetworkManager[396]: <info> Starting VPN service 'openvpn'...
Dec 03 15:40:28 rincewind NetworkManager[396]: <info> VPN service 'openvpn' started (org.freedesktop.NetworkManager.openvpn), PID 9338
Dec 03 15:40:28 rincewind NetworkManager[396]: <info> VPN service 'openvpn' appeared; activating connections
Dec 03 15:40:31 rincewind NetworkManager[396]: <info> VPN plugin state changed: starting (3)
Dec 03 15:40:31 rincewind nm-openvpn[9346]: OpenVPN 2.3.2 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Sep 12 2013
Dec 03 15:40:31 rincewind NetworkManager[396]: ** Message: openvpn started with pid 9346
Dec 03 15:40:31 rincewind NetworkManager[396]: <info> VPN connection 'VPN 1' (Connect) reply received.
Dec 03 15:40:31 rincewind nm-openvpn[9346]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Dec 03 15:40:31 rincewind nm-openvpn[9346]: Attempting to establish TCP connection with [AF_INET]172.17.5.1:443 [nonblock]
Dec 03 15:40:32 rincewind nm-openvpn[9346]: TCP connection established with [AF_INET]172.17.5.1:443
Dec 03 15:40:32 rincewind nm-openvpn[9346]: TCPv4_CLIENT link local: [undef]
Dec 03 15:40:32 rincewind nm-openvpn[9346]: TCPv4_CLIENT link remote: [AF_INET]172.17.5.1:443
Dec 03 15:40:33 rincewind nm-openvpn[9346]: WARNING: 'dev-type' is used inconsistently, local='dev-type tun', remote='dev-type tap'
Dec 03 15:40:33 rincewind nm-openvpn[9346]: WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1544', remote='link-mtu 1576'
Dec 03 15:40:33 rincewind nm-openvpn[9346]: WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1500', remote='tun-mtu 1532'
Dec 03 15:40:33 rincewind nm-openvpn[9346]: [server] Peer Connection Initiated with [AF_INET]172.17.5.1:443
Dec 03 15:40:35 rincewind nm-openvpn[9346]: WARNING: Since you are using --dev tun with a point-to-point topology, the second argument to --ifconfig must be an IP address.  You are using somethi...config-nowarn)
Dec 03 15:40:35 rincewind nm-openvpn[9346]: WARNING: potential conflict between --remote address [172.17.5.1] and --ifconfig address pair [172.17.5.51, 255.255.255.0] -- this is a warning only t...config-nowarn)
Dec 03 15:40:35 rincewind nm-openvpn[9346]: TUN/TAP device tun0 opened
Dec 03 15:40:35 rincewind nm-openvpn[9346]: /usr/libexec/nm-openvpn-service-openvpn-helper tun0 1500 1544 172.17.5.51 255.255.255.0 init
Dec 03 15:40:35 rincewind NetworkManager[396]: <info> (tun0): carrier is OFF
Dec 03 15:40:35 rincewind NetworkManager[396]: <info> (tun0): new Tun device (driver: 'unknown' ifindex: 17)
Dec 03 15:40:35 rincewind NetworkManager[396]: <info> (tun0): exported as /org/freedesktop/NetworkManager/Devices/15
Dec 03 15:40:35 rincewind NetworkManager[396]: <info> (tun0): No existing connection detected.
Dec 03 15:40:35 rincewind NetworkManager[396]: <info> VPN connection 'VPN 1' (IP4 Config Get) reply received from old-style plugin.
Dec 03 15:40:35 rincewind NetworkManager[396]: <info> VPN Gateway: 172.17.5.1
Dec 03 15:40:35 rincewind NetworkManager[396]: <info> Tunnel Device: tun0
Dec 03 15:40:35 rincewind NetworkManager[396]: <info> IPv4 configuration:
Dec 03 15:40:35 rincewind NetworkManager[396]: <info>   Internal Gateway: 172.17.5.0
Dec 03 15:40:35 rincewind NetworkManager[396]: <info>   Internal Address: 172.17.5.51
Dec 03 15:40:35 rincewind NetworkManager[396]: <info>   Internal Prefix: 24
Dec 03 15:40:35 rincewind NetworkManager[396]: <info>   Internal Point-to-Point Address: 0.0.0.0
Dec 03 15:40:35 rincewind NetworkManager[396]: <info>   Maximum Segment Size (MSS): 0
Dec 03 15:40:35 rincewind NetworkManager[396]: <info>   Static Route: 172.17.0.0/16   Next Hop: 172.17.5.0
Dec 03 15:40:35 rincewind NetworkManager[396]: <info>   Forbid Default Route: no
Dec 03 15:40:35 rincewind NetworkManager[396]: <info>   Internal DNS: 172.17.17.2
Dec 03 15:40:35 rincewind NetworkManager[396]: <info>   DNS Domain: '(none)'
Dec 03 15:40:35 rincewind nm-openvpn[9346]: Initialization Sequence Completed
Dec 03 15:40:35 rincewind NetworkManager[396]: <info> No IPv6 configuration
Dec 03 15:40:35 rincewind NetworkManager[396]: <info> (tun0): link connected
Dec 03 15:40:35 rincewind NetworkManager[396]: <error> [1386078035.197551] [platform/nm-linux-platform.c:1116] add_object(): Netlink error: Invalid input data or parameter
Dec 03 15:40:35 rincewind NetworkManager[396]: <warn> VPN connection 'VPN 1' did not receive valid IP config information.
Dec 03 15:40:35 rincewind NetworkManager[396]: inet 172.17.0.0/16 table main
Dec 03 15:40:35 rincewind NetworkManager[396]: priority 0x400
Dec 03 15:40:35 rincewind NetworkManager[396]: nexthop via 172.17.5.0 dev 17
Dec 03 15:40:35 rincewind NetworkManager[396]: ** Message: Terminated openvpn daemon with PID 9346.
Dec 03 15:40:35 rincewind avahi-daemon[376]: Withdrawing workstation service for tun0.
Dec 03 15:40:35 rincewind NetworkManager[396]: <error> [1386078035.205439] [platform/nm-linux-platform.c:1449] link_change(): Netlink error: No such device
Dec 03 15:40:35 rincewind NetworkManager[396]: <error> [1386078035.205505] [platform/nm-linux-platform.c:1150] delete_object(): Netlink error: No such device
Dec 03 15:40:35 rincewind nm-openvpn[9346]: SIGTERM[hard,] received, process exiting

I tried upgrading libnl3 by compiling my own RPMs for libnl-3.2.23 and NetworkManager-pptp-0.9.8.4, the VPN still doesn't work.

BTW, what does the "old-style" plugin means in this message?

dec 03 14:44:43 localhost.localdomain NetworkManager[2516]: <info> VPN connection 'MYVPN' (IP4 Config Get) reply received from old-style plugin.

(In reply to Elad Alfassa from comment #52)
> I seem to still have this problem with the most recent nm packages installed:

> Dec 03 15:40:35 rincewind NetworkManager[396]: <info>   Internal
> Point-to-Point Address: 0.0.0.0

Your VPN is not using point-to-point topology, so the bug you're hitting is not the same as the one in this report. (And you should file a new bug report for it.)

(In reply to Zoltan Boszormenyi from comment #53)
> BTW, what does the "old-style" plugin means in this message?

It means NetworkManager-pptp hasn't been updated to support a certain optional new NM API. That's probably not related to your problem though; NetworkManager-openvpn is still old-style too.

Package NetworkManager-0.9.9.0-20.git20131003.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing NetworkManager-0.9.9.0-20.git20131003.fc20'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-22654/NetworkManager-0.9.9.0-20.git20131003.fc20
then log in and leave karma (feedback).

NetworkManager-0.9.9.0-20.git20131003.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Works for me now with latest updates from updates-testing.

I realized there was a problem with my PPTP VPN settings, this is why it didn't work. These were the automatic settings discovered by pppd:

dec 16 11:04:06 localhost.localdomain pppd[5687]: local  IP address 172.16.34.11
dec 16 11:04:06 localhost.localdomain pppd[5687]: remote IP address 192.168.100.2
dec 16 11:04:06 localhost.localdomain pppd[5687]: primary   DNS address 24.104.42.19
dec 16 11:04:06 localhost.localdomain pppd[5687]: secondary DNS address 192.168.5.1

I also had a few extra static routes added to this VPN:
192.168.7.0/24 gw 192.168.7.1
192.168.3.0/24 gw 192.168.7.1
192.168.5.0/24 gw 192.168.7.1
192.168.6.0/24 gw 192.168.7.1
172.16.0.0/16 gw 192.168.7.1

Previously, in F19 it worked for some reason. Most likely because NM ignored the specific gateway address, it only used the interface it has got from pppd. This seems to be a plausible explanation, because when I add these routes from the command line using only the ppp0 interface name, they work.

192.168.7.1 is not visible until the route to 192.168.7.0/24 is set up, NM in F20 must be using the GW address it was given. As soon as I replaced 192.168.7.1 with the remote P-t-P IP address, i.e. 192.168.100.2, the interface started up just fine. I know the bug is closed, I just wanted to tell that my detail was a textbook case of PEBKAC. :-) Sorry for the noise.

I am still having problems with the connection:

here's the sanitised log output i'm seeing

 NetworkManager[913]: <info>   Forbid Default Route: yes
 NetworkManager[913]: <info>   Internal DNS: 10.10.0.5
 NetworkManager[913]: <info>   DNS Domain: '(none)'
 NetworkManager[913]: <info> No IPv6 configuration
 NetworkManager[913]: <info> (tun0): link connected
 NetworkManager[913]: <error> [1388418942.756273] [platform/nm-linux-platform.c:1127] add_object(): Netlink error: Invalid input data or
 NetworkManager[913]: <warn> VPN connection 'VPN' did not receive valid IP config information.
 NetworkManager[913]: inet 44.147.153.233/24 table main
 NetworkManager[913]: priority 0x400
 NetworkManager[913]: nexthop via 10.10.5.123 dev 7
 NetworkManager[913]: ** Message: Terminated openvpn daemon with PID 4569.
 nm-openvpn[4569]: event_wait : Interrupted system call (code=4)
 avahi-daemon[791]: Withdrawing workstation service for tun0.
 NetworkManager[913]: refresh_object: assertion 'kernel_object' failed
 NetworkManager[913]: <error> [1388418942.758850] [platform/nm-linux-platform.c:1161] delete_object(): Netlink error: No such device
 nm-openvpn[4569]: SIGTERM[hard,] received, process exiting
 gnome-session[1850]: Gjs-Message: JS LOG: Removing a network device that was not added

On my system openvpn via NetworkManager is also broken again. However, this is probably unrelated to comment 59. Here is what happens:

1) connect to openvpn server via nm
2) connection is established, nm shows the lock symbol
3) traffic is not routed through tun0 (e.g. opening dnsleaktest.com in a browser), relevant part of the routing table: 

$ route 
Kernel IP routing table
Destination    Gateway           Genmask     Flags Metric Ref    Use Iface
default        192.168.x.x       0.0.0.0     UG    0      0        0 wlp3s0
default        xxx.xxx.xxx.xxx   0.0.0.0     UG    1024   0        0 tun0
[...] 

where wlp3s0 is my wifi and 192.168.x.x points to my router.

4) using openvpn on the command line with the same profile / server gives the expected result, i.e. traffic is routed through the VPN. Routing table in this case:

$ route -n
Kernel IP routing table
Destination    Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0        10.129.69.125   128.0.0.0       UG    0      0        0 tun0
default        192.168.1.1     0.0.0.0         UG    0      0        0 wlp3s0
default        192.168.1.1     0.0.0.0         UG    1024   0        0 wlp3s0
[...]

If you're having a problem which clearly isn't the original bug here, it would be best to file a new report rather than continuing to comment on a closed bug report.

i added it here cause of https://bugzilla.redhat.com/show_bug.cgi?id=1018317#c56.
But i'm happy to raise a new bug.

Hi,

I have similar issues with fortisslvpn client (all versions)

The tunnel is starting but gets stuck after sending 2188k 

root@laptop helper]# tail -f /var/log/messages
Mar 10 11:52:07 laptop kernel: PPP generic driver version 2.4.2
Mar 10 11:52:07 laptop pppd[1780]: Using interface ppp0
Mar 10 11:52:07 laptop pppd[1780]: Connect: ppp0 <--> /dev/pts/1
Mar 10 11:52:07 laptop NetworkManager[645]: <info> (ppp0): new Generic device (driver: 'unknown' ifindex: 4)
Mar 10 11:52:07 laptop NetworkManager[645]: <info> (ppp0): exported as /org/freedesktop/NetworkManager/Devices/3
Mar 10 11:52:07 laptop NetworkManager[645]: <info> (ppp0): No existing connection detected.
Mar 10 11:52:08 laptop kernel: [  582.330729] PPP BSD Compression module registered
Mar 10 11:52:08 laptop kernel: PPP BSD Compression module registered
Mar 10 11:52:08 laptop kernel: [  582.335820] PPP Deflate Compression module 


Please advise.
Thanks

Forgot to mention I am using fedora core 20

I've got the same problem.
I added some static routes in a OpenVPN connection and now it fails to activate the VPN.


May 20 08:35:50 starmetal NetworkManager[1136]: <info> Starting VPN service 'openvpn'...
May 20 08:35:50 starmetal NetworkManager[1136]: <info> VPN service 'openvpn' started (org.freedesktop.NetworkManager.openvpn), PID 15467
May 20 08:35:50 starmetal NetworkManager[1136]: <info> VPN service 'openvpn' appeared; activating connections
May 20 08:35:51 starmetal NetworkManager[1136]: <info> VPN plugin state changed: starting (3)
May 20 08:35:51 starmetal NetworkManager: ** Message: openvpn started with pid 15472
May 20 08:35:51 starmetal NetworkManager[1136]: <info> VPN connection 'Guezza' (Connect) reply received.
May 20 08:35:55 starmetal NetworkManager[1136]: <info> (tun0): carrier is OFF
May 20 08:35:55 starmetal NetworkManager[1136]: <info> (tun0): new Tun device (driver: 'unknown' ifindex: 17)
May 20 08:35:55 starmetal NetworkManager[1136]: <info> (tun0): exported as /org/freedesktop/NetworkManager/Devices/18
May 20 08:35:55 starmetal NetworkManager[1136]: <info> (tun0): No existing connection detected.
May 20 08:35:55 starmetal NetworkManager[1136]: <info> VPN connection 'Guezza' (IP Config Get) reply received.
May 20 08:35:55 starmetal NetworkManager[1136]: <info> VPN connection 'Guezza' (IP4 Config Get) reply received.
May 20 08:35:55 starmetal NetworkManager[1136]: <info> VPN Gateway: ***.***.***.***
May 20 08:35:55 starmetal NetworkManager[1136]: <info> Tunnel Device: tun0
May 20 08:35:55 starmetal NetworkManager[1136]: <info> IPv4 configuration:
May 20 08:35:55 starmetal NetworkManager[1136]: <info>   Internal Gateway: 192.168.66.5
May 20 08:35:55 starmetal NetworkManager[1136]: <info>   Internal Address: 192.168.66.6
May 20 08:35:55 starmetal NetworkManager[1136]: <info>   Internal Prefix: 32
May 20 08:35:55 starmetal NetworkManager[1136]: <info>   Internal Point-to-Point Address: 192.168.66.5
May 20 08:35:55 starmetal NetworkManager[1136]: <info>   Maximum Segment Size (MSS): 0
May 20 08:35:55 starmetal NetworkManager[1136]: <info>   Static Route: 10.150.3.0/24   Next Hop: 192.168.66.5
May 20 08:35:55 starmetal NetworkManager[1136]: <info>   Static Route: 192.168.66.0/24   Next Hop: 192.168.66.5
May 20 08:35:55 starmetal NetworkManager[1136]: <info>   Static Route: 192.168.66.1/32   Next Hop: 192.168.66.5
May 20 08:35:55 starmetal NetworkManager[1136]: <info>   Static Route: 10.0.0.0/8   Next Hop: 10.150.3.13
May 20 08:35:55 starmetal NetworkManager[1136]: <info>   Static Route: 172.16.0.0/12   Next Hop: 10.150.3.13
May 20 08:35:55 starmetal NetworkManager[1136]: <info>   Forbid Default Route: no
May 20 08:35:55 starmetal NetworkManager[1136]: <info>   DNS Domain: '(none)'
May 20 08:35:56 starmetal NetworkManager[1136]: <info> No IPv6 configuration
May 20 08:35:56 starmetal NetworkManager[1136]: <info> (tun0): link connected
May 20 08:35:56 starmetal NetworkManager[1136]: <error> [1400567755.986584] [platform/nm-linux-platform.c:1222] add_object(): Netlink error: Unspecific failure
May 20 08:35:56 starmetal NetworkManager[1136]: <warn> VPN connection 'Guezza' did not receive valid IP config information.
May 20 08:35:56 starmetal NetworkManager[1136]: <error> [1400567755.989793] [platform/nm-linux-platform.c:1596] link_change(): Netlink error: No such device
May 20 08:35:56 starmetal NetworkManager[1136]: <error> [1400567755.990827] [platform/nm-linux-platform.c:1278] delete_object(): Netlink error: No such device
May 20 08:35:56 starmetal NetworkManager[1136]: <warn> (tun0): failed to get device's ifindex
May 20 08:35:56 starmetal NetworkManager: inet 10.0.0.0/8 table main
May 20 08:35:56 starmetal NetworkManager: priority 0x400
May 20 08:35:56 starmetal NetworkManager: nexthop via 10.150.3.13 dev 17
May 20 08:35:56 starmetal NetworkManager: ** Message: Terminated openvpn daemon with PID 15472.
May 20 08:36:00 starmetal NetworkManager[1136]: <info> VPN service 'openvpn' disappeared


The first 3 routes are pushed by OpenVPN, the last 2 are static ones added in NetworkManager.

Fedora 20 amd64 NetworkManager-0.9.9.0-38.git20131003.fc20

(In reply to Alessio Caiazza from comment #65)

This bug is already closed and the original issue is most likely fixed.
Even if it would be the same issue/cause, it would be worth opening a new bug.







Anyway, ... does it work, if you leave out the static routes from the configuration? If it does, it would look like that your static routes are invalid.



Static Route: 10.150.3.0/24   Next Hop: 192.168.66.5
Static Route: 192.168.66.0/24   Next Hop: 192.168.66.5
Static Route: 192.168.66.1/32   Next Hop: 192.168.66.5
Static Route: 10.0.0.0/8   Next Hop: 10.150.3.13
Static Route: 172.16.0.0/12   Next Hop: 10.150.3.13

are the last two routes the ones you added manually?

I think, that the error here is that your "Next Hop: 10.150.3.13" is not directly reachable. You cannot add a route via a Next Hop that is not directly reachable. The kernel does not allow that.

Depending how your VPN is configured on the other set, you might should set set:

  Static Route: 10.0.0.0/8   Next Hop: 192.168.66.5
  Static Route: 172.16.0.0/12   Next Hop: 192.168.66.5

or

  Static Route: 10.0.0.0/8   Next Hop: 0.0.0.0
  Static Route: 172.16.0.0/12   Next Hop: 0.0.0.0

or

  Static Route: 10.150.3.13/32   Next Hop: 0.0.0.0
  Static Route: 10.0.0.0/8   Next Hop: 10.150.3.13
  Static Route: 172.16.0.0/12   Next Hop: 10.150.3.13


(with "Next Hop: 0.0.0.0" I mean that to set a direct route over the VPN tun device, no gateway)

*** Bug 1013700 has been marked as a duplicate of this bug. ***