Dear, Briefly, our scenario has 3 servers with FreeRadius 3.0.14. 2 institutions (ufjfteste.br and rnpteste.br) and 1 FLR (.br). On the institution level we run RadSec (embedded TCP/TLS in FreeRadius3) to communicate with our FLR, a radsecproxy. So, using this TLS communication, EAP does not work, but turning off it and doing the communication between all servers using only UDP (disabling RadSec at institutions and radsecproxy at FLR), all EAP methods works. To confirm it, if we turn on the TLS communication, we could only authenticate using 'radtest' (as we know, a simple authentication without EAP). We suspect that EAP messages are lost during the exchanging when TLS communication are enable. Do you have any ideia about it to help us? * Our real scenario here in Brazil is similar to this, with institutions using FreeRadius (today with radsecproxy) and the FLR using radsecproxy too. Now we are conducting this validations to update our infrastructure to use FreeRadius3 with RadSec in institution level, and maintaining radsecproxy in FLR. Thanks in advance, -- Luciano Fernandes da Rocha. Analista de Operações DAGSer - Diretoria Adjunta de Gestão de Serviços RNP – Rede Nacional de Ensino e Pesquisa Site:http://www.rnp.br e-mail:luciano.rocha@rnp.br Tel.:+55 61 3243-4389
On Jul 13, 2017, at 9:46 AM, Luciano Fernandes da Rocha <luciano.rocha@rnp.br> wrote:
Briefly, our scenario has 3 servers with FreeRadius 3.0.14. 2 institutions (ufjfteste.br and rnpteste.br) and 1 FLR (.br). On the institution level we run RadSec (embedded TCP/TLS in FreeRadius3) to communicate with our FLR, a radsecproxy. So, using this TLS communication, EAP does not work, but turning off it and doing the communication between all servers using only UDP (disabling RadSec at institutions and radsecproxy at FLR), all EAP methods works.
Please be clearer about "it doesn't work". What happens? What does the debug say?
To confirm it, if we turn on the TLS communication, we could only authenticate using 'radtest' (as we know, a simple authentication without EAP).
We suspect that EAP messages are lost during the exchanging when TLS communication are enable.
The server doesn't lose EAP messages.
Do you have any ideia about it to help us?
Read the debug output. Or, post it to the list. Nothing else will help. if it's too large to send on the list (~500K), send it to me off-list. Preferably gzip'd. Set up a proxy which uses RadSec to talk to a home server. Set up the home server with test certs and a test user. Use wpa_supplicant to send packets to the proxy. Then send ALL the debug output over. Alan DeKok.
not sure what you've done - I've used FreeRADIUS with native radsec connectivity to proxy EAP to remote servers (RADIATOR and radsecproxy) and to receive EAP from the same remote proxies. Would suggest, as Alan had said, to grab debug and check what the server is doing. its all quite clear what its doing (dont be overwhelmed by all the output, just read it step by step...) - there will be some very ovbious difference between the EAP and your radtest - likely to be related to action of server when packet has gone into inner-tunnel (which, I'm guessing it shouldnt be doing as its supposed to be proxied to remote site......) alan On 13 July 2017 at 15:23, Alan DeKok <aland@deployingradius.com> wrote:
On Jul 13, 2017, at 9:46 AM, Luciano Fernandes da Rocha <luciano.rocha@rnp.br> wrote:
Briefly, our scenario has 3 servers with FreeRadius 3.0.14. 2 institutions (ufjfteste.br and rnpteste.br) and 1 FLR (.br). On the institution level we run RadSec (embedded TCP/TLS in FreeRadius3) to communicate with our FLR, a radsecproxy. So, using this TLS communication, EAP does not work, but turning off it and doing the communication between all servers using only UDP (disabling RadSec at institutions and radsecproxy at FLR), all EAP methods works.
Please be clearer about "it doesn't work". What happens? What does the debug say?
To confirm it, if we turn on the TLS communication, we could only authenticate using 'radtest' (as we know, a simple authentication without EAP).
We suspect that EAP messages are lost during the exchanging when TLS communication are enable.
The server doesn't lose EAP messages.
Do you have any ideia about it to help us?
Read the debug output. Or, post it to the list. Nothing else will help.
if it's too large to send on the list (~500K), send it to me off-list. Preferably gzip'd.
Set up a proxy which uses RadSec to talk to a home server. Set up the home server with test certs and a test user. Use wpa_supplicant to send packets to the proxy.
Then send ALL the debug output over.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi I'm working with Luciano on eduroam BR and trying to solve this. I attached our debug files. 4 files: 1) debug-eapol-from-ujfteste-to-rnpteste - the client eapol running an auth test 2) debug-ufjfteste-FR3 - FreeRadius @ inst1/ufjfteste.br 3) debug-rnpteste-FR3 - FreeRadius @ inst1/rnpteste.br 4) debug-radsecproxy-FLR - radsecproxy @ federation level What caught my attention was this "error" on the local (institution) FreeRadius rlm_eap (EAP): No EAP session matching state 0xc6ab1049c7a90598 I can send debug file from radtest too, but I think this isn't necessary Thank you all --Edelberto Em 13-Jul-17 4:59 PM, Alan Buxey escreveu:
not sure what you've done - I've used FreeRADIUS with native radsec connectivity to proxy EAP to remote servers (RADIATOR and radsecproxy) and to receive EAP from the same remote proxies. Would suggest, as Alan had said, to grab debug and check what the server is doing. its all quite clear what its doing (dont be overwhelmed by all the output, just read it step by step...) - there will be some very ovbious difference between the EAP and your radtest - likely to be related to action of server when packet has gone into inner-tunnel (which, I'm guessing it shouldnt be doing as its supposed to be proxied to remote site......)
alan
On Jul 13, 2017, at 9:46 AM, Luciano Fernandes da Rocha <luciano.rocha@rnp.br> wrote:
Briefly, our scenario has 3 servers with FreeRadius 3.0.14. 2 institutions (ufjfteste.br and rnpteste.br) and 1 FLR (.br). On the institution level we run RadSec (embedded TCP/TLS in FreeRadius3) to communicate with our FLR, a radsecproxy. So, using this TLS communication, EAP does not work, but turning off it and doing the communication between all servers using only UDP (disabling RadSec at institutions and radsecproxy at FLR), all EAP methods works.
Please be clearer about "it doesn't work". What happens? What does the debug say?
To confirm it, if we turn on the TLS communication, we could only authenticate using 'radtest' (as we know, a simple authentication without EAP).
We suspect that EAP messages are lost during the exchanging when TLS communication are enable. The server doesn't lose EAP messages.
Do you have any ideia about it to help us? Read the debug output. Or, post it to the list. Nothing else will help.
if it's too large to send on the list (~500K), send it to me off-list. Preferably gzip'd.
Set up a proxy which uses RadSec to talk to a home server. Set up the home server with test certs and a test user. Use wpa_supplicant to send packets to the proxy.
Then send ALL the debug output over.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 13 July 2017 at 15:23, Alan DeKok <aland@deployingradius.com> wrote: - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Jul 13, 2017, at 4:50 PM, Edelberto Franco <esilva@midiacom.uff.br> wrote:
Hi
I'm working with Luciano on eduroam BR and trying to solve this. I attached our debug files. 4 files: 1) debug-eapol-from-ujfteste-to-rnpteste - the client eapol running an auth test 2) debug-ufjfteste-FR3 - FreeRadius @ inst1/ufjfteste.br 3) debug-rnpteste-FR3 - FreeRadius @ inst1/rnpteste.br 4) debug-radsecproxy-FLR - radsecproxy @ federation level
You don't say which server is doing what, or why. Is (1) sending to (2) which is proxying to (3) and then (4)? Describing the system would be helpful.
What caught my attention was this "error" on the local (institution) FreeRadius rlm_eap (EAP): No EAP session matching state 0xc6ab1049c7a90598
There's some telling logs in mpteste: (1) # Executing group from file /etc/freeradius/sites-enabled/default (1) Sent Access-Challenge Id 1 from 0.0.0.0:2083 to 200.130.15.23:33001 length 0 (1) EAP-Message = 0x010200061520 (1) Message-Authenticator = 0x00000000000000000000000000000000 (1) State = 0x161759b417154cb0f3b4952e04b41a4d (1) Proxy-State = 0x31 ... (2) Received Access-Request Id 2 from 200.130.15.23:33001 to 0.0.0.0:2083 length 464 (2) User-Name = "eduroam@rnpteste.br" ... (2) EAP-Message = 0x0202013315001603010128010001240303d2f5eea4fdbe3d97827f69579ce66256228d2985dafcc71333fe57a0d62fe0610000aac030c02cc028c024c014c00a00a500a300a1009f006b006a0069006800390038003700360088008700860085c032c02ec02ac026c00fc005009d003d00350084c02fc0 (2) State = 0x161759b417154cb0f3b4952e04b41a4d ... (3) Received Access-Request Id 3 from 200.130.15.23:33001 to 0.0.0.0:2083 length 464 (3) User-Name = "eduroam@rnpteste.br" (3) NAS-IP-Address = 127.0.0.1 (3) Calling-Station-Id = "02-00-00-00-00-01" (3) Framed-MTU = 1400 (3) NAS-Port-Type = Wireless-802.11 (3) Service-Type = Framed-User (3) Connect-Info = "CONNECT 11Mbps 802.11b" (3) EAP-Message = 0x0202013315001603010128010001240303d2f5eea4fdbe3d97827f69579ce66256228d2985dafcc71333fe57a0d62fe0610000aac030c02cc028c024c014c00a00a500a300a1009f006b006a0069006800390038003700360088008700860085c032c02ec02ac026c00fc005009d003d00350084c02fc0 (3) State = 0x161759b417154cb0f3b4952e04b41a4d (3) Message-Authenticator = 0x384c2741f7321ca2d8e8f78b9c0864b3 The server is sending a reply to packet 2, and then packet 3 is a retransmit of packet 2. That's wrong. The client should go on to the next packet. This is confirmed from the eapol_test packet: Attribute 24 (State) length=18 Value: 161759b417154cb0f3b4952e04b41a4d Attribute 80 (Message-Authenticator) length=18 Value: 67ecbe0e885a25686f87da3397222a19 Next RADIUS client retransmit in 3 seconds EAPOL: SUPP_BE entering state RECEIVE EAPOL: startWhen --> 0 STA 02:00:00:00:00:01: Resending RADIUS message (id=2) Packets are being lost somewhere. I have no idea where. I suggest setting up a test system. And don't use radsecproxy. The debug output is entirely useless. It doesn't show the packets going back and forth, so it is of *zero* help for debugging. Test the systems, and watch the packets going back and forth. Then READ THE DEBUG OUTPUT. If it's complaining that there's no EAP session for the State attribute... go back in the debug log looking for other references to that State. See if the packets are being retransmitted. See if the reply sent by the proxy is making it to the client. i.e. debug it. Trace the packets step by step through the system. It isn't hard. It just takes some effort to read the debug output. Alan DeKok.
Updating this threat to our colleagues... Changing the parameter "fragment_size" in tls block on "sites-enable/tls" file, packets were sent and received by FR3 servers (using 756 - less than 1024). But it is not an absolute truth, sometimes packets are lost and authA not happens. *needing more investigation. --E Em 14-Jul-17 10:29 AM, Alan DeKok escreveu:
On Jul 13, 2017, at 4:50 PM, Edelberto Franco <esilva@midiacom.uff.br> wrote:
Hi
I'm working with Luciano on eduroam BR and trying to solve this. I attached our debug files. 4 files: 1) debug-eapol-from-ujfteste-to-rnpteste - the client eapol running an auth test 2) debug-ufjfteste-FR3 - FreeRadius @ inst1/ufjfteste.br 3) debug-rnpteste-FR3 - FreeRadius @ inst1/rnpteste.br 4) debug-radsecproxy-FLR - radsecproxy @ federation level You don't say which server is doing what, or why. Is (1) sending to (2) which is proxying to (3) and then (4)?
Describing the system would be helpful.
What caught my attention was this "error" on the local (institution) FreeRadius rlm_eap (EAP): No EAP session matching state 0xc6ab1049c7a90598 There's some telling logs in mpteste:
(1) # Executing group from file /etc/freeradius/sites-enabled/default (1) Sent Access-Challenge Id 1 from 0.0.0.0:2083 to 200.130.15.23:33001 length 0 (1) EAP-Message = 0x010200061520 (1) Message-Authenticator = 0x00000000000000000000000000000000 (1) State = 0x161759b417154cb0f3b4952e04b41a4d (1) Proxy-State = 0x31 ... (2) Received Access-Request Id 2 from 200.130.15.23:33001 to 0.0.0.0:2083 length 464 (2) User-Name = "eduroam@rnpteste.br" ... (2) EAP-Message = 0x0202013315001603010128010001240303d2f5eea4fdbe3d97827f69579ce66256228d2985dafcc71333fe57a0d62fe0610000aac030c02cc028c024c014c00a00a500a300a1009f006b006a0069006800390038003700360088008700860085c032c02ec02ac026c00fc005009d003d00350084c02fc0 (2) State = 0x161759b417154cb0f3b4952e04b41a4d ... (3) Received Access-Request Id 3 from 200.130.15.23:33001 to 0.0.0.0:2083 length 464 (3) User-Name = "eduroam@rnpteste.br" (3) NAS-IP-Address = 127.0.0.1 (3) Calling-Station-Id = "02-00-00-00-00-01" (3) Framed-MTU = 1400 (3) NAS-Port-Type = Wireless-802.11 (3) Service-Type = Framed-User (3) Connect-Info = "CONNECT 11Mbps 802.11b" (3) EAP-Message = 0x0202013315001603010128010001240303d2f5eea4fdbe3d97827f69579ce66256228d2985dafcc71333fe57a0d62fe0610000aac030c02cc028c024c014c00a00a500a300a1009f006b006a0069006800390038003700360088008700860085c032c02ec02ac026c00fc005009d003d00350084c02fc0 (3) State = 0x161759b417154cb0f3b4952e04b41a4d (3) Message-Authenticator = 0x384c2741f7321ca2d8e8f78b9c0864b3
The server is sending a reply to packet 2, and then packet 3 is a retransmit of packet 2. That's wrong. The client should go on to the next packet.
This is confirmed from the eapol_test packet:
Attribute 24 (State) length=18 Value: 161759b417154cb0f3b4952e04b41a4d Attribute 80 (Message-Authenticator) length=18 Value: 67ecbe0e885a25686f87da3397222a19 Next RADIUS client retransmit in 3 seconds EAPOL: SUPP_BE entering state RECEIVE EAPOL: startWhen --> 0 STA 02:00:00:00:00:01: Resending RADIUS message (id=2)
Packets are being lost somewhere. I have no idea where.
I suggest setting up a test system. And don't use radsecproxy. The debug output is entirely useless. It doesn't show the packets going back and forth, so it is of *zero* help for debugging.
Test the systems, and watch the packets going back and forth. Then READ THE DEBUG OUTPUT. If it's complaining that there's no EAP session for the State attribute... go back in the debug log looking for other references to that State. See if the packets are being retransmitted. See if the reply sent by the proxy is making it to the client.
i.e. debug it. Trace the packets step by step through the system. It isn't hard. It just takes some effort to read the debug output.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Updating this thread* Em 15-Jul-17 11:02 AM, Edelberto Franco escreveu:
Updating this threat to our colleagues...
Changing the parameter "fragment_size" in tls block on "sites-enable/tls" file, packets were sent and received by FR3 servers (using 756 - less than 1024). But it is not an absolute truth, sometimes packets are lost and authA not happens.
*needing more investigation.
--E
Em 14-Jul-17 10:29 AM, Alan DeKok escreveu:
On Jul 13, 2017, at 4:50 PM, Edelberto Franco <esilva@midiacom.uff.br> wrote:
Hi
I'm working with Luciano on eduroam BR and trying to solve this. I attached our debug files. 4 files: 1) debug-eapol-from-ujfteste-to-rnpteste - the client eapol running an auth test 2) debug-ufjfteste-FR3 - FreeRadius @ inst1/ufjfteste.br 3) debug-rnpteste-FR3 - FreeRadius @ inst1/rnpteste.br 4) debug-radsecproxy-FLR - radsecproxy @ federation level You don't say which server is doing what, or why. Is (1) sending to (2) which is proxying to (3) and then (4)?
Describing the system would be helpful.
What caught my attention was this "error" on the local (institution) FreeRadius rlm_eap (EAP): No EAP session matching state 0xc6ab1049c7a90598 There's some telling logs in mpteste:
(1) # Executing group from file /etc/freeradius/sites-enabled/default (1) Sent Access-Challenge Id 1 from 0.0.0.0:2083 to 200.130.15.23:33001 length 0 (1) EAP-Message = 0x010200061520 (1) Message-Authenticator = 0x00000000000000000000000000000000 (1) State = 0x161759b417154cb0f3b4952e04b41a4d (1) Proxy-State = 0x31 ... (2) Received Access-Request Id 2 from 200.130.15.23:33001 to 0.0.0.0:2083 length 464 (2) User-Name = "eduroam@rnpteste.br" ... (2) EAP-Message = 0x0202013315001603010128010001240303d2f5eea4fdbe3d97827f69579ce66256228d2985dafcc71333fe57a0d62fe0610000aac030c02cc028c024c014c00a00a500a300a1009f006b006a0069006800390038003700360088008700860085c032c02ec02ac026c00fc005009d003d00350084c02fc0 (2) State = 0x161759b417154cb0f3b4952e04b41a4d ... (3) Received Access-Request Id 3 from 200.130.15.23:33001 to 0.0.0.0:2083 length 464 (3) User-Name = "eduroam@rnpteste.br" (3) NAS-IP-Address = 127.0.0.1 (3) Calling-Station-Id = "02-00-00-00-00-01" (3) Framed-MTU = 1400 (3) NAS-Port-Type = Wireless-802.11 (3) Service-Type = Framed-User (3) Connect-Info = "CONNECT 11Mbps 802.11b" (3) EAP-Message = 0x0202013315001603010128010001240303d2f5eea4fdbe3d97827f69579ce66256228d2985dafcc71333fe57a0d62fe0610000aac030c02cc028c024c014c00a00a500a300a1009f006b006a0069006800390038003700360088008700860085c032c02ec02ac026c00fc005009d003d00350084c02fc0 (3) State = 0x161759b417154cb0f3b4952e04b41a4d (3) Message-Authenticator = 0x384c2741f7321ca2d8e8f78b9c0864b3
The server is sending a reply to packet 2, and then packet 3 is a retransmit of packet 2. That's wrong. The client should go on to the next packet.
This is confirmed from the eapol_test packet:
Attribute 24 (State) length=18 Value: 161759b417154cb0f3b4952e04b41a4d Attribute 80 (Message-Authenticator) length=18 Value: 67ecbe0e885a25686f87da3397222a19 Next RADIUS client retransmit in 3 seconds EAPOL: SUPP_BE entering state RECEIVE EAPOL: startWhen --> 0 STA 02:00:00:00:00:01: Resending RADIUS message (id=2)
Packets are being lost somewhere. I have no idea where.
I suggest setting up a test system. And don't use radsecproxy. The debug output is entirely useless. It doesn't show the packets going back and forth, so it is of *zero* help for debugging.
Test the systems, and watch the packets going back and forth. Then READ THE DEBUG OUTPUT. If it's complaining that there's no EAP session for the State attribute... go back in the debug log looking for other references to that State. See if the packets are being retransmitted. See if the reply sent by the proxy is making it to the client.
i.e. debug it. Trace the packets step by step through the system. It isn't hard. It just takes some effort to read the debug output.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Jul 15, 2017, at 10:02 AM, Edelberto Franco <esilva@midiacom.uff.br> wrote:
Updating this threat to our colleagues...
Changing the parameter "fragment_size" in tls block on "sites-enable/tls" file, packets were sent and received by FR3 servers (using 756 - less than 1024). But it is not an absolute truth, sometimes packets are lost and authA not happens.
The TLS fragment size helps deal with EAPoL, where the ethernet MTU is less than 1536. When sending TLS over TCP (i.e. radsec), there is no need for fragmentation, and no need for changing the fragment size. My guess is that something else in the network is broken. Alan DeKok.
participants (4)
-
Alan Buxey -
Alan DeKok -
Edelberto Franco -
Luciano Fernandes da Rocha