Jon Escombe wrote: > 2) openvpn and NM are both trying to setup the routes after connection, I > believe thats why there's an error message in the log. Perhaps we should be > passing the --route-noexec parameter to stop openvpn manipulating the routes > itself?
I don't think openvpn should be trying to setup routes unless specific options are being passed (--route, --route-gateway), but I could be wrong. Either way, there's no harm in passing that option. > 3) As I'm using a TAP device type and therefore effectively bridged onto my > vpn server subnet, my default route needs to include the gateway to get off > that subnet. This is available as the route_vpn_gateway environment variable, > but it's not picked up by NM. Not sure whether this would also be required > for a TUN connection? The openvpn plugin is picking up the "trusted_ip" env var and passing it to NM as the gateway. This is the public ip of the openvpn server (same ip we're passing to openvpn through --remote), so that NM can maintain a route to that IP over the underlying network. The route_vpn_gateway env var for me (using TUN) is set to the remote endpoint of the TUN device (which is in private address space). I think I'm going to need to switch to TAP and play with things a bit. (Thanks for your help testing by the way!) -casey _______________________________________________ NetworkManager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
