local error: tls: bad record MAC

[BurntRouter]

Background (please complete the following information):

• Panel or Daemon: Daemon
• Version of Panel/Daemon: 1.0.1
• Server's OS: Debian 10
• Your Computer's OS & Browser: OSx Catalina/Windows 10 | Safari/Firefox

Describe the bug
There seems to be some kind of bug with TLS on the daemon where it is returning the error
"TLS handshake error from (panel IP address):54724: local error: tls: bad record MAC"
I have attempted to reissue the certs. Reinstall Wings. Tried different NICs. Performed local SSL tests to ensure no malformation of packets over the network. I've seen multiple users in the Discord with this error and none have resolved it. Only appears on version 1.0 or higher since it is a "Go" specific error.

To Reproduce
Unknown, happens after a few days without modification to the box in any way.

Expected behavior
No output of error as the exchange should good.

[DaneEveritt]

Can you please provide more context surrounding the error, rather than just the one error line? (Specifically, please provide more lines before and after from the log).

Edit: per kubernetes/minikube#7313 (comment), rclone/rclone#1774 (comment)

I did some research on the situation, and it seems to come down to a couple of possibilities:

• A faulty network card driver. Often recoverable by turning off hardware preload features.
• Anti-virus software intercepting outgoing SSL packets
• Network MTU misconfiguration

From everything I've seen this is something completely out of the control of Pterodactyl.

[BurntRouter]

 INFO: [Oct 15 10:51:47.144] creating new server object from API response server=46c11588-8b63-4c03-82f9-54d157b34476
 INFO: [Oct 15 10:51:47.144] creating new server object from API response server=852ac61e-8029-4587-959e-450971edeecd
 INFO: [Oct 15 10:51:47.145] registering event listeners: console, state, resources... server=46c11588-8b63-4c03-82f9-54d157b34476
 INFO: [Oct 15 10:51:47.146] registering event listeners: console, state, resources... server=852ac61e-8029-4587-959e-450971edeecd
DEBUG: [Oct 15 10:51:47.147] syncing stop configuration with configured docker environment server=46c11588-8b63-4c03-82f9-54d157b34476
DEBUG: [Oct 15 10:51:47.148] syncing stop configuration with configured docker environment server=852ac61e-8029-4587-959e-450971edeecd
 INFO: [Oct 15 10:51:47.149] finished processing server configurations duration=5.705226ms
 INFO: [Oct 15 10:51:47.158] loaded configuration for server server=46c11588-8b63-4c03-82f9-54d157b34476
 INFO: [Oct 15 10:51:47.158] loaded configuration for server server=852ac61e-8029-4587-959e-450971edeecd
 INFO: [Oct 15 10:51:47.160] configuring server environment and restoring to previous state server=852ac61e-8029-4587-959e-450971edeecd
 INFO: [Oct 15 10:51:47.160] configuring server environment and restoring to previous state server=46c11588-8b63-4c03-82f9-54d157b34476
 INFO: [Oct 15 10:51:47.166] detected server is running, re-attaching to process... server=46c11588-8b63-4c03-82f9-54d157b34476
 INFO: [Oct 15 10:51:47.166] detected server is running, re-attaching to process... server=852ac61e-8029-4587-959e-450971edeecd
DEBUG: [Oct 15 10:51:47.187] saw server status change event server=852ac61e-8029-4587-959e-450971edeecd status=running
DEBUG: [Oct 15 10:51:47.192] starting resource polling for container container_id=852ac61e-8029-4587-959e-450971edeecd
DEBUG: [Oct 15 10:51:47.210] saw server status change event server=46c11588-8b63-4c03-82f9-54d157b34476 status=running
 INFO: [Oct 15 10:51:47.215] configuring internal webserver host_address=0.0.0.0 host_port=8080 use_auto_tls=false use_ssl=true
DEBUG: [Oct 15 10:51:47.215] starting resource polling for container container_id=46c11588-8b63-4c03-82f9-54d157b34476
 INFO: [Oct 15 10:51:47.216] sftp subsystem listening for connections host=0.0.0.0 port=2022
2020/10/15 10:51:52 http: TLS handshake error from xxx.xxx.xxx.58:54592: local error: tls: bad record MAC
2020/10/15 10:51:52 http: TLS handshake error from xxx.xxx.xxx.58:54594: local error: tls: bad record MAC

I've confirmed there's not any faulty hardware or drivers through extensive testing inside and outside the OS. Turned off hardware preload to be sure with no repair. There's no security issue. And the MTU is fine. I reported it since it's a Go specific error and doesn't provide enough information

[DaneEveritt]

To the best of my knowledge and googling this is an issue with the Go std lib, and not something I can resolve with Pterodactyl. If anyone has a specific answer that shows there is something I can do to address this I'm all ears, but until that point I'm going to close this because I:

a.) Have no clue at all how to even debug this.
b.) Truly don't think it is anything specific with Pterodactyl.
c.) Cannot reproduce the issue.
d.) Have run out of things to search for online and the only things I've found point to hardware or network issues, and not configuration settings in the code I'm writing.

[alliraine]

I had this issue as well. Turned out I needed to renew my SSL cert.

[Kurounin]

Encountered this issue as well on a new installation.
Solved by changing api.ssl.cert in /etc/pterodactyl/config.yml from letsencrypt-cert.pem to letsencrypt-fullchain.pem

[ikbenignace]

I have this problem suddenly, I renewed the SSL but nothing works, it's the connection with wings.

[BurntRouter]

I have this problem suddenly, I renewed the SSL but nothing works, it's the connection with wings.

I found out it was a network connection issue with the provider for the panel. I switched from OVH to DigialOcean and it started working fine

[StarScream159]

I also had this error. It was due to certbot updating to version 2+ whereby the default cert/key type is now ECDSA. pterodactyl/wings/nginx whatever doesn't like this cert/key combo type and seems to only work with RSA. Regenerating a new key with the --key-type rsa flag and using that cert/key works.

[MrX123123]

facing the same issue with a new installation v1.11.7. Running acme v3.0.7, --key-type is unknown. Does somebody found a solution?

[r59q]

I'm not sure if it will ever be useful, but I thought I'd chime in with some additional information.

I got the message

I went to systemctl status wings and saw

Jul 08 11:31:35 UBUNTU wings[1369568]: 2024/07/08 11:31:35 http: TLS handshake error from XXX.XXX.XXX.XXX:34288: tls: first record does not look like a TLS handshake

I had before experienced this where it was an outdated certificate, where certbot renew fixed the issue. However this time my certificate is not expired, and for some reason this only seems to be a problem on my laptop. I can access the server perfectly fine on my phone and desktop, so I'm not sure what the problem is.