Error configuring network is seen on connecting to openvpn, for enterprise user. |
|||||||||||||||
Issue descriptionChrome OS-10323.46.0 65.0.3325.107 DUT: Hana/Bob. What steps will reproduce the problem? 1) Install the image on the device, sign in with credentials networktest02/chromeos. 2) Configure a VPN (for example openvpn) 3) Fill/Select the required details. 4) Click on the active connect button. Note: This happens for an enterprise user, works fine for an regular user. Reproducible on Hana/Bob. Not reproducible on Eve. Will check on more devices and update. What is the expected result? Openvpn should be connected without any errors. What happens instead? 1) On clicking the connect button, it displays the config window back - if connected through chrome://settings page. 2) On clicking the connect button, it shows 'Error configuring network' - if connected through the bottom panel from the user. Screenshot + Feedback report on Hana - https://listnr.corp.google.com/report/85127521110 Feedback report on Bob - https://listnr.corp.google.com/report/85127570192
,
Mar 2 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/1a36c69b9784a29b6b84cd735a99ab1ead285d44 commit 1a36c69b9784a29b6b84cd735a99ab1ead285d44 Author: Steven Bennetts <stevenjb@chromium.org> Date: Fri Mar 02 22:44:49 2018 ONC: Allow VPN.OpenVPN.UserAuthenticationType to be unspecified Currently if a policy does not specify UserAuthenticationType, Password and OTP will be stripped from merged ONC. Insead we should allow both if unspecified. Bug: 817617 Change-Id: I2c4a47fb5aa0faaba10d4a76e53bb54671e7f450 Reviewed-on: https://chromium-review.googlesource.com/944617 Reviewed-by: Maksim Ivanov <emaxx@chromium.org> Commit-Queue: Steven Bennetts <stevenjb@chromium.org> Cr-Commit-Position: refs/heads/master@{#540669} [modify] https://crrev.com/1a36c69b9784a29b6b84cd735a99ab1ead285d44/chromeos/network/managed_network_configuration_handler_unittest.cc [modify] https://crrev.com/1a36c69b9784a29b6b84cd735a99ab1ead285d44/chromeos/network/onc/onc_normalizer.cc [modify] https://crrev.com/1a36c69b9784a29b6b84cd735a99ab1ead285d44/chromeos/test/data/network/policy/policy_vpn.onc [add] https://crrev.com/1a36c69b9784a29b6b84cd735a99ab1ead285d44/chromeos/test/data/network/policy/policy_vpn_no_user_auth_type.onc
,
Mar 2 2018
,
Mar 3 2018
Your change meets the bar and is auto-approved for M66. Please go ahead and merge the CL to branch 3359 manually. Please contact milestone owner if you have questions. Owners: cmasso@(Android), cmasso@(iOS), josafat@(ChromeOS), abdulsyed@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Mar 5 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/0752d345f32fe760c412c743abe3017ea73f0292 commit 0752d345f32fe760c412c743abe3017ea73f0292 Author: Steven Bennetts <stevenjb@chromium.org> Date: Mon Mar 05 23:17:08 2018 ONC: Allow VPN.OpenVPN.UserAuthenticationType to be unspecified Currently if a policy does not specify UserAuthenticationType, Password and OTP will be stripped from merged ONC. Insead we should allow both if unspecified. TBR=stevenjb@chromium.org (cherry picked from commit 1a36c69b9784a29b6b84cd735a99ab1ead285d44) Bug: 817617 Change-Id: I2c4a47fb5aa0faaba10d4a76e53bb54671e7f450 Reviewed-on: https://chromium-review.googlesource.com/944617 Reviewed-by: Maksim Ivanov <emaxx@chromium.org> Commit-Queue: Steven Bennetts <stevenjb@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#540669} Reviewed-on: https://chromium-review.googlesource.com/949976 Reviewed-by: Steven Bennetts <stevenjb@chromium.org> Cr-Commit-Position: refs/branch-heads/3359@{#18} Cr-Branched-From: 66afc5e5d10127546cc4b98b9117aff588b5e66b-refs/heads/master@{#540276} [modify] https://crrev.com/0752d345f32fe760c412c743abe3017ea73f0292/chromeos/network/managed_network_configuration_handler_unittest.cc [modify] https://crrev.com/0752d345f32fe760c412c743abe3017ea73f0292/chromeos/network/onc/onc_normalizer.cc [modify] https://crrev.com/0752d345f32fe760c412c743abe3017ea73f0292/chromeos/test/data/network/policy/policy_vpn.onc [add] https://crrev.com/0752d345f32fe760c412c743abe3017ea73f0292/chromeos/test/data/network/policy/policy_vpn_no_user_auth_type.onc
,
Mar 8 2018
This continues to fail on M66 10452.2.0, 66.0.3359.10 (Eve and Candy devices). Should this be ReleaseBlock-Dev?
,
Mar 8 2018
feedback reports: 1) Candy: https://listnr.corp.google.com/report/85161150236 2) Eve: https://listnr.corp.google.com/report/85161214242
,
Mar 8 2018
I don't think this needs to be R-B-Dev. My official chromebook just updated with 66.0.3359.10 and configuration for me fails but the symptom is different: Observe: Notification appears: 'Failed to connect to network Google OpenVPN: Internal error' Looking at chrome://device-log and the properties set after 'SetShillProperties', it looks like we are now specifying Uer and Password but not OTP :( p.s. when re-opening please use 'Assigned' not 'Available'.
,
Mar 13 2018
The CL on comment #5 only fixed part of the problem. A new Cl is up with another fix which is hopefully sufficient: In ONC, if a policy provided network configuration does not explicitly list a property as 'Recommended', the user is not able to set the property. In Google's OpenVPN policy configuration (and potentially others), UserAuthenticationType is not explicitly set, and OTP is not included in the Recommended list, even though it needs to be provided by the user. To work around this technically incorrect policy configuration (and not break existing policies with the new UI), when UserAuthenticationType is not explicitly set in the policy, this change adds Password and OTP to the Recommended list so that they can be provided by the UI.
,
Mar 14 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/1c0f0cb625d70da8a204f71b8810c6dd67997d0b commit 1c0f0cb625d70da8a204f71b8810c6dd67997d0b Author: Steven Bennetts <stevenjb@chromium.org> Date: Wed Mar 14 20:03:57 2018 ONC: OpenVPN: Make Password and OTP recommended if auth type unset In ONC, if a policy provided network configuration does not explicitly list a property as 'Recommended', the user is not able to set the property. In Google's OpenVPN policy configuration (and potentially others), UserAuthenticationType is not explicitly set, and OTP is not included in the Recommended list, even though it needs to be provided by the user. To work around this technically incorrect policy configuration (and not break existing policies with the new UI), when UserAuthenticationType is not explicitly set in the policy, this change adds Password and OTP to the Recommended list so that they can be provided by the UI. This also adds a test that catches the failure case and passes with the new changes. Bug: 817617 Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation Change-Id: If22f34e8943a2b82cf8becc93f257413c3cdcf92 Reviewed-on: https://chromium-review.googlesource.com/961365 Commit-Queue: Steven Bennetts <stevenjb@chromium.org> Reviewed-by: Toni Barzic <tbarzic@chromium.org> Cr-Commit-Position: refs/heads/master@{#543171} [modify] https://crrev.com/1c0f0cb625d70da8a204f71b8810c6dd67997d0b/chrome/browser/resources/settings/internet_page/internet_detail_page.js [modify] https://crrev.com/1c0f0cb625d70da8a204f71b8810c6dd67997d0b/chromeos/network/managed_network_configuration_handler_unittest.cc [modify] https://crrev.com/1c0f0cb625d70da8a204f71b8810c6dd67997d0b/chromeos/network/network_configuration_handler_unittest.cc [modify] https://crrev.com/1c0f0cb625d70da8a204f71b8810c6dd67997d0b/chromeos/network/onc/onc_translator_onc_to_shill.cc [modify] https://crrev.com/1c0f0cb625d70da8a204f71b8810c6dd67997d0b/chromeos/network/onc/onc_validator.cc [modify] https://crrev.com/1c0f0cb625d70da8a204f71b8810c6dd67997d0b/chromeos/network/onc/onc_validator.h [add] https://crrev.com/1c0f0cb625d70da8a204f71b8810c6dd67997d0b/chromeos/test/data/network/policy/policy_vpn_no_auth.onc [add] https://crrev.com/1c0f0cb625d70da8a204f71b8810c6dd67997d0b/chromeos/test/data/network/policy/policy_vpn_ui.json [modify] https://crrev.com/1c0f0cb625d70da8a204f71b8810c6dd67997d0b/chromeos/test/data/network/policy/shill_policy_on_managed_vpn.json [add] https://crrev.com/1c0f0cb625d70da8a204f71b8810c6dd67997d0b/chromeos/test/data/network/policy/shill_policy_on_managed_vpn_plus_ui.json [modify] https://crrev.com/1c0f0cb625d70da8a204f71b8810c6dd67997d0b/chromeos/test/data/network/repaired_toplevel_partially_invalid.onc
,
Mar 14 2018
New merge request for CL in comment #10.
,
Mar 15 2018
This bug requires manual review: M66 has already been promoted to the beta branch, so this requires manual review Please contact the milestone owner if you have questions. Owners: cmasso@(Android), cmasso@(iOS), josafat@(ChromeOS), abdulsyed@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Mar 15 2018
,
Mar 16 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/7c9a99bb96ffe335c046a92074f4f5d0ace2277a commit 7c9a99bb96ffe335c046a92074f4f5d0ace2277a Author: Steven Bennetts <stevenjb@chromium.org> Date: Fri Mar 16 22:31:50 2018 ONC: OpenVPN: Make Password and OTP recommended if auth type unset In ONC, if a policy provided network configuration does not explicitly list a property as 'Recommended', the user is not able to set the property. In Google's OpenVPN policy configuration (and potentially others), UserAuthenticationType is not explicitly set, and OTP is not included in the Recommended list, even though it needs to be provided by the user. To work around this technically incorrect policy configuration (and not break existing policies with the new UI), when UserAuthenticationType is not explicitly set in the policy, this change adds Password and OTP to the Recommended list so that they can be provided by the UI. This also adds a test that catches the failure case and passes with the new changes. TBR=stevenjb@chromium.org (cherry picked from commit 1c0f0cb625d70da8a204f71b8810c6dd67997d0b) Bug: 817617 Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation Change-Id: If22f34e8943a2b82cf8becc93f257413c3cdcf92 Reviewed-on: https://chromium-review.googlesource.com/961365 Commit-Queue: Steven Bennetts <stevenjb@chromium.org> Reviewed-by: Toni Barzic <tbarzic@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#543171} Reviewed-on: https://chromium-review.googlesource.com/967374 Reviewed-by: Steven Bennetts <stevenjb@chromium.org> Cr-Commit-Position: refs/branch-heads/3359@{#294} Cr-Branched-From: 66afc5e5d10127546cc4b98b9117aff588b5e66b-refs/heads/master@{#540276} [modify] https://crrev.com/7c9a99bb96ffe335c046a92074f4f5d0ace2277a/chrome/browser/resources/settings/internet_page/internet_detail_page.js [modify] https://crrev.com/7c9a99bb96ffe335c046a92074f4f5d0ace2277a/chromeos/network/managed_network_configuration_handler_unittest.cc [modify] https://crrev.com/7c9a99bb96ffe335c046a92074f4f5d0ace2277a/chromeos/network/network_configuration_handler_unittest.cc [modify] https://crrev.com/7c9a99bb96ffe335c046a92074f4f5d0ace2277a/chromeos/network/onc/onc_translator_onc_to_shill.cc [modify] https://crrev.com/7c9a99bb96ffe335c046a92074f4f5d0ace2277a/chromeos/network/onc/onc_validator.cc [modify] https://crrev.com/7c9a99bb96ffe335c046a92074f4f5d0ace2277a/chromeos/network/onc/onc_validator.h [add] https://crrev.com/7c9a99bb96ffe335c046a92074f4f5d0ace2277a/chromeos/test/data/network/policy/policy_vpn_no_auth.onc [add] https://crrev.com/7c9a99bb96ffe335c046a92074f4f5d0ace2277a/chromeos/test/data/network/policy/policy_vpn_ui.json [modify] https://crrev.com/7c9a99bb96ffe335c046a92074f4f5d0ace2277a/chromeos/test/data/network/policy/shill_policy_on_managed_vpn.json [add] https://crrev.com/7c9a99bb96ffe335c046a92074f4f5d0ace2277a/chromeos/test/data/network/policy/shill_policy_on_managed_vpn_plus_ui.json [modify] https://crrev.com/7c9a99bb96ffe335c046a92074f4f5d0ace2277a/chromeos/test/data/network/repaired_toplevel_partially_invalid.onc
,
Apr 11 2018
Openvpn256 failed to connect on DUT - Soraka, on M66-10452.54.0 Feedback report on Soraka - https://listnr.corp.google.com/report/85302955458
,
Apr 11 2018
Is this only happening in Soraka boards? Was this tested on previous M66 beta? passed?
,
Apr 11 2018
on previous M66 beta it passed. I had tested this vpn-256 connection on Santa DUT. Build: M66 - 66.0.3359.79 (10452.42.0)
,
Apr 12 2018
Is it failing on Santa for this build now?
,
Apr 12 2018
Assuming this is a regression from previous beta (dsunkara@ please confirm on c#18 that this problem is seen in all boards now and was not seen on .79) Steven, anything that may have caused this as per diff below? here is the diff (chrome) from previous beta https://chromium.googlesource.com/chromium/src/+log/66.0.3359.79..66.0.3359.102?n=10000
,
Apr 12 2018
Yes, this is failing on Santa for this build. Also verified that Openvpn256 issue exists on last beta build of M66 on Eve. This bug was originally logged for openvpn and openvpn connection is good on current build.
,
Apr 12 2018
The primary issue is that it can't resolve the hostname "openvpn256":
2018-04-11T16:06:18.539655-07:00 INFO shill[1151]: [INFO:openvpn_driver.cc(322)] OpenVPN process options: client,tls-client,remote openvpn256,nobind,persist-key,persist-tun,dev tun0,dev-type tun,syslog,proto tcp,port 1194,auth-retry interact,ca /run/shill/certificate_export/.org.chromium.Chromium.uK029v,auth-user-pass,remote-cert-tls server,management <IPv4: 25> 36855,management-client,management-hold,management-query-passwords,setenv SHILL_TASK_SERVICE :1.5,setenv SHILL_TASK_SERVICE :1.5,setenv SHILL_TASK_PATH /task/1,script-security 2,up /usr/lib64/shill/shims/openvpn-script,up-restart,route-noexec,ifconfig-noexec,user openvpn,group openvpn
2018-04-11T16:06:18.541517-07:00 INFO shill[1151]: [INFO:service.cc(312)] Suppressed autoconnect to service 1 (no endpoints)
2018-04-11T16:06:18.541610-07:00 INFO shill[1151]: [INFO:service.cc(312)] Suppressed autoconnect to service 2 (no endpoints)
2018-04-11T16:06:18.541664-07:00 INFO shill[1151]: [INFO:service.cc(312)] Suppressed autoconnect to service 45 (throttled)
2018-04-11T16:06:18.548399-07:00 NOTICE openvpn[7661]: OpenVPN 2.4.4 x86_64-cros-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Apr 10 2018
2018-04-11T16:06:18.548512-07:00 NOTICE openvpn[7661]: library versions: OpenSSL 1.0.2n 7 Dec 2017, LZO 2.06
2018-04-11T16:06:18.549193-07:00 INFO shill[1151]: [INFO:openvpn_management_server.cc(226)] >INFO:OpenVPN Management Interface Version 1 -- type 'help' for more info
2018-04-11T16:06:18.549289-07:00 INFO shill[1151]: [INFO:openvpn_management_server.cc(405)] Client waiting for hold release.
2018-04-11T16:06:18.549343-07:00 INFO shill[1151]: [INFO:openvpn_management_server.cc(154)] Releasing hold.
2018-04-11T16:06:18.552629-07:00 INFO shill[1151]: [INFO:openvpn_management_server.cc(417)] SUCCESS: real-time state notification set to ON
2018-04-11T16:06:18.591427-07:00 INFO shill[1151]: [INFO:openvpn_management_server.cc(417)] SUCCESS: hold release succeeded
2018-04-11T16:06:18.591443-07:00 INFO shill[1151]: [INFO:openvpn_management_server.cc(236)] Processing need-password message.
2018-04-11T16:06:18.591453-07:00 INFO shill[1151]: [INFO:openvpn_management_server.cc(319)] Perform authentication: Auth
2018-04-11T16:06:18.591603-07:00 INFO shill[1151]: [INFO:openvpn_management_server.cc(417)] SUCCESS: 'Auth' username entered, but not yet verified
2018-04-11T16:06:18.591614-07:00 INFO shill[1151]: [INFO:openvpn_management_server.cc(417)] SUCCESS: 'Auth' password entered, but not yet verified
2018-04-11T16:06:18.591654-07:00 WARNING openvpn[7661]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2018-04-11T16:06:18.723173-07:00 ERR openvpn[7661]: RESOLVE: Cannot resolve host address: openvpn256:1194 (Name or service not known)
2018-04-11T16:06:18.852353-07:00 ERR openvpn[7661]: RESOLVE: Cannot resolve host address: openvpn256:1194 (Name or service not known)
2018-04-11T16:06:18.852393-07:00 WARNING openvpn[7661]: Could not determine IPv4/IPv6 protocol
2018-04-11T16:06:18.852418-07:00 NOTICE openvpn[7661]: NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
2018-04-11T16:06:18.852694-07:00 NOTICE openvpn[7661]: SIGUSR1[soft,init_instance] received, process restarting
2018-04-11T16:06:18.852823-07:00 INFO shill[1151]: [INFO:openvpn_management_server.cc(386)] OpenVPN state: RESOLVE
2018-04-11T16:06:18.852882-07:00 INFO shill[1151]: [INFO:openvpn_management_server.cc(386)] OpenVPN state: RESOLVE
2018-04-11T16:06:18.852960-07:00 INFO shill[1151]: [INFO:openvpn_management_server.cc(386)] OpenVPN state: RECONNECTING
2018-04-11T16:06:18.852992-07:00 INFO shill[1151]: [INFO:openvpn_driver.cc(987)] OnReconnecting(0)
2018-04-11T16:06:18.853250-07:00 INFO shill[1151]: [INFO:openvpn_management_server.cc(405)] Client waiting for hold release.
2018-04-11T16:06:18.853276-07:00 INFO shill[1151]: [INFO:openvpn_management_server.cc(154)] Releasing hold.
2018-04-11T16:06:18.853639-07:00 WARNING openvpn[7661]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2018-04-11T16:06:18.853721-07:00 INFO shill[1151]: [INFO:openvpn_management_server.cc(417)] SUCCESS: hold release succeeded
2018-04-11T16:06:18.983421-07:00 ERR openvpn[7661]: RESOLVE: Cannot resolve host address: openvpn256:1194 (Name or service not known)
2018-04-11T16:06:19.110698-07:00 ERR openvpn[7661]: RESOLVE: Cannot resolve host address: openvpn256:1194 (Name or service not known)
2018-04-11T16:06:19.110734-07:00 WARNING openvpn[7661]: Could not determine IPv4/IPv6 protocol
2018-04-11T16:06:19.110988-07:00 NOTICE openvpn[7661]: SIGUSR1[soft,init_instance] received, process restarting
2018-04-11T16:06:19.111104-07:00 INFO shill[1151]: [INFO:openvpn_management_server.cc(386)] OpenVPN state: RESOLVE
2018-04-11T16:06:19.111162-07:00 INFO shill[1151]: [INFO:openvpn_management_server.cc(386)] OpenVPN state: RESOLVE
2018-04-11T16:06:19.111245-07:00 INFO shill[1151]: [INFO:openvpn_management_server.cc(386)] OpenVPN state: RECONNECTING
2018-04-11T16:06:19.111318-07:00 INFO shill[1151]: [INFO:openvpn_driver.cc(987)] OnReconnecting(0)
2018-04-11T16:06:19.111486-07:00 INFO shill[1151]: [INFO:openvpn_management_server.cc(405)] Client waiting for hold release.
2018-04-11T16:06:19.111515-07:00 INFO shill[1151]: [INFO:openvpn_management_server.cc(154)] Releasing hold.
2018-04-11T16:06:19.111870-07:00 WARNING openvpn[7661]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2018-04-11T16:06:19.111915-07:00 INFO shill[1151]: [INFO:openvpn_management_server.cc(417)] SUCCESS: hold release succeeded
2018-04-11T16:06:19.244944-07:00 ERR openvpn[7661]: RESOLVE: Cannot resolve host address: openvpn256:1194 (Name or service not known)
2018-04-11T16:06:19.379441-07:00 ERR openvpn[7661]: RESOLVE: Cannot resolve host address: openvpn256:1194 (Name or service not known)
2018-04-11T16:06:19.379478-07:00 WARNING openvpn[7661]: Could not determine IPv4/IPv6 protocol
2018-04-11T16:06:19.379780-07:00 NOTICE openvpn[7661]: SIGUSR1[soft,init_instance] received, process restarting
The secondary issue is that it keeps retrying over and over again for a minute until it hits the timeout, rather than sending a sensible error message back to the user. This is a KI which I intend to fix.
It looks like there is no default search domain on this network, so you would need to provide a FQDN to OpenVPN:
"/device/wlan0": {
"Address": "f894c21e8bba",
"BgscanMethod": "simple",
"BgscanShortInterval": 30,
"BgscanSignalThreshold": -62,
"ForceWakeToScanTimer": false,
"IPConfigs": {
"/ipconfig/wlan0_13_dhcp": {
"AcceptedHostname": "",
"Address": "<IPv4: 24>9",
"Broadcast": "<IPv4: 34>55",
"Dhcpv6Addresses": [ ],
"Dhcpv6DelegatedPrefixes": [ ],
"DomainName": "",
"Gateway": "<IPv4: 23>",
"LeaseDurationSeconds": 86400.0,
"Method": "dhcp",
"Mtu": 0,
"NameServers": [ "<IPv4: 23>" ],
"PeerAddress": "",
"Prefixlen": 24,
"SearchDomains": [ ],
"VendorEncapsulatedOptions": [ ],
"WebProxyAutoDiscoveryUrl": "",
"iSNSOptionData": [ ]
},
"/ipconfig/wlan0_14_ip": {
"AcceptedHostname": "",
"Address": "<IPv6: 13>",
"Broadcast": "",
"Dhcpv6Addresses": [ ],
"Dhcpv6DelegatedPrefixes": [ ],
"DomainName": "",
"Gateway": "<IPv6: 12>",
"LeaseDurationSeconds": 0.0,
"Method": "ipv6",
"Mtu": 0,
"NameServers": [ "<IPv6: 11>" ],
"PeerAddress": "",
"Prefixlen": 64,
"SearchDomains": [ ],
"VendorEncapsulatedOptions": [ ],
"WebProxyAutoDiscoveryUrl": "",
"iSNSOptionData": [ ]
}
},
Maybe this means that DHCP is no longer providing it, or maybe it means that CrOS is not setting it up correctly.
Reassigning since this doesn't look like a problem on the Chrome side.
,
Apr 12 2018
This is a different issue. I am re-closing this and opening new issue 832165 . (In general, old bugs, especially merged ones, shouldn't be re-opened unless we are certain it is the exact same issue and the fix did not work).
,
Apr 13 2018
Openvpn connection is fine. |
|||||||||||||||
►
Sign in to add a comment |
|||||||||||||||
Comment 1 by steve...@chromium.org
, Mar 1 2018Owner: steve...@chromium.org
Status: Started (was: Untriaged)