On Jul 18, 2019, at 5:49 AM, Alberto Martínez Setién via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
Am not. That would be an easy explanation.
The default configuration doesn't have this issue. So what changed? From the debug log, it looks like this is happening: (6) eap_ttls: Session established. Proceeding to decode tunneled attributes (6) eap_ttls: Got tunneled request (6) eap_ttls: User-Name = "username" (6) eap_ttls: User-Password = "passwd" (6) eap_ttls: FreeRADIUS-Proxied-To = 127.0.0.1 That's normal. (6) if (&User-Name && &User-Password) { (6) if (&User-Name && &User-Password) -> TRUE (6) if (&User-Name && &User-Password) { (6) update control { rlm_sql (sql_oracle_dscorp): Reserved connection (1) (6) Executing select query: SELECT swi_wi.pkg_wifi.f_get_username_code('username') FROM DUAL rlm_sql (sql_oracle_dscorp): Released connection (1) That's your local changes, which are fine. But then: (6) policy accept { (6) update control { (6) &Response-Packet-Type = Access-Accept (6) } # update control = noop So you're not actually running the "authenticate" section in the inner tunnel. Which then leads to: 6) Virtual server sending reply (6) Filter-Id := "rol-invitado-logon" (6) eap_ttls: Tunneled authentication will be proxied to LOCAL And that message comes about because the inner-tunnel virtual server is bypassing the "authenticate" section. Which sets the inner reply packet type. And since there's no packet type for the reply, the outer TTLS code guess that the packet should be proxied. And then comes up with the above message. I'll push a fix for 3.0.20. In the mean time, you can work around it by ensuring that the "authenticate" section is run, and the "pap" module authenticates the user. Alan DeKok.