Thanks for testing my patches!
> I noticed that the default route also gets redirected to the tunnel > device even though the server does not push this route. So internet > connectivity is broken unless I explicitly enable the "use this > connection for resources on its network" setting. However I believe this > bug occurs with IPv4 as well, so I don't think it is something wrong > with your patches per se in this regard. > As I understand things after reading https://community.openvpn.net/openvpn/wiki/Openvpn23ManPage: (a) With IPv4, OpenVPN server issues an push "redirect-gateway def1" command which tells the client to configure a default route via what is in the route-gateway option. This option is retrieved by OpenVPN plugin using environment variable "route_vpn_gateway" but the first push command is lost and that's why NetworkManager provides a checkbox to allow the user to choose whether this VPN connection may be used as default route or not. (b) With IPv6, push "redirect-gateway def1" command doesn't do anything and there is nothing like "route_vpn_gateway". A simple workaround consists in pushing a route to 2000::/3 but there should be another way for an OpenVPN server to push IPv6 default routes to its clients. Right now, NetworkManager is acting in IPv6 like in IPv4: it creates a default route unless "use this connection only for resources on its network" is checked. For OpenVPN I think NM should never create a default route as the server pushes what is needed, but for other VPN the situation is certainly different. To be compatible with every VPN plugin, I've written a patch in bug 706332 which would allow the IPv6 internal gateway associated with a connection to be NULL, which is different from "::" (this latest value meaning "configure a default route without any gateway"). Best, Nicolas
_______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
