Ubuntu
network-manager-openvpn package

network-manager-openvpn claims connection established when it's not

Bug #909102 reported by Maarten Jacobs
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
network-manager-openvpn (Ubuntu)
New
Undecided
Unassigned

Bug Description

I'm using pre-shared keys to create a simple PTP VPN connection. My server is running on windows XP, my client on XUbuntu 11.10.

I'm using the plugin to allow my XUbuntu machine to establish the connection to the windows machine. I have the OpenVPN software installed on the windows machine.

If I enable the server on windows, I can connect successfully to the server and exchange data.

However, if I disable the server on the windows machine, and attempt to create the VPN connection, I get the pop-up that states the VPN connection has been established. In fact there is no VPN connection (as the server is not accepting connections).

I therefore believe the plugin claims success too early - or it reporting a certain status to network-manager is interpreted incorrectly.

Here's a snippet from syslog (I've blanked out my IP addresses):

Dec 27 12:17:09 snellebak nm-openvpn[16201]: UDPv4 link local: [undef]
Dec 27 12:17:09 snellebak nm-openvpn[16201]: UDPv4 link remote: [AF_INET]xxx.xxx.xxx.xxx:1194
Dec 27 12:17:10 snellebak NetworkManager[705]: <info> VPN connection 'test' (IP Config Get) complete.
Dec 27 12:17:10 snellebak NetworkManager[705]: <info> Policy set 'test' (tun0) as default for IPv4 routing and DNS.
Dec 27 12:17:10 snellebak NetworkManager[705]: <info> VPN plugin state changed: 4

<< At this stage the VPN connection is marked as "established" >>

Dec 27 12:17:18 snellebak nm-openvpn[16201]: Peer Connection Initiated with [AF_INET]xxx.xxx.xxx.xxx:1194
Dec 27 12:17:19 snellebak nm-openvpn[16201]: Initialization Sequence Completed

<< When the VPN server is enabled, the connection is not really established until this point>>

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: network-manager-openvpn 0.9.0-0ubuntu1
ProcVersionSignature: Ubuntu 3.0.0-14.23-generic 3.0.9
Uname: Linux 3.0.0-14-generic i686
ApportVersion: 1.23-0ubuntu4
Architecture: i386
Date: Tue Dec 27 13:06:46 2011
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release i386 (20101007)
ProcEnviron:
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: network-manager-openvpn
UpgradeStatus: Upgraded to oneiric on 2011-10-28 (60 days ago)

Revision history for this message
Maarten Jacobs (maarten256) wrote :
Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please answer these questions:

* Is this reproducible?
* If so, what specific steps should we take to recreate this bug?

This will help us to find and resolve the problem.

Changed in network-manager-openvpn (Ubuntu):
status: New → Incomplete
Revision history for this message
Maarten Jacobs (maarten256) wrote :

Yes - highly (and easily) reproducible.

1. Use Windows as Server (I'm using XP), XUbuntu as Client
2. Install OpenVPN on Windows XP (download here http://swupdate.openvpn.org/community/releases/openvpn-2.2.2-install.exe)
3. Configure simple server on Windows (follow these instructions http://openvpn.net/index.php/open-source/documentation/miscellaneous/78-static-key-mini-howto.html)
4. Launch OpenVPN GUI on Windows (do NOT connect on windows)
5. Set up VPN Connection on XUbuntu - to match OpenVPN connection created on Windows Server
6. Connect on Windows
7. Connect on XUbuntu
8. Connection will be marked as "established" on XUbuntu - similar message seen on Windows
9. Verify connection by pinging server from client, and vice-versa (use IP addresses as defined in configuration). Will require Windows Firewall to be updated to return ICMP Echo Packets.
10. Disconnect VPN connection on Server/Windows (connection is not lost on Client/XUbuntu side)
11. Disconnect VPN connection on Client/XUbuntu side
12. Reconnect on Client/XUbuntu side. Connection will be shown as established on Client/XUbuntu (through pop-up window). Connection does not show as connected on Server/Windows.
13. Attempt to ping server from client - no success.

On step 12 above, the network-manager erroneously assumes the connection is established when it is done initializing - even before it made a connection with the server. Refer to the log output I provided with the original bug report.

Hope this helps.

Maarten Jacobs (maarten256)
Changed in network-manager-openvpn (Ubuntu):
status: Incomplete → New
Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

Please provide full /var/log/syslog logs, also see http://live.gnome.org/NetworkManager/Debugging for how to get debug logs for the openvpn connections.

Changed in network-manager-openvpn (Ubuntu):
status: New → Incomplete
Maarten Jacobs (maarten256)
Changed in network-manager-openvpn (Ubuntu):
status: Incomplete → New
Revision history for this message
Maarten Jacobs (maarten256) wrote :

I have captured more output during a session where I tested the behavior of the openvpn plugin.

Using the referenced instructions (which are incorrect btw as nm-openvpn-service does not reside in /usr/libexec, but in /usr/lib/NetworkManager/), I created two output files that capture the debug:

nm-openvpn-service.out - captures debug for a "normal" session where the server is accepting connections.

nm-openvpn-service-error.out - captures output where the server is not accepting connections, but the VPN connection is still marked as "up" on the client side.

I've also attached /var/log/syslog that captures the same sessions. I assume timestamps between the openvpn-service output and syslog can be used to correlate the individually captured sessions with the output recorded in syslog.

(The three log files are in the attached debug_out.tgz tarball - so I can attach all three log files as one)

Let me know if anything else is needed!!!

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

Other bug subscribers

Remote bug watches

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