There's more screwy things going on with network-manager-openvpn's interaction with the routing table, I realised.  This is how my routing table look after activating the tunnel:

tore@envy:~$ ip r
10.8.0.5 dev tun0  proto kernel  scope link  src 10.8.0.6
VPN-GW.VPN-GW.VPN-GW.VPN-GW via 10.0.0.1 dev wlan0  proto static
10.0.0.0/24 dev wlan0  proto kernel  scope link  src 10.0.0.51  metric 2
VPN.VPN.VPN.0/19 dev tun0  proto static  scope link
169.254.0.0/16 dev wlan0  scope link  metric 1000
VPN.VPN.0.0/12 dev tun0  proto static  scope link
default via 10.0.0.1 dev wlan0  proto static

I've added the routes to VPN.VPN.* manually using the workaround I mentioned in another comment, since the default route redirection doesn't work.  One thing missing here is that there should be a route to 10.8.0.1 (the OpenVPN server's internal OpenVPN address).  It used to be automatically added before (and indeed, it pushes that address as the DNS dhcp-option too), so that's another regression.

You can see the host-route added to VPN-GW x 4 (which is neccessary for the OpenVPN connection to work, since that particular address is part of my employers VPN.VPN.VPN.0/19 network (and the OpenVPN packets can't very well be routed inside of the OpenVPN tunnel).

Then the VPN connection stop working.  In my logs I see the following:

Oct 14 23:10:46 envy dhclient: DHCPREQUEST of 10.0.0.51 on wlan0 to 10.0.0.1 port 67
Oct 14 23:10:46 envy dhclient: DHCPACK of 10.0.0.51 from 10.0.0.1
Oct 14 23:10:46 envy NetworkManager: <info>  DHCP: device wlan0 state changed bound -> renew
Oct 14 23:10:46 envy NetworkManager: <info>    address 10.0.0.51
Oct 14 23:10:46 envy NetworkManager: <info>    prefix 24 (255.255.255.0)
Oct 14 23:10:46 envy NetworkManager: <info>    gateway 10.0.0.1
Oct 14 23:10:46 envy NetworkManager: <info>    nameserver '217.13.7.140'
Oct 14 23:10:46 envy NetworkManager: <info>    nameserver '217.13.4.24'
Oct 14 23:10:46 envy NetworkManager: <info>    domain name 'lan'
Oct 14 23:10:46 envy NetworkManager: <info>  (wlan0): writing resolv.conf to /sbin/resolvconf
Oct 14 23:10:46 envy dhclient: bound to 10.0.0.51 -- renewal in 2735 seconds.
Oct 14 23:10:46 envy avahi-daemon[5342]: Withdrawing address record for 10.0.0.51 on wlan0.
Oct 14 23:10:46 envy avahi-daemon[5342]: Leaving mDNS multicast group on interface wlan0.IPv4 with address 10.0.0.51.
Oct 14 23:10:46 envy avahi-daemon[5342]: Interface wlan0.IPv4 no longer relevant for mDNS.
Oct 14 23:10:46 envy avahi-daemon[5342]: Joining mDNS multicast group on interface wlan0.IPv4 with address 10.0.0.51.
Oct 14 23:10:46 envy avahi-daemon[5342]: New relevant interface wlan0.IPv4 for mDNS.
Oct 14 23:10:46 envy avahi-daemon[5342]: Registering new address record for 10.0.0.51 on wlan0.IPv4.
Oct 14 23:10:47 envy NetworkManager: <info>  (wlan0): writing resolv.conf to /sbin/resolvconf
Oct 14 23:10:47 envy NetworkManager: <info>  Policy set (wlan0) as default device for routing and DNS.
Oct 14 23:12:36 envy nm-openvpn[23085]: [openvpn-gw.employer.no] Inactivity timeout (--ping-restart), restarting
Oct 14 23:12:36 envy nm-openvpn[23085]: SIGUSR1[soft,ping-restart] received, process restarting
Oct 14 23:12:38 envy nm-openvpn[23085]: WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Oct 14 23:12:38 envy nm-openvpn[23085]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Oct 14 23:12:38 envy nm-openvpn[23085]: Re-using SSL/TLS context
Oct 14 23:12:38 envy nm-openvpn[23085]: LZO compression initialized
Oct 14 23:12:38 envy nm-openvpn[23085]: UDPv4 link local: [undef]
Oct 14 23:12:38 envy nm-openvpn[23085]: UDPv4 link remote: VPN-GW.VPN-GW.VPN-GW.VPN-GW:1194
Oct 14 23:13:25 envy NetworkManager: <info>  (wlan0): supplicant connection state change: 7 -> 6
Oct 14 23:13:25 envy NetworkManager: <info>  (wlan0): supplicant connection state change: 6 -> 7
Oct 14 23:13:38 envy nm-openvpn[23085]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your networkconnectivity)
Oct 14 23:13:38 envy nm-openvpn[23085]: TLS Error: TLS handshake failed
Oct 14 23:13:38 envy nm-openvpn[23085]: SIGUSR1[soft,tls-error] received, process restarting
Oct 14 23:13:40 envy nm-openvpn[23085]: WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
[...repeated...]

And the new routing table:

tore@envy:~$ ip r
10.8.0.5 dev tun0  proto kernel  scope link  src 10.8.0.6
10.0.0.0/24 dev wlan0  proto kernel  scope link  src 10.0.0.51  metric 2
VPN.VPN.VPN.0/19 dev tun0  proto static  scope link
VPN.VPN.0.0/12 dev tun0  proto static  scope link
default via 10.0.0.1 dev wlan0  proto static

So what just happened?  It seems that the DHCP lease (given out by a lame residental CPE/NAT device which terminates my DSL circuit) was up for renewal.  As part of this procedure n-m removed the route to VPN-GW, which of cause breaks the tunnel since those packets are now routed to inside the VPN tunnel (a catch-22), since the VPN routes themselves are left in place.  The same problem would occur if the redirection of the default route redirection worked, since VPN-GW is within the default route too.  So the host (/32) route to the VPN GW needs to left intact for the VPN connection to work, but right now this too seems to be broken.

Apologies for the anonymisation, I'm a bit paranoid about these things.  Hope the report is still usable.
Tore