Description of problem:
Although the routes setup by nm-openvpn and vanilla openvpn client are almost the exact same, NetworkManager doesn't give a working connection whereas the openvpn init.d script does.

Version-Release number of selected component (if applicable):
[root@vpn-dbyrne ~]# rpm -qa | grep NetworkManager
NetworkManager-openvpn-0.7.0.99-1.fc11.x86_64
NetworkManager-gnome-0.7.1-4.git20090414.fc11.x86_64
NetworkManager-0.7.1-4.git20090414.fc11.x86_64
NetworkManager-glib-0.7.1-4.git20090414.fc11.x86_64

How reproducible:
Always using a "Password with certificates (TLS)" openvpn connection with an additional TLS key. It broke for me somewhere during an update to Fedora 10 and continues to be a problem in Fedora 11. We have to use the openvpn init.d script instead

Steps to Reproduce:
1. Connect using nm-openvpn
2. Connection is setup but unable to ping anything
  
Actual results:
Unable to ping any hosts with nm-openvpn. Works fine with vanilla openvpn client.

The result of "ip route | sort" with no VPN:
192.168.1.0/24 dev wlan0  proto kernel  scope link  src 192.168.1.76  metric 2
default via 192.168.1.254 dev wlan0  proto static

The result of "ip route | sort" with vanilla openvpn client (working):
172.16.0.0/16 via 192.168.13.133 dev tun0
172.17.0.0/16 via 192.168.13.133 dev tun0
172.18.0.0/16 via 192.168.13.133 dev tun0
192.168.0.0/24 via 192.168.13.133 dev tun0
192.168.10.0/24 via 192.168.13.133 dev tun0
192.168.1.0/24 dev wlan0  proto kernel  scope link  src 192.168.1.76  metric 2
192.168.1.0/24 via 192.168.13.133 dev tun0
192.168.12.0/24 via 192.168.13.133 dev tun0
192.168.13.129 via 192.168.13.133 dev tun0
192.168.13.133 dev tun0  proto kernel  scope link  src 192.168.13.135
192.168.20.166 via 192.168.13.133 dev tun0
192.168.20.204 via 192.168.13.133 dev tun0
192.168.2.0/24 via 192.168.13.133 dev tun0
193.XXX.XXX.XXX via 192.168.1.254 dev wlan0
default via 192.168.13.133 dev tun0

The result of "ip route | sort" with nm-openvpn (not working):
172.16.0.0/16 via 192.168.13.133 dev tun0  proto static
172.17.0.0/16 via 192.168.13.133 dev tun0  proto static
172.18.0.0/16 via 192.168.13.133 dev tun0  proto static
192.168.0.0/24 via 192.168.13.133 dev tun0  proto static
192.168.10.0/24 via 192.168.13.133 dev tun0  proto static
192.168.1.0/24 dev wlan0  proto kernel  scope link  src 192.168.1.76  metric 2
192.168.1.0/24 via 192.168.13.133 dev tun0  proto static
192.168.12.0/24 via 192.168.13.133 dev tun0  proto static
192.168.13.129 via 192.168.13.133 dev tun0  proto static
192.168.13.133 dev tun0  proto kernel  scope link  src 192.168.13.134
192.168.20.166 via 192.168.13.133 dev tun0  proto static
192.168.20.204 via 192.168.13.133 dev tun0  proto static
192.168.2.0/24 via 192.168.13.133 dev tun0  proto static
193.XXX.XXX.XXX via 192.168.1.254 dev wlan0  proto static
default via 192.168.13.133 dev tun0  proto static

The only visible difference in routing is the use of "proto static" in the nm-openvpn case.

Expected results:
It used to work for our openvpn server with the same account details in the early days of Fedora 10 but then broke in some update.

Additional info:
The following error message appears and periodically repeats in the logs for the nm-openvpn case:

nm-openvpn[15525]: write to TUN/TAP : Invalid argument (code=22)

In both cases the resolv.conf is correctly configured. iptables is disabled in both cases.