Hide Forgot
Created attachment 1147282 [details] nm log, with nm-openpn-service --debug Description of problem: Imported a ".ovpn" file to NM-ovpn, connection fails silently. Version-Release number of selected component (if applicable): NetworkManager-openvpn-1.0.8-2.fc23.x86_64 NetworkManager-openvpn-gnome-1.0.8-2.fc23.x86_64 openvpn-2.3.10-1.fc23.x86_64 How reproducible: 100% Steps to Reproduce: 1. Import ovpn file, review settings, provide password, save. 2. Attempt connectin 3. Actual results: Connection failed, no feedback Expected results: Successful connection Additional info: Debug log to be attached
What is the ovpn file which works for you? (please redact possible sensitive data)
Heh, I already leaked a temporary password, which has been changed already. Here are the interesting parts of the ovpn file, which works for openvpn, and has imported (apparently successfully) to NM. setenv FORWARD_COMPATIBLE 1 client server-poll-timeout 4 nobind remote vpn.x.com 1194 udp remote vpn.x.com 1194 udp remote vpn.x.com 443 tcp remote vpn.x.com 1194 udp remote vpn.x.com 1194 udp remote vpn.x.com 1194 udp remote vpn.x.com 1194 udp remote vpn.x.com 1194 udp dev tun dev-type tun ns-cert-type server reneg-sec 604800 sndbuf 100000 rcvbuf 100000 auth-user-pass /home/martin/src/... # NOTE: LZO commands are pushed by the Access Server at connect time. # NOTE: The below line doesn't disable LZO. comp-lzo no verb 3 setenv PUSH_PEER_INFO <ca> -----BEGIN CERTIFICATE----- IndBdMoJCi8ISAcG+3SwfAGmzkczHDAFWjWZhA== -----END CERTIFICATE----- </ca> <cert> ... -----END CERTIFICATE----- </cert> <key> -----BEGIN PRIVATE KEY----- ... -----END PRIVATE KEY----- </key> key-direction 1 <tls-auth> -----BEGIN OpenVPN Static key V1----- ... -----END OpenVPN Static key V1----- </tls-auth>
Hm, I don't see what is wrong there. At least to me, the openvpn logfile isn't telling the problem. In the logfile from comment 1, you see how nm-openvpn starts openvpn (the line with "EXEC: '/usr/sbin/openvpn"). Could you start with these options and try it in the terminal, tweaking the options until it works?
Probably the same issue as: https://bugzilla.gnome.org/show_bug.cgi?id=739519 caused by bad handling of "comp-lzo no" option, which is now solved.
Interesting. From what I can see 1.2.4 isn't in F24 yet. Quick check of Koji shows no builds to test either. I'll be happy to test and confirm, if there's an update to test ;-)
NetworkManager-openvpn-1.2.4-1.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-c719a6115b
NetworkManager-openvpn-1.2.4-1.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-c719a6115b
Bingo! it works.
NetworkManager-openvpn-1.2.4-1.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.
This breaks connection to the RH VPN. Aug 4 15:31:47 krikkit nm-openvpn[26478]: Bad LZO decompression header byte: 42 I do not have LZO compression enabled! Downgrading to NetworkManager-openvpn.x86_64 1:1.2.2-1.fc24 allows me to connect to the internel RH network again.
(In reply to Andreas Schneider from comment #10) > This breaks connection to the RH VPN. > > Aug 4 15:31:47 krikkit nm-openvpn[26478]: Bad LZO decompression header > byte: 42 > > I do not have LZO compression enabled! > > Downgrading to NetworkManager-openvpn.x86_64 1:1.2.2-1.fc24 allows me to > connect to the internel RH network again. I think this is related to https://bugzilla.redhat.com/show_bug.cgi?id=1355688#c24 and the new issue is tracked there. Andreas, could you verify that you see "comp-lzo=no" in `nmcli connection show $CONN_NAME` and that the regression is caused by that? Did you originally use plasma-nm to create your connection? Thanks.
The regression mentioned in comment 10 is indeed bug 1355688. I close this BZ again as the issue is tracked there. Thanks Andreas.