eap_ttls: ERROR: TLS Alert write:fatal:bad record mac
Hey guys, After a random interval (hours) our wifi clients gets disconnected after this log entry: ``` May 24 09:28:15 gra1-radius-01 : (205) Login incorrect (eap_ttls: TLS Alert write:fatal:bad record mac): [jolt] (from client Flattr port 85 cli 784f434d22ba) May 24 09:28:15 gra1-radius-01 : (205) eap_ttls: ERROR: TLS Alert write:fatal:bad record mac ``` This is on Alpine 3.9 with freeradius-eap-3.0.17-r5, and openssl-1.1.1b-r1. This is my first time setting this up, so bear with me. I'm running this together with an Asus router with EAP-TTLS and having mainly macbooks in this office. I have tried to search for others with this issue, but can't find much that seems related, I have set `tls_max_version = "1.2"` (to not trigger any tls1.3 bugs) but the issue still occurs. ## Output of ``[radiusd|freeradius] -fxx -l stdout`` if using eg RADIUS with TLS) ```text Waking up in 0.3 seconds. Thread 4 got semaphore Thread 4 handling request 231, (47 handled so far) (231) Received Access-Request Id 2 from 172.16.48.214:48268 to 172.16.54.20:1812 length 197 (231) User-Name = "jolt" (231) NAS-IP-Address = 172.16.48.214 (231) Called-Station-Id = "40b076368a34" (231) Calling-Station-Id = "784f434d22ba" (231) NAS-Identifier = "40b076368a34" (231) NAS-Port = 85 (231) Framed-MTU = 1400 (231) State = 0x63de82e165d997993bc43b07e7488f96 (231) NAS-Port-Type = Wireless-802.11 (231) EAP-Message = 0x020700431580000000391703030034e3e40e58ae7f7295d08781537dec10239ab8dc0c805e653756f82652fbb22f2840139d3800015443f177ff4266a1afcafaf4f27a (231) Message-Authenticator = 0x4ebdb0708a803b03cc27cd1f666e128a (231) session-state: No cached attributes (231) # Executing section authorize from file /etc/raddb/sites-enabled/default (231) authorize { (231) auth_log: EXPAND /var/log/radius/radacct/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/auth-detail-%Y%m%d (231) auth_log: --> /var/log/radius/radacct/172.16.48.214/auth-detail-20190528 (231) auth_log: /var/log/radius/radacct/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/auth-detail-%Y%m%d expands to /var/log/radius/radacct/172.16.48.214/auth-detail-20190528 (231) auth_log: EXPAND %t (231) auth_log: --> Tue May 28 09:27:49 2019 (231) [auth_log] = ok (231) eap: Peer sent EAP Response (code 2) ID 7 length 67 (231) eap: Continuing tunnel setup (231) [eap] = ok (231) } # authorize = ok (231) Found Auth-Type = eap (231) # Executing group from file /etc/raddb/sites-enabled/default (231) authenticate { (231) eap: Expiring EAP session with state 0x7833efcb7832e926 (231) eap: Finished EAP session with state 0x63de82e165d99799 (231) eap: Previous EAP request found for state 0x63de82e165d99799, released from the list (231) eap: Peer sent packet with method EAP TTLS (21) (231) eap: Calling submodule eap_ttls to process data (231) eap_ttls: Authenticate (231) eap_ttls: Continuing EAP-TLS (231) eap_ttls: Peer indicated complete TLS record size will be 57 bytes (231) eap_ttls: Got complete TLS record (57 bytes) (231) eap_ttls: [eaptls verify] = length included (231) eap_ttls: >>> send TLS 1.2 [length 0002] (231) eap_ttls: ERROR: TLS Alert write:fatal:bad record mac (231) eap_ttls: SSL_read Error (231) eap_ttls: ERROR: Error in fragmentation logic (231) eap_ttls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1408F119:SSL routines:ssl3_get_record:decryption failed or bad record mac (231) eap_ttls: ERROR: System call (I/O) error (-1) (231) eap_ttls: ERROR: [eaptls process] = fail (231) eap: ERROR: Failed continuing EAP TTLS (21) session. EAP sub-module failed (231) eap: Sending EAP Failure (code 4) ID 7 length 4 (231) eap: Failed in EAP select (231) [eap] = invalid (231) } # authenticate = invalid (231) Failed to authenticate the user (231) Using Post-Auth-Type Reject (231) # Executing group from file /etc/raddb/sites-enabled/default (231) Post-Auth-Type REJECT { (231) attr_filter.access_reject: EXPAND %{User-Name} (231) attr_filter.access_reject: --> jolt (231) attr_filter.access_reject: Matched entry DEFAULT at line 11 (231) [attr_filter.access_reject] = updated (231) policy remove_reply_message_if_eap { (231) if (&reply:EAP-Message && &reply:Reply-Message) { (231) if (&reply:EAP-Message && &reply:Reply-Message) -> FALSE (231) else { (231) [noop] = noop (231) } # else = noop (231) } # policy remove_reply_message_if_eap = noop (231) } # Post-Auth-Type REJECT = updated (231) Delaying response for 1.000000 seconds Thread 4 waiting to be assigned a request Waking up in 0.6 seconds. (231) Sending delayed response (231) Sent Access-Reject Id 2 from 172.16.54.20:1812 to 172.16.48.214:48268 length 44 (231) EAP-Message = 0x04070004 (231) Message-Authenticator = 0x00000000000000000000000000000000 Waking up in 3.9 seconds. (231) Cleaning up request packet ID 2 with timestamp +330184 Ready to process requests Waking up in 0.3 seconds. Thread 3 got semaphore Thread 3 handling request 232, (47 handled so far) ``` Any guesses? -- Fredrik Lundhag wire.com <http://wire.com/>: @jolt
On Jun 1, 2019, at 5:57 AM, Fredrik Lundhag <fredrik@flattr.com> wrote:
After a random interval (hours) our wifi clients gets disconnected after this log entry:
``` May 24 09:28:15 gra1-radius-01 : (205) Login incorrect (eap_ttls: TLS Alert write:fatal:bad record mac): [jolt] (from client Flattr port 85 cli 784f434d22ba) May 24 09:28:15 gra1-radius-01 : (205) eap_ttls: ERROR: TLS Alert write:fatal:bad record mac ```
Some magic crypto parameter is wrong. :( That's the best non-technical explanation. The message is being produced by FreeRADIUS (via OpenSSL), when it tries to decode the packet from the client. It means that the packet is bad, and that OpenSSL won't continue to run the TLS setup. There really isn't anything you can do here. Just have the user try again.
I have tried to search for others with this issue, but can't find much that seems related, I have set `tls_max_version = "1.2"` (to not trigger any tls1.3 bugs) but the issue still occurs.
FreeRADIUS doesn't use TLS 1.3. And the EAP-TLS transports for TLS 1.3 aren't yet defined. So no supplicant on the market implements TLS 1.3. Alan DeKok.
On 1 Jun 2019, at 14:04, Alan DeKok <aland@deployingradius.com> wrote:
Some magic crypto parameter is wrong. :( That's the best non-technical explanation.
The message is being produced by FreeRADIUS (via OpenSSL), when it tries to decode the packet from the client. It means that the packet is bad, and that OpenSSL won't continue to run the TLS setup.
There really isn't anything you can do here. Just have the user try again.
Ah, bummer. Thanks for your help, I've been going crazy trying to debug this. I have seen some VPN logs complaining about bad packets, (the auth server is located separately from the access point, so I guess that is it then). Thank you! -Fredrik -- Wire.com: @jolt
participants (2)
-
Alan DeKok -
Fredrik Lundhag