Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

provision an IoT Edge for Linux on Windows: Failed to do TLS Handshake, Connection Attempt Timed #7192

Open
tkudya opened this issue Jan 5, 2024 · 6 comments

Comments

@tkudya
Copy link

tkudya commented Jan 5, 2024

Provide a general summary of the issue in the Title above
-->

Expected Behavior

Tell us what should happen

Current Behavior

Trying to provision an IOT Device using private endpoints. I have configured them private endpoints in DNS and also inside the VM using our internal DNS. Able to contact all the address currently internally
Currently provisioning using x509 and the command completes successfully with "Ok" at the end but there is no connection

Output of iotedge check

Configuration checks (aziot-identity-service)

√ keyd configuration is well-formed - OK
√ certd configuration is well-formed - OK
√ tpmd configuration is well-formed - OK
√ identityd configuration is well-formed - OK
√ daemon configurations up-to-date with config.toml - OK
√ identityd config toml file specifies a valid hostname - OK
× aziot-identity-service package is up-to-date - Error
could not query https://raw.githubusercontent.com/Azure/azure-iotedge/main/latest-aziot-identity-service.json for latest available version
‼ host time is close to reference time - Warning
Could not query NTP server
√ production readiness: identity certificates expiry - OK
√ preloaded certificates are valid - OK
√ keyd is running - OK
√ certd is running - OK
√ identityd is running - OK
√ read all preloaded certificates from the Certificates Service - OK
√ read all preloaded key pairs from the Keys Service - OK
√ check all EST server URLs utilize HTTPS - OK
√ ensure all preloaded certificates match preloaded private keys with the same ID - OK

Connectivity checks (aziot-identity-service)

× host can connect to and perform TLS handshake with iothub AMQP port - Error
Failed to do TLS Handshake, Connection Attempt Timed out in 70 Seconds
× host can connect to and perform TLS handshake with iothub HTTPS / WebSockets port - Error
Failed to do TLS Handshake, Connection Attempt Timed out in 70 Seconds
× host can connect to and perform TLS handshake with iothub MQTT port - Error
Failed to do TLS Handshake, Connection Attempt Timed out in 70 Seconds

Configuration checks

√ aziot-edged configuration is well-formed - OK
√ configuration up-to-date with config.toml - OK
√ container engine is installed and functional - OK
√ configuration has correct URIs for daemon mgmt endpoint - OK
× aziot-edge package is up-to-date - Error
Error while fetching latest versions of edge components: HTTP request timed out
√ container time is close to host time - OK
√ DNS server - OK
‼ production readiness: logs policy - Warning
Container engine is not configured to rotate module logs which may cause it run out of disk space.
Please see https://aka.ms/iotedge-prod-checklist-logs for best practices.
You can ignore this warning if you are setting log policy per module in the Edge deployment.
× production readiness: Edge Agent's storage directory is persisted on the host filesystem - Error
Could not check current state of edgeAgent container
× production readiness: Edge Hub's storage directory is persisted on the host filesystem - Error
Could not check current state of edgeHub container
√ Agent image is valid and can be pulled from upstream - OK
√ proxy settings are consistent in aziot-edged, aziot-identityd, moby daemon and config.toml - OK

Connectivity checks

× container on the default network can connect to upstream AMQP port - Error
Container on the default network could not connect to privatelink.azureiotcentral.com:5671
× container on the default network can connect to upstream HTTPS / WebSockets port - Error
Container on the default network could not connect to privatelink.azureiotcentral.com:443
× container on the IoT Edge module network can connect to upstream AMQP port - Error
Container on the azure-iot-edge network could not connect to privatelink.azureiotcentral.com:5671
× container on the IoT Edge module network can connect to upstream HTTPS / WebSockets port - Error
Container on the azure-iot-edge network could not connect to privatelink.azureiotcentral.com:443
23 check(s) succeeded.
2 check(s) raised warnings. Re-run with --verbose for more details.
11 check(s) raised errors. Re-run with --verbose for more details.
2 check(s) were skipped due to errors from other checks. Re-run with --verbose for more details.

Click here

Runtime Versions

  • aziot-edged [run iotedge version]: iotedge 1.4.20

Logs

aziot-edged logs

<Paste here between the triple backticks>


## Additional Information
Please provide any additional information that may be helpful in understanding the issue.
![image](https://github.com/Azure/iotedge/assets/78653328/8de05c60-4919-4a94-8e95-5b40e5450fca)
@jlian
Copy link
Member

jlian commented Jan 9, 2024

With this

could not query https://raw.githubusercontent.com/Azure/azure-iotedge/main/latest-aziot-identity-service.json for latest available version

It looks like there's no internet connectivity at all, not just private endpoints. I think we need EFLOW folks to help troubleshoot the networking env. Transferring

@jlian
Copy link
Member

jlian commented Jan 9, 2024

@Azure/iotedge-eflow and @josephknierman (on-call) can you please help take a look and/or transfer the issue?

@jagadishmurugan
Copy link

@tkudya, can you try nslookup privatelink.azureiotcentral.com and check if it resolves? If not, can you check EFLOW VM has connectivity - try ping from EFLOW-VM to host to confirm traffic is not blocked within the VM...

@tkudya
Copy link
Author

tkudya commented Jan 16, 2024

@jagadishmurugan NSLOOKUP and ping return the right internal ip address from the Eflow-VM and from the host device.

@jlian
Copy link
Member

jlian commented Jan 23, 2024

@jagadishmurugan any thoughts?

@jlian
Copy link
Member

jlian commented Jan 30, 2024

@Azure/iotedge-eflow and @jagadishmurugan do you think this might be a proxy issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants