On Tue, Dec 13, 2016 at 11:04:46PM +0100, Michael Biebl wrote: > Am 13.12.2016 um 18:22 schrieb Michael Biebl: > > I've blocked the two bugs accordingly and forwarded the issue to > > upstream. > > This is upstream's response > > > Thomas Haller: > > I don't think there is anything to do. > > > > nm-openvpn already supports the verify-x509-name option, which should > > be used. > > > > > > The problem is for users who have existing connections with > > tls-remote setting. > > > > For example, when you look at your NetworkManager ovpn connection > > (for example, named "MyOVPN"): > > > > $ nmcli connection show "MyVPN" | grep tls-remote > > > > > > openvpn 2.4 breaks backward compatibility by removing the option. > > There is nothing that nm-openvpn can do about it except requiring > > users to fix their configuration. > > > > E.g. the Gnome plugin of nm-openvpn for nm-connection-editor has a > > "Server Certificate Check" combobox. Affected users have to move away > > from the "Verify subject partially (legacy mode)" setting. > > In light of that, I'll close this bug report. > I suggest, openvpn either patches tls-remote support back in (for > stretch) or it adds a NEWS file, telling users to check their VPN > configuration files (including the NetworkManager config) and fix them > up manually.
Michael, Indeed, changing that configuration did fix my setup. Thanks! Since NM can detect this situation, could it provide this same advice to the user, even if just via syslog? -dann
