Newer versions (3.0.x) of FR fix the problem with this, there you can use update outer.reply and it'll work (but then switch use_tunneled_reply to 'no'). In 2.x I've only ever gotten it to work with 'update reply' in the inner-tunnel and then setting use_tunneled_reply to 'yes', unless Alan and Arran have made the same fix in 2.2.5 as they have had in 3.0.x. Stefan ________________________________________ From: freeradius-users-bounces+stefan.paetow=ja.net@lists.freeradius.org [freeradius-users-bounces+stefan.paetow=ja.net@lists.freeradius.org] on behalf of Axel Luttgens [axel.luttgens@skynet.be] Sent: 28 August 2014 20:01 To: FreeRadius users mailing list Subject: Re: Not able to receive inner identity in Access-Accept in EAP-TTLS. Le 26 août 2014 à 14:33, Alan DeKok a écrit :
[...] That updates the outer reply. Which is later over-written by the "use_tunneled_reply" code.
Am I missing any configuration for EAP-TTLS OR bug still not fixed for EAP-TTLS?
You're doing contradictory things to the configuration Don't do that.
Hmmm... I'm facing the same kind of behavior as the one described by Bhavesh: the inner identity, brought to the outer reply thru a "update outer.reply", just appears in an Access-Challenge reply, never in an Access-Accept reply. I've tried several things, but couldn't manage to go beyond that behavior described in more details hereafter. Any hint would be greatly appreciated. ;-) TIA, Axel Looking at Bhavesh's "free_radius.log" file, one may read: [ttls] Got tunneled Access-Accept [ttls] Got MS-CHAP2-Success, tunneling it to the client in a challenge. ++[eap] returns handled Sending Access-Challenge of id 6 to 10.202.28.31 port 33345 User-Name = "testuser" EAP-Message = 0x016e005f15800000005517030100506d233ce5f277e8790ca9d99b7c6154d04fab50fde0bf996936a266c513eee868d0a91e83d2047f566844b1e3689704e80743ab4b722d91c087f375eb3f771ed97840aaa0d96cc57e3284b043fb1cf720 Message-Authenticator = 0x00000000000000000000000000000000 State = 0xd589c140d3e7d46dd220203641ea1c2f Finished request 6. Going to the next request Waking up in 4.9 seconds. rad_recv: Access-Request packet from host 10.202.28.31 port 33345, id=7, length=178 User-Name = "anonymous" NAS-IP-Address = 127.0.0.1 NAS-Port = 1 Called-Station-Id = "00-0E-8E-38-3E-10:WiFi_SSO-Bhavesh" Calling-Station-Id = "64-70-02-08-95-D9" Framed-MTU = 1400 NAS-Port-Type = Wireless-802.11 Connect-Info = "CONNECT 54Mbps 802.11g" EAP-Message = 0x026e00061500 State = 0xd589c140d3e7d46dd220203641ea1c2f Message-Authenticator = 0xee2c1fb5ca38abe58da40276e36568d9 That is, an Access-Challenge is sent to the client with the inner identity, and the client's subsequent Access-Request comes with a User-Name set to the outer identity. The inner identity doesn't appear later in the log anymore; in particular, no Access-Accept with the inner identity is to be seen. I am facing exactly the same kind of behavior here, with FreeRadius 3.0.4. For example, with TTLS-MSCHAPv2: (28) eap_ttls : Got tunneled Access-Accept (28) eap_ttls : Got MS-CHAP2-Success, tunneling it to the client in a challenge (28) eap_ttls : sending tunneled reply attributes MS-CHAP2-Success = 0xb5533d39444331443832323642343232453638423937464335424639393937424335394341353331353641 (28) eap_ttls : end tunneled reply attributes (28) eap-wifi : New EAP session, adding 'State' attribute to reply 0xc3a04e0ac5a75b08 (28) [eap-wifi] = handled (28) } # authenticate = handled (28) Sending Access-Challenge packet to host 127.0.0.1 port 64970, id=6, length=0 (28) User-Name = 'bob@dummy.be' (28) EAP-Message = 0x0107005f15800000005517030100506f359c4660334b695bb0395c3f2e9c20d604278cd68a6efc2820b6856255edfc80b62a52e49fdd89f4697fe424d39cb0df945e439ae5fc3bd16386caa2ff43fb9f81c036ad6a0698c762daec595cb4bb (28) Message-Authenticator = 0x00000000000000000000000000000000 (28) State = 0xc3a04e0ac5a75b0801f6c577ce0fa88e Sending Access-Challenge Id 6 from 127.0.0.1:1812 to 127.0.0.1:64970 User-Name = 'bob@dummy.be' EAP-Message = 0x0107005f15800000005517030100506f359c4660334b695bb0395c3f2e9c20d604278cd68a6efc2820b6856255edfc80b62a52e49fdd89f4697fe424d39cb0df945e439ae5fc3bd16386caa2ff43fb9f81c036ad6a0698c762daec595cb4bb Message-Authenticator = 0x00000000000000000000000000000000 State = 0xc3a04e0ac5a75b0801f6c577ce0fa88e (28) Finished request Waking up in 0.2 seconds. Received Access-Request Id 7 from 127.0.0.1:64970 to 127.0.0.1:1812 length 151 User-Name = 'anonymous@dummy.be' NAS-IP-Address = 127.0.0.1 Calling-Station-Id = '02-00-00-00-00-01' Framed-MTU = 1400 NAS-Port-Type = Wireless-802.11 Connect-Info = 'CONNECT 11Mbps 802.11b' EAP-Message = 0x020700061500 State = 0xc3a04e0ac5a75b0801f6c577ce0fa88e Message-Authenticator = 0xc735ef8d3c36dfe21a5cca667577da66 (29) Received Access-Request packet from host 127.0.0.1 port 64970, id=7, length=151 (29) User-Name = 'anonymous@dummy.be' (29) NAS-IP-Address = 127.0.0.1 (29) Calling-Station-Id = '02-00-00-00-00-01' (29) Framed-MTU = 1400 (29) NAS-Port-Type = Wireless-802.11 (29) Connect-Info = 'CONNECT 11Mbps 802.11b' (29) EAP-Message = 0x020700061500 (29) State = 0xc3a04e0ac5a75b0801f6c577ce0fa88e (29) Message-Authenticator = 0xc735ef8d3c36dfe21a5cca667577da66 Or with PEAP: (9) eap_peap : Tunneled authentication was successful (9) eap_peap : SUCCESS (9) eap-wifi : New EAP session, adding 'State' attribute to reply 0x922f7d0b9b2564f5 (9) [eap-wifi] = handled (9) } # authenticate = handled (9) Sending Access-Challenge packet to host 127.0.0.1 port 63529, id=9, length=0 (9) User-Name = 'bob@dummy.be' (9) EAP-Message = 0x010a002b190017030100200170b89bcf1ab9c867dcf5bef895bc5c5827d521d6ff40a960f8ae5f8a7634f5 (9) Message-Authenticator = 0x00000000000000000000000000000000 (9) State = 0x922f7d0b9b2564f576dd75b4625e51f2 Sending Access-Challenge Id 9 from 127.0.0.1:1812 to 127.0.0.1:63529 User-Name = 'bob@dummy.be' EAP-Message = 0x010a002b190017030100200170b89bcf1ab9c867dcf5bef895bc5c5827d521d6ff40a960f8ae5f8a7634f5 Message-Authenticator = 0x00000000000000000000000000000000 State = 0x922f7d0b9b2564f576dd75b4625e51f2 (9) Finished request Waking up in 0.2 seconds. Received Access-Request Id 10 from 127.0.0.1:63529 to 127.0.0.1:1812 length 225 User-Name = 'anonymous@dummy.be' NAS-IP-Address = 127.0.0.1 Calling-Station-Id = '02-00-00-00-00-01' Framed-MTU = 1400 NAS-Port-Type = Wireless-802.11 Connect-Info = 'CONNECT 11Mbps 802.11b' EAP-Message = 0x020a005019001703010020f774f728b6a603c0f1b3e610ac5da554c105434b533a20000983924b62b07d0f17030100204ad47488830ade25c9bc6bd4535b6fa52f7c76c7cffcf7900aee8988787e1958 State = 0x922f7d0b9b2564f576dd75b4625e51f2 Message-Authenticator = 0xa59640412b7cc810723ecabbf6e766be (10) Received Access-Request packet from host 127.0.0.1 port 63529, id=10, length=225 (10) User-Name = 'anonymous@dummy.be' (10) NAS-IP-Address = 127.0.0.1 (10) Calling-Station-Id = '02-00-00-00-00-01' (10) Framed-MTU = 1400 (10) NAS-Port-Type = Wireless-802.11 (10) Connect-Info = 'CONNECT 11Mbps 802.11b' (10) EAP-Message = 0x020a005019001703010020f774f728b6a603c0f1b3e610ac5da554c105434b533a20000983924b62b07d0f17030100204ad47488830ade25c9bc6bd4535b6fa52f7c76c7cffcf7900aee8988787e1958 (10) State = 0x922f7d0b9b2564f576dd75b4625e51f2 (10) Message-Authenticator = 0xa59640412b7cc810723ecabbf6e766be - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html Janet(UK) is a trading name of Jisc Collections and Janet Limited, a not-for-profit company which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238