Error while trying to just accept user in inner tunnel

[Alan DeKok]

On Jul 18, 2019, at 5:49 AM, Alberto Martínez Setién via Freeradius-Users <freeradius-users at 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.