On 11/11/2016 10:40, Gabriel Ozaki wrote:
I can see the reply mensage in eap and in sql, but the reply is not in the final mensage and i don't know why (note:radtest works fine) (4) eap: Found mutually acceptable type PEAP (25)
Looking at debug output, you've set "use_tunneled_reply = yes" for ttls, but forgot to set it to yes for peap. # Linked to sub-module rlm_eap_peap peap { tls = "tls-common" default_eap_type = "mschapv2" copy_request_to_tunnel = no * use_tunneled_reply = no** * proxy_tunneled_request_as_eap = yes virtual_server = "inner-tunnel" soh = no require_client_cert = no } Aside: if you're sending the radtests to localhost:18120, then you're looking just at what the inner-tunnel is doing. That's where the SQL stuff belongs, since only the inner tunnel knows the *true* identity of the logged in user. The outer server should ignore everything and only send the reply attributes from the inner tunnel. If you have something like this in your outer (main) server: eap { ok = return } sql then non-tunnelled sessions will also use your sql logic. However it turns out that some parts of the ongoing EAP exchange will also fall through to the block after eap. I found I needed to do this to avoid it: eap { ok = return updated = return } sql If you don't make this change then it may only be annoying - some unnecessary SQL queries are done, some unnecessary attributes are returned in Access-Challenge responses. But if the sql logic sets Auth-Type := Reject under some circumstances, then I found I was rejecting users before they had a chance to complete their authentication. Regards, Brian.