Connection error with MySQL only if SSL Enabled: SQL_CONNECTION_FAILURE / Communications link failure

Hi, I’ve got a weird situation. We have a MariaDB database but have been using the MySQL connector with SSL disabled (not great). We would switch to MariaDB (which does work with SSL enabled) but there’s an issue with our bigger queries getting stuck on refresh that doesn’t happen with the MySQL datasource, so I’m trying to fix either of the two issues (I’ll open a separate topic for the other one).

We can connect successfully with SSL disabled, which seems to rule out any sort of firewall-related issues. Similarly, the MariaDB datasource can at least connect with SSL enabled, so it seems like a MySQL thing.

The error we from Quicksight when we validate the connection is: SQL_CONNECTION_FAILURE / Communications link failure The last packet successfully received from the server was 30 milliseconds ago. The last packet sent successfully to the server was 30 milliseconds ago.

On the server side, we see a message like this each time we try to validate the connection: Aborted connection 1334909 to db: ‘unconnected’ user: ‘unauthenticated’ host: ‘52.23.63.231’ (This connection closed normally without authentication)

Does anyone have any ideas on how to fix this or debug it? One thought I had was maybe that the list of ciphers supported by the MySQL client does not overlap with the ones supported by the server or something, but I don’t have any way to see what the client is trying to use. But that doesn’t make much sense given the error message anyway.

Also, it’s kinda weird that the client complains that it hasn’t received anything from the server in 30 milliseconds – that’s a really short time for a timeout, isn’t it?

Thanks in advance for any suggestions!

1 Like

Hello @perry_the_platypus, welcome to the QuickSight community!

I found some documentation that may be helpful in regards to debugging this issue. I will link it below. Let me know if any of it is relevant and what you are able to discover, then I can try to guide you further.

Testing SSL connection, QuickSight Q&A:

A community thread where a user experienced a similar issue, lots of input about establishing the datasource connection from our experts:

Documentation about establishing a connection between MariaDB and QuickSight. I didn’t find any direct reference regarding SSL though:

Also, for some more information, are you utilizing a VPC to establish the connection with QuickSight? A little more information about how you connected to the database could be helpful in debugging. Thank you!

Hi @DylanM, thanks for the response.

To answer your last question first, we are not using a VPC, and the database is not hosted on AWS. We have a firewall that whitelists the Quicksight IP range to allow the incoming connection.

I had a look through your links. I think our SSL config is fine, as we can connect to the DB using local clients in all sorts of different circumstances, and certificate validation works. Here’s our SSL-related variables:

mysql> show status like ‘ssl%’ \G
*************************** 1. row ***************************
Variable_name: Ssl_accept_renegotiates
Value: 0
*************************** 2. row ***************************
Variable_name: Ssl_accepts
Value: 335001
*************************** 3. row ***************************
Variable_name: Ssl_callback_cache_hits
Value: 0
*************************** 4. row ***************************
Variable_name: Ssl_cipher
Value: TLS_AES_256_GCM_SHA384
*************************** 5. row ***************************
Variable_name: Ssl_cipher_list
Value: TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:RSA-PSK-AES256-GCM-SHA384:DHE-PSK-AES256-GCM-SHA384:RSA-PSK-CHACHA20-POLY1305:DHE-PSK-CHACHA20-POLY1305:ECDHE-PSK-CHACHA20-POLY1305:AES256-GCM-SHA384:PSK-AES256-GCM-SHA384:PSK-CHACHA20-POLY1305:RSA-PSK-AES128-GCM-SHA256:DHE-PSK-AES128-GCM-SHA256:AES128-GCM-SHA256:PSK-AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:ECDHE-PSK-AES256-CBC-SHA384:ECDHE-PSK-AES256-CBC-SHA:SRP-RSA-AES-256-CBC-SHA:SRP-AES-256-CBC-SHA:RSA-PSK-AES256-CBC-SHA384:DHE-PSK-AES256-CBC-SHA384:RSA-PSK-AES256-CBC-SHA:DHE-PSK-AES256-CBC-SHA:AES256-SHA:PSK-AES256-CBC-SHA384:PSK-AES256-CBC-SHA:ECDHE-PSK-AES128-CBC-SHA256:ECDHE-PSK-AES128-CBC-SHA:SRP-RSA-AES-128-CBC-SHA:SRP-AES-128-CBC-SHA:RSA-PSK-AES128-CBC-SHA256:DHE-PSK-AES128-CBC-SHA256:RSA-PSK-AES128-CBC-SHA:DHE-PSK-AES128-CBC-SHA:AES128-SHA:PSK-AES128-CBC-SHA256:PSK-AES128-CBC-SHA
*************************** 6. row ***************************
Variable_name: Ssl_client_connects
Value: 0
*************************** 7. row ***************************
Variable_name: Ssl_connect_renegotiates
Value: 0
*************************** 8. row ***************************
Variable_name: Ssl_ctx_verify_depth
Value: 18446744073709551615
*************************** 9. row ***************************
Variable_name: Ssl_ctx_verify_mode
Value: 5
*************************** 10. row ***************************
Variable_name: Ssl_default_timeout
Value: 7200
*************************** 11. row ***************************
Variable_name: Ssl_finished_accepts
Value: 334981
*************************** 12. row ***************************
Variable_name: Ssl_finished_connects
Value: 0
*************************** 13. row ***************************
Variable_name: Ssl_server_not_after
Value: Jul 2 23:59:59 2024 GMT
*************************** 14. row ***************************
Variable_name: Ssl_server_not_before
Value: Apr 3 00:00:00 2024 GMT
*************************** 15. row ***************************
Variable_name: Ssl_session_cache_hits
Value: 0
*************************** 16. row ***************************
Variable_name: Ssl_session_cache_misses
Value: 0
*************************** 17. row ***************************
Variable_name: Ssl_session_cache_mode
Value: SERVER
*************************** 18. row ***************************
Variable_name: Ssl_session_cache_overflows
Value: 0
*************************** 19. row ***************************
Variable_name: Ssl_session_cache_size
Value: 128
*************************** 20. row ***************************
Variable_name: Ssl_session_cache_timeouts
Value: 0
*************************** 21. row ***************************
Variable_name: Ssl_sessions_reused
Value: 0
*************************** 22. row ***************************
Variable_name: Ssl_used_session_cache_entries
Value: 0
*************************** 23. row ***************************
Variable_name: Ssl_verify_depth
Value: 18446744073709551615
*************************** 24. row ***************************
Variable_name: Ssl_verify_mode
Value: 5
*************************** 25. row ***************************
Variable_name: Ssl_version
Value: TLSv1.3

I think the second link doesn’t apply to us, as that seems to be for someone connecting to an AWS RDS db. Our firewall setup seems fine.

And we can actually connect with SSL, but only using the MariaDB datatype. I understand that what we’re trying to do (using the MySQL connector to connect to a MariaDB server) is probably not advisable and maybe unsupported, but we’re just trying to find a way to make something work for us. For more background, here’s a link to the other question I posted about what happens when we use the MariaDB datasource client type - MariaDB custom query Dataset never finishes refresh, hangs

So I’d appreciate any help, but I also wouldn’t be surprised if this turns out to be something that’s just impossible due to subtle incompatibilities between the two database servers that have accumulated since they were forked.

1 Like

Hello @perry_the_platypus, I think it is likely an issue that the database is not compatible with QuickSight.

In order to see if there is a way we can resolve this issue, I would recommend filing a case with AWS Support where we can dive into the details so that we can help you further. Here are the steps to open a support case. If your company has someone who manages your AWS account, you might not have direct access to AWS Support and will need to raise an internal ticket to your IT team or whomever manages your AWS account. They should be able to open an AWS Support case on your behalf. I hope this helps!

Hello @perry_the_platypus, since we have not heard back from you with any follow-up questions, I will archive this topic. I will also tag it as a feature request for our support team, since it seems likely an issue with a database connection limitation. Hopefully the support team is able to help you further through your support case. Thank you!