Is there a way log EAP NAK reason with linelog?
Hi, I am using the "linelog" module for "accept" and "reject" logs with the format and fields I need. It works pretty well for me. You can find the template I use below. Access-Reject = "Rejected User: [%{User-Name}] inner_username: [%{session-state:ETU-Inner-User-Name}] event_timestamp: [%T] calling_station_id: [%{Calling-Station-Id}] called_station_id: [%{Called-Station-Id}] ssid: [%{Called-Station-SSID}] srcip: [%{Packet-Src-IP-Address}] nas_name: [%{NAS-Identifier}] client_location: [%{ETU-Client-Location}] failure_msg: [%{Module-Failure-Message}] inner_failure_msg: [%{session-state:ETU-Inner-Module-Failure-Message}] etu_service: [%{ETU-Radius-Service-Name}] auth_type: [%{control:Auth-Type}] eap_type: [%{EAP-Type}] tls_version: [%{&session-state:TLS-Session-Version}]" I only support EAP-PEAP and EAP-TTLS for EAP types. Is there a way to log the reason for EAP NAK while using "linelog"? For now, "%{EAP-Type}" attribute prints "NAK" but could not find any additional attribute for the NAK reason? If there is no default attribute, I can set a custom one with "unlang" somewhere, so I can use it in "linelog" template? Regards Rahman Duran
On Jul 11, 2024, at 6:36 AM, Rahman DURAN via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
I only support EAP-PEAP and EAP-TTLS for EAP types. Is there a way to log the reason for EAP NAK while using "linelog"? For now, "%{EAP-Type}" attribute prints "NAK" but could not find any additional attribute for the NAK reason? If there is no default attribute, I can set a custom one with "unlang" somewhere, so I can use it in "linelog" template?
If the client sends NAK, my $0.02 is to just log the EAP-Message from the request. The trailing bytes of EAP-Message are the various EAP types that the client is trying to use. Actually decoding the NAK values will be a bit more work. Alan DeKok.
Hi Allan, Thanks for the hint. I added "EAP-Message" field to linelog template and started logging. What I see is, for most of the users "%{Module-Failure-Message}" attribute tells me what is going wrong when eap-type is NAK. Like; - eap.etu: rlm_eap (eap.etu): No EAP session matching state 0x30004a5b31035f45 - or, eap.etu: No mutually acceptable types found This is all good, but for some clients, eap type is NAK but inner or outer "%{Module-Failure-Message}" does not log anything. Here is an example log for empty "%{Module-Failure-Message}": freeradius-etu-freeradius-etu-co Rejected User: [xxxx@erzurum.edu.tr] inner_username: [] event_timestamp: [2024-07-12-06.26.40.708160] calling_station_id: [xxx] called_station_id: [xxx:eduroam] ssid: [eduroam] srcip: [172.xxx] nas_name: [xxxx] client_location: [] failure_msg: [] inner_failure_msg: [] etu_service: [etu_service_eduroam_local] auth_type: [eap.etu] eap_type: [NAK] tls_version: [] eap_message: [0x020300060300] I tried to find an online eap message decoder but failed to find one. Does "0x020300060300" with EAP type NAK gives any hints? Thanks for your help. Rahman Duran Alan DeKok <aland@deployingradius.com>, 11 Tem 2024 Per, 19:21 tarihinde şunu yazdı:
On Jul 11, 2024, at 6:36 AM, Rahman DURAN via Freeradius-Users < freeradius-users@lists.freeradius.org> wrote:
I only support EAP-PEAP and EAP-TTLS for EAP types. Is there a way to log the reason for EAP NAK while using "linelog"? For now, "%{EAP-Type}" attribute prints "NAK" but could not find any additional attribute for the NAK reason? If there is no default attribute, I can set a custom one with "unlang" somewhere, so I can use it in "linelog" template?
If the client sends NAK, my $0.02 is to just log the EAP-Message from the request. The trailing bytes of EAP-Message are the various EAP types that the client is trying to use.
Actually decoding the NAK values will be a bit more work.
Alan DeKok.
Hi again, After doing some packet capture and reading some EAPoL docs here is what I found: 1. Access request sent to freeradius for the problematic client: AVP: t=EAP-Message(79) l=29 Last Segment[1] Type: 79 Length: 29 EAP fragment: 0201001b016d2e747572616e4065727a7572756d2e6564752e7472 Extensible Authentication Protocol Code: Response (2) Id: 1 Length: 27 Type: Identity (1) Identity: xxxx@erzurum.edu.tr 2. Freeradius responds with a challenge with EAP-PEAP AVP: t=EAP-Message(79) l=8 Last Segment[1] Type: 79 Length: 8 EAP fragment: 010200061920 Extensible Authentication Protocol Code: Request (1) Id: 2 Length: 6 Type: Protected EAP (EAP-PEAP) (25) EAP-TLS Flags: 0x20 0... .... = Length Included: False .0.. .... = More Fragments: False ..1. .... = Start: True .... .000 = Version: 0 3. Problematic client does not like it and send a request with a "legacy nak" with desired eap type "EAP-TTLS" (which freeradius also supports) AVP: t=EAP-Message(79) l=8 Last Segment[1] Type: 79 Length: 8 EAP fragment: 020200060315 Extensible Authentication Protocol Code: Response (2) Id: 2 Length: 6 Type: Legacy Nak (Response Only) (3) Desired Auth Type: Tunneled TLS EAP (EAP-TTLS) (21) 4. Freeradius responds with another challenge with EAP-TTLS as client requested AVP: t=EAP-Message(79) l=8 Last Segment[1] Type: 79 Length: 8 EAP fragment: 010300061520 Extensible Authentication Protocol Code: Request (1) Id: 3 Length: 6 Type: Tunneled TLS EAP (EAP-TTLS) (21) EAP-TLS Flags: 0x20 0... .... = Length Included: False .0.. .... = More Fragments: False ..1. .... = Start: True .... .000 = Version: 0 5. Client seems to not accept EAP-TTLS type even it asked itself and send another NAK with desired type "unkown" AVP: t=EAP-Message(79) l=8 Last Segment[1] Type: 79 Length: 8 EAP fragment: 020300060300 Extensible Authentication Protocol Code: Response (2) Id: 3 Length: 6 Type: Legacy Nak (Response Only) (3) Desired Auth Type: Unknown (0) 6. Freeradius rejects the clients: AVP: t=EAP-Message(79) l=6 Last Segment[1] Type: 79 Length: 6 EAP fragment: 04030004 Extensible Authentication Protocol Code: Failure (4) Id: 3 Length: 4 So it seems the problem is in the client but It should be easy for us if "%{Module-Failure-Message}" prints something like "Client sent NAK, rejecting client". Or if there is a way to make Freeradius to log this kind of situations. Regards, Rahman Duran Bilgi İşlem Daire Başkanlığı Erzurum Teknik Üniversitesi 444 5 388 - 2730 Rahman DURAN <rahman.duran@erzurum.edu.tr>, 12 Tem 2024 Cum, 09:30 tarihinde şunu yazdı:
Hi Allan,
Thanks for the hint. I added "EAP-Message" field to linelog template and started logging. What I see is, for most of the users "%{Module-Failure-Message}" attribute tells me what is going wrong when eap-type is NAK. Like; - eap.etu: rlm_eap (eap.etu): No EAP session matching state 0x30004a5b31035f45 - or, eap.etu: No mutually acceptable types found
This is all good, but for some clients, eap type is NAK but inner or outer "%{Module-Failure-Message}" does not log anything.
Here is an example log for empty "%{Module-Failure-Message}":
freeradius-etu-freeradius-etu-co Rejected User: [xxxx@erzurum.edu.tr] inner_username: [] event_timestamp: [2024-07-12-06.26.40.708160] calling_station_id: [xxx] called_station_id: [xxx:eduroam] ssid: [eduroam] srcip: [172.xxx] nas_name: [xxxx] client_location: [] failure_msg: [] inner_failure_msg: [] etu_service: [etu_service_eduroam_local] auth_type: [eap.etu] eap_type: [NAK] tls_version: [] eap_message: [0x020300060300]
I tried to find an online eap message decoder but failed to find one. Does "0x020300060300" with EAP type NAK gives any hints?
Thanks for your help.
Rahman Duran
Alan DeKok <aland@deployingradius.com>, 11 Tem 2024 Per, 19:21 tarihinde şunu yazdı:
On Jul 11, 2024, at 6:36 AM, Rahman DURAN via Freeradius-Users < freeradius-users@lists.freeradius.org> wrote:
I only support EAP-PEAP and EAP-TTLS for EAP types. Is there a way to log the reason for EAP NAK while using "linelog"? For now, "%{EAP-Type}" attribute prints "NAK" but could not find any additional attribute for the NAK reason? If there is no default attribute, I can set a custom one with "unlang" somewhere, so I can use it in "linelog" template?
If the client sends NAK, my $0.02 is to just log the EAP-Message from the request. The trailing bytes of EAP-Message are the various EAP types that the client is trying to use.
Actually decoding the NAK values will be a bit more work.
Alan DeKok.
On Jul 12, 2024, at 3:39 AM, Rahman DURAN via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
So it seems the problem is in the client but It should be easy for us if "%{Module-Failure-Message}" prints something like "Client sent NAK, rejecting client". Or if there is a way to make Freeradius to log this kind of situations.
See src/modules/rlm_eap/eap.c and function eap_process_nak() It already prints out a bunch of debug messages: REDEBUG(...). Those messages should make it into Module-Failure-Message, as they're error messages. Alan DeKok.
Hi Alan, I am using 3.2.5 in a docker container. It seems there is no "eap_process_nak()" function in 3.2.x branch: https://github.com/FreeRADIUS/freeradius-server/blob/v3.2.x/src/modules/rlm_... Master branch has that function which I suppose it is v4 code base. Regards, Rahman Duran Alan DeKok <aland@deployingradius.com>, 12 Tem 2024 Cum, 14:09 tarihinde şunu yazdı:
On Jul 12, 2024, at 3:39 AM, Rahman DURAN via Freeradius-Users < freeradius-users@lists.freeradius.org> wrote:
So it seems the problem is in the client but It should be easy for us if "%{Module-Failure-Message}" prints something like "Client sent NAK, rejecting client". Or if there is a way to make Freeradius to log this kind of situations.
See src/modules/rlm_eap/eap.c and function eap_process_nak()
It already prints out a bunch of debug messages: REDEBUG(...). Those messages should make it into Module-Failure-Message, as they're error messages.
Alan DeKok.
On Jul 12, 2024, at 8:44 AM, Rahman DURAN <rahman.duran@erzurum.edu.tr> wrote:
Hi Alan,
I am using 3.2.5 in a docker container. It seems there is no "eap_process_nak()" function in 3.2.x branch: https://github.com/FreeRADIUS/freeradius-server/blob/v3.2.x/src/modules/rlm_...
Look at eap.c, not rlm_eap.c. Alan DeKok.
Sorry, my bad :) So, this line seems to populate %{Module-Failure-Message} as I see logs with this message: REDEBUG("No mutually acceptable types found"); But for NAK with Auth type "0", this line is different debug command: RDEBUG("Peer NAK'd indicating it is not willing to continue "); Is "RDEBUG()" a typo or does it have another meaning? Maybe this line is the reason why this condition does not set "%{Module-Failure-Message}"? The file also has "RDEBUG2()" lines for other "NAK" control conditions. Sorry for all the questions but I am not a c programmer. Thanks Rahman Duran Bilgi İşlem Daire Başkanlığı Erzurum Teknik Üniversitesi 444 5 388 - 2730 Alan DeKok <aland@deployingradius.com>, 12 Tem 2024 Cum, 15:47 tarihinde şunu yazdı:
On Jul 12, 2024, at 8:44 AM, Rahman DURAN <rahman.duran@erzurum.edu.tr> wrote:
Hi Alan,
I am using 3.2.5 in a docker container. It seems there is no
"eap_process_nak()" function in 3.2.x branch: https://github.com/FreeRADIUS/freeradius-server/blob/v3.2.x/src/modules/rlm_...
Look at eap.c, not rlm_eap.c.
Alan DeKok.
participants (2)
-
Alan DeKok -
Rahman DURAN