Still problems with IOS9 and FR2.2.9
Hi, Like lots of people, we've been hit with the changes to TLS support in IOS9. I've upgraded to FR2.2.9 (we're a moderate sized ISP and can't upgrade to 3.x in a hurry) but there's still little change to the matter. Our configuration is an proxy configuration which forwards normal (non-EAP) RADIUS to our customer facing radius platform. The difference that we're seeing between an 8.x connection attempt (which works fine) and a 9.x connection attempt is that we don't see the MSCHAP attributes passed through in the request. If anyone has any ideas, that would be greatly appreciated. I'm kind of at a dead end at this point. Cheers Mark Thread 3 handling request 25, (6 handled so far) # Executing section authorize from file /usr/share/ii/wifiproxy/sites-enabled/default +group authorize { ++[preprocess] = ok ++[chap] = noop ++[mschap] = noop ++[digest] = noop [suffix] No '@' in User-Name = "levsky", looking up realm NULL [suffix] Found realm "NULL" [suffix] Adding Realm = "NULL" [suffix] Authentication realm is LOCAL. ++[suffix] = ok [eap] EAP packet type response id 1 length 11 [eap] No EAP Start, assuming it's an on-going EAP conversation ++[eap] = updated ++[files] = noop ++[expiration] = noop ++[logintime] = noop [pap] WARNING! No "known good" password found for the user. Authentication may fail because of this. ++[pap] = noop +} # group authorize = updated Found Auth-Type = EAP # Executing group from file /usr/share/ii/wifiproxy/sites-enabled/default +group authenticate { [eap] EAP Identity [eap] processing type tls [tls] Initiate [tls] Start returned 1 ++[eap] = handled +} # group authenticate = handled Finished request 25. Going to the next request Thread 3 waiting to be assigned a request Waking up in 0.9 seconds. Thread 4 got semaphore Thread 4 handling request 26, (6 handled so far) # Executing section authorize from file /usr/share/ii/wifiproxy/sites-enabled/default +group authorize { ++[preprocess] = ok ++[chap] = noop ++[mschap] = noop ++[digest] = noop [suffix] No '@' in User-Name = "levsky", looking up realm NULL [suffix] Found realm "NULL" [suffix] Adding Realm = "NULL" [suffix] Authentication realm is LOCAL. ++[suffix] = ok [eap] EAP packet type response id 2 length 143 [eap] Continuing tunnel setup. ++[eap] = ok +} # group authorize = ok Found Auth-Type = EAP # Executing group from file /usr/share/ii/wifiproxy/sites-enabled/default +group authenticate { [eap] Request found, released from the list [eap] EAP/ttls [eap] processing type ttls [ttls] Authenticate [ttls] processing EAP-TLS TLS Length 133 [ttls] Length Included [ttls] eaptls_verify returned 11 [ttls] (other): before/accept initialization [ttls] TLS_accept: before/accept initialization [ttls] <<< TLS 1.0 Handshake [length 0080], ClientHello [ttls] TLS_accept: SSLv3 read client hello A [ttls] >>> TLS 1.0 Handshake [length 0031], ServerHello [ttls] TLS_accept: SSLv3 write server hello A [ttls] >>> TLS 1.0 Handshake [length 06b2], Certificate [ttls] TLS_accept: SSLv3 write certificate A [ttls] >>> TLS 1.0 Handshake [length 0004], ServerHelloDone [ttls] TLS_accept: SSLv3 write server done A [ttls] TLS_accept: SSLv3 flush data [ttls] TLS_accept: Need to read more data: SSLv3 read client certificate A [ttls] TLS_accept: Need to read more data: SSLv3 read client certificate A In SSL Handshake Phase In SSL Accept mode [ttls] eaptls_process returned 13 ++[eap] = handled +} # group authenticate = handled Finished request 26. Going to the next request Thread 4 waiting to be assigned a request Waking up in 0.9 seconds. Thread 2 got semaphore Thread 2 handling request 27, (6 handled so far) # Executing section authorize from file /usr/share/ii/wifiproxy/sites-enabled/default +group authorize { ++[preprocess] = ok ++[chap] = noop ++[mschap] = noop ++[digest] = noop [suffix] No '@' in User-Name = "levsky", looking up realm NULL [suffix] Found realm "NULL" [suffix] Adding Realm = "NULL" [suffix] Authentication realm is LOCAL. ++[suffix] = ok [eap] EAP packet type response id 3 length 6 [eap] Continuing tunnel setup. ++[eap] = ok +} # group authorize = ok Found Auth-Type = EAP # Executing group from file /usr/share/ii/wifiproxy/sites-enabled/default +group authenticate { [eap] Request found, released from the list [eap] EAP/ttls [eap] processing type ttls [ttls] Authenticate [ttls] processing EAP-TLS [ttls] Received TLS ACK [ttls] ACK handshake fragment handler [ttls] eaptls_verify returned 1 [ttls] eaptls_process returned 13 ++[eap] = handled +} # group authenticate = handled Finished request 27. Going to the next request Thread 2 waiting to be assigned a request Waking up in 0.9 seconds. Thread 5 got semaphore Thread 5 handling request 28, (6 handled so far) # Executing section authorize from file /usr/share/ii/wifiproxy/sites-enabled/default +group authorize { ++[preprocess] = ok ++[chap] = noop ++[mschap] = noop ++[digest] = noop [suffix] No '@' in User-Name = "levsky", looking up realm NULL [suffix] Found realm "NULL" [suffix] Adding Realm = "NULL" [suffix] Authentication realm is LOCAL. ++[suffix] = ok [eap] EAP packet type response id 4 length 253 [eap] Continuing tunnel setup. ++[eap] = ok +} # group authorize = ok Found Auth-Type = EAP # Executing group from file /usr/share/ii/wifiproxy/sites-enabled/default +group authenticate { [eap] Request found, released from the list [eap] EAP/ttls [eap] processing type ttls [ttls] Authenticate [ttls] processing EAP-TLS TLS Length 326 [ttls] Length Included [ttls] eaptls_verify returned 11 [ttls] <<< TLS 1.0 Handshake [length 0106], ClientKeyExchange [ttls] TLS_accept: SSLv3 read client key exchange A [ttls] <<< TLS 1.0 ChangeCipherSpec [length 0001] [ttls] <<< TLS 1.0 Handshake [length 0010], Finished [ttls] TLS_accept: SSLv3 read finished A [ttls] >>> TLS 1.0 ChangeCipherSpec [length 0001] [ttls] TLS_accept: SSLv3 write change cipher spec A [ttls] >>> TLS 1.0 Handshake [length 0010], Finished [ttls] TLS_accept: SSLv3 write finished A [ttls] TLS_accept: SSLv3 flush data [ttls] (other): SSL negotiation finished successfully SSL Connection Established [ttls] eaptls_process returned 13 ++[eap] = handled +} # group authenticate = handled Finished request 28. Going to the next request Thread 5 waiting to be assigned a request Waking up in 0.8 seconds. Thread 1 got semaphore Thread 1 handling request 29, (7 handled so far) # Executing section authorize from file /usr/share/ii/wifiproxy/sites-enabled/default +group authorize { ++[preprocess] = ok ++[chap] = noop ++[mschap] = noop ++[digest] = noop [suffix] No '@' in User-Name = "levsky", looking up realm NULL [suffix] Found realm "NULL" [suffix] Adding Realm = "NULL" [suffix] Authentication realm is LOCAL. ++[suffix] = ok [eap] EAP packet type response id 5 length 63 [eap] Continuing tunnel setup. ++[eap] = ok +} # group authorize = ok Found Auth-Type = EAP # Executing group from file /usr/share/ii/wifiproxy/sites-enabled/default +group authenticate { [eap] Request found, released from the list [eap] EAP/ttls [eap] processing type ttls [ttls] Authenticate [ttls] processing EAP-TLS TLS Length 53 [ttls] Length Included [ttls] eaptls_verify returned 11 [ttls] eaptls_process returned 7 [ttls] Session established. Proceeding to decode tunneled attributes. [ttls] Got tunneled identity of levsky [ttls] Setting default EAP type for tunneled EAP session. # Executing section authorize from file /usr/share/ii/wifiproxy/sites-enabled/ttls-proxy +group authorize { rlm_perl: Added pair NAS-Port-Type = Wireless-802.11 rlm_perl: Added pair Service-Type = Framed-User rlm_perl: Added pair Tunnel-Type = VLAN rlm_perl: Added pair Called-Station-Id = 34dbfd24e9e0:iiNet Customer DEV rlm_perl: Added pair Airespace-Wlan-Id = 155 rlm_perl: Added pair FreeRADIUS-Proxied-To = 127.0.0.1 rlm_perl: Added pair Location-Capable = Civix-Location rlm_perl: Added pair II-Proxy-Realm = IIRADIUS rlm_perl: Added pair NAS-IP-Address = 10.13.6.8 rlm_perl: Added pair Tunnel-Private-Group-Id = 151 rlm_perl: Added pair Tunnel-Medium-Type = IEEE-802 rlm_perl: Added pair Calling-Station-Id = f0f61c739670 rlm_perl: Added pair Cisco-AVPair = audit-session-id=0a19d7cb0005280162131656 rlm_perl: Added pair User-Name = levsky rlm_perl: Added pair NAS-Identifier = wlc1.per3 rlm_perl: Added pair Chargeable-User-Identity = rlm_perl: Added pair EAP-Message = 0x0200000b016c6576736b79 rlm_perl: Added pair NAS-Port = 1 rlm_perl: Added pair Framed-MTU = 1300 rlm_perl: Added pair EAP-Type = MD5-Challenge ++[perl-innertunnels] = ok ++update control { expand: %{II-Proxy-Realm} -> IIRADIUS ++} # update control = noop +} # group authorize = ok [ttls] Tunneled authentication will be proxied to IIRADIUS [eap] Tunneled session will be proxied. Not doing EAP. ++[eap] = handled +} # group authenticate = handled WARNING: Empty pre-proxy section. Using default return values. Proxying request 29 to home server 10.10.24.1 port 1645 Going to the next request Thread 1 waiting to be assigned a request Waking up in 0.8 seconds. Thread 3 got semaphore Thread 3 handling request 29, (7 handled so far) # Executing section post-proxy from file /usr/share/ii/wifiproxy/sites-enabled/default +group post-proxy { [eap] Doing post-proxy callback [eap] Passing reply from proxy back into the tunnel. [eap] Got tunneled Access-Reject [eap] Reply was rejected [eap] Failed in post-proxy callback rlm_eap_ttls: Freeing handler for user levsky ++[eap] = reject +} # group post-proxy = reject Login incorrect (Home Server says so): [levsky/<via Auth-Type = EAP>] (from client wlc1.per3 port 1 cli f0f61c739670) Using Post-Auth-Type Reject # Executing group from file /usr/share/ii/wifiproxy/sites-enabled/default +group REJECT { [attr_filter.access_reject] expand: %{User-Name} -> levsky attr_filter: Matched entry DEFAULT at line 11 ++[attr_filter.access_reject] = updated +} # group REJECT = updated Delaying reject of request 29 for 1 seconds Going to the next request Thread 3 waiting to be assigned a request Sending delayed reject for request 29 Cleaning up request 23 ID 117 with timestamp +47 Waking up in 1.7 seconds. Cleaning up request 24 ID 119 with timestamp +49 Waking up in 2.0 seconds. Waking up in 0.9 seconds.
Hi,
Like lots of people, we've been hit with the changes to TLS support in IOS9. I've upgraded to FR2.2.9 (we're a moderate sized ISP and can't upgrade to 3.x in a hurry) but there's still little change to the matter.
no.....theres no change - its not TLS 1.2 yet - they pulled back
Our configuration is an proxy configuration which forwards normal (non-EAP) RADIUS to our customer facing radius platform. The difference that we're seeing between an 8.x connection attempt (which works fine) and a 9.x connection attempt is that we don't see the MSCHAP attributes passed through in the request.
correct...because thats the change - they now send EAP-MSCHAPv2 in the inner. alan
Thanks for the headsup on that Alan, What I'm not getting is how come this isn't converting to straight MSCHAPV2 in the inner server definition. We have the eap directive in both post-proxy and authenticate stanzas defined for the server (perl-innertunnels is just a quick bit of perl to set the correct realm based on username) Our inner tunnel server looks like: server ttls-proxy { authorize { perl-innertunnels update control { Proxy-To-Realm := "%{II-Proxy-Realm}" } } authenticate { eap } post-auth { update outer.reply { User-Name := "%{request:User-Name}" } } post-proxy { eap perl-innertunnels } } and the eap.conf like eap { default_eap_type = ttls timer_expire = 60 ignore_unknown_eap_types = no cisco_accounting_username_bug = no max_sessions = 4096 md5 { } leap { } gtc { auth_type = PAP } tls { certdir = /etc/ssl/certs cadir = /etc/ssl/certs private_key_file = ${certdir}/radius_key.pem certificate_file = ${certdir}/radius_crt.pem dh_file = ${confdir}/certs/dh random_file = /dev/urandom CA_path = ${cadir} cipher_list = "DEFAULT" make_cert_command = "${certdir}/bootstrap" ecdh_curve = "prime256v1" cache { enable = no max_entries = 255 } verify { } ocsp { enable = no override_cert_url = yes url = "http://127.0.0.1/ocsp/" } } ttls { default_eap_type = md5 copy_request_to_tunnel = yes proxy_tunneled_request_as_eap = no use_tunneled_reply = yes virtual_server = "ttls-proxy" } peap { default_eap_type = mschapv2 copy_request_to_tunnel = yes use_tunneled_reply = yes proxy_tunneled_request_as_eap = no virtual_server = "peap-proxy" } mschapv2 { send_error = yes } } But what gets proxied to the (radiator) home servers looks like Code: Access-Request Identifier: 247 Authentic: <213><243><218><183><200><28><177><22>s<165><203><145><160><156><151><188> Attributes: NAS-Port-Type = 19 Service-Type = Framed Tunnel-Type = 13 Called-Station-Id = "34dbfd24e9e0" NAS-IP-Address = 10.13.6.8 Tunnel-Private-Group-ID = "151" Tunnel-Medium-Type = 6 Calling-Station-Id = "f0f61c739670" cisco-avpair = "audit-session-id=0a19d7cb000541d3642e1756" User-Name = "levsky" NAS-Identifier = "wlc1.per3" EAP-Message = <2><0><0><11><1>levsky NAS-Port = 1 Framed-MTU = 1300 Signature = j<170><210>"Z<214>5<229>G}<31><250><225><189><219><22> Proxy-State = 148 On 8 October 2015 at 16:52, <A.L.M.Buxey@lboro.ac.uk> wrote:
Hi,
Like lots of people, we've been hit with the changes to TLS support in IOS9. I've upgraded to FR2.2.9 (we're a moderate sized ISP and can't upgrade to 3.x in a hurry) but there's still little change to the matter.
no.....theres no change - its not TLS 1.2 yet - they pulled back
Our configuration is an proxy configuration which forwards normal (non-EAP) RADIUS to our customer facing radius platform. The difference that we're seeing between an 8.x connection attempt (which works fine) and a 9.x connection attempt is that we don't see the MSCHAP attributes passed through in the request.
correct...because thats the change - they now send EAP-MSCHAPv2 in the inner.
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Oct 8, 2015, at 11:12 PM, Mark Haselden <levsky@gmail.com> wrote:
What I'm not getting is how come this isn't converting to straight MSCHAPV2 in the inner server definition. We have the eap directive in both post-proxy and authenticate stanzas defined for the server (perl-innertunnels is just a quick bit of perl to set the correct realm based on username)
OK.
Our inner tunnel server looks like:
No...
But what gets proxied to the (radiator) home servers looks like
And no... Please post the debug output of *FreeRADIUS*, as suggested in the FAQ, "man" page, web pages, and daily on this list. We need to see what's going on, and *why* it's happening. Alan DeKok.
Sorry Alan, I'd already posted the freeradius output in the prior email, and I didn't want to spam too much, but here it is again. Thanks Mark Thread 3 handling request 25, (6 handled so far) # Executing section authorize from file /usr/share/ii/wifiproxy/sites-enabled/default +group authorize { ++[preprocess] = ok ++[chap] = noop ++[mschap] = noop ++[digest] = noop [suffix] No '@' in User-Name = "levsky", looking up realm NULL [suffix] Found realm "NULL" [suffix] Adding Realm = "NULL" [suffix] Authentication realm is LOCAL. ++[suffix] = ok [eap] EAP packet type response id 1 length 11 [eap] No EAP Start, assuming it's an on-going EAP conversation ++[eap] = updated ++[files] = noop ++[expiration] = noop ++[logintime] = noop [pap] WARNING! No "known good" password found for the user. Authentication may fail because of this. ++[pap] = noop +} # group authorize = updated Found Auth-Type = EAP # Executing group from file /usr/share/ii/wifiproxy/sites-enabled/default +group authenticate { [eap] EAP Identity [eap] processing type tls [tls] Initiate [tls] Start returned 1 ++[eap] = handled +} # group authenticate = handled Finished request 25. Going to the next request Thread 3 waiting to be assigned a request Waking up in 0.9 seconds. Thread 4 got semaphore Thread 4 handling request 26, (6 handled so far) # Executing section authorize from file /usr/share/ii/wifiproxy/sites-enabled/default +group authorize { ++[preprocess] = ok ++[chap] = noop ++[mschap] = noop ++[digest] = noop [suffix] No '@' in User-Name = "levsky", looking up realm NULL [suffix] Found realm "NULL" [suffix] Adding Realm = "NULL" [suffix] Authentication realm is LOCAL. ++[suffix] = ok [eap] EAP packet type response id 2 length 143 [eap] Continuing tunnel setup. ++[eap] = ok +} # group authorize = ok Found Auth-Type = EAP # Executing group from file /usr/share/ii/wifiproxy/sites-enabled/default +group authenticate { [eap] Request found, released from the list [eap] EAP/ttls [eap] processing type ttls [ttls] Authenticate [ttls] processing EAP-TLS TLS Length 133 [ttls] Length Included [ttls] eaptls_verify returned 11 [ttls] (other): before/accept initialization [ttls] TLS_accept: before/accept initialization [ttls] <<< TLS 1.0 Handshake [length 0080], ClientHello [ttls] TLS_accept: SSLv3 read client hello A [ttls] >>> TLS 1.0 Handshake [length 0031], ServerHello [ttls] TLS_accept: SSLv3 write server hello A [ttls] >>> TLS 1.0 Handshake [length 06b2], Certificate [ttls] TLS_accept: SSLv3 write certificate A [ttls] >>> TLS 1.0 Handshake [length 0004], ServerHelloDone [ttls] TLS_accept: SSLv3 write server done A [ttls] TLS_accept: SSLv3 flush data [ttls] TLS_accept: Need to read more data: SSLv3 read client certificate A [ttls] TLS_accept: Need to read more data: SSLv3 read client certificate A In SSL Handshake Phase In SSL Accept mode [ttls] eaptls_process returned 13 ++[eap] = handled +} # group authenticate = handled Finished request 26. Going to the next request Thread 4 waiting to be assigned a request Waking up in 0.9 seconds. Thread 2 got semaphore Thread 2 handling request 27, (6 handled so far) # Executing section authorize from file /usr/share/ii/wifiproxy/sites-enabled/default +group authorize { ++[preprocess] = ok ++[chap] = noop ++[mschap] = noop ++[digest] = noop [suffix] No '@' in User-Name = "levsky", looking up realm NULL [suffix] Found realm "NULL" [suffix] Adding Realm = "NULL" [suffix] Authentication realm is LOCAL. ++[suffix] = ok [eap] EAP packet type response id 3 length 6 [eap] Continuing tunnel setup. ++[eap] = ok +} # group authorize = ok Found Auth-Type = EAP # Executing group from file /usr/share/ii/wifiproxy/sites-enabled/default +group authenticate { [eap] Request found, released from the list [eap] EAP/ttls [eap] processing type ttls [ttls] Authenticate [ttls] processing EAP-TLS [ttls] Received TLS ACK [ttls] ACK handshake fragment handler [ttls] eaptls_verify returned 1 [ttls] eaptls_process returned 13 ++[eap] = handled +} # group authenticate = handled Finished request 27. Going to the next request Thread 2 waiting to be assigned a request Waking up in 0.9 seconds. Thread 5 got semaphore Thread 5 handling request 28, (6 handled so far) # Executing section authorize from file /usr/share/ii/wifiproxy/sites-enabled/default +group authorize { ++[preprocess] = ok ++[chap] = noop ++[mschap] = noop ++[digest] = noop [suffix] No '@' in User-Name = "levsky", looking up realm NULL [suffix] Found realm "NULL" [suffix] Adding Realm = "NULL" [suffix] Authentication realm is LOCAL. ++[suffix] = ok [eap] EAP packet type response id 4 length 253 [eap] Continuing tunnel setup. ++[eap] = ok +} # group authorize = ok Found Auth-Type = EAP # Executing group from file /usr/share/ii/wifiproxy/sites-enabled/default +group authenticate { [eap] Request found, released from the list [eap] EAP/ttls [eap] processing type ttls [ttls] Authenticate [ttls] processing EAP-TLS TLS Length 326 [ttls] Length Included [ttls] eaptls_verify returned 11 [ttls] <<< TLS 1.0 Handshake [length 0106], ClientKeyExchange [ttls] TLS_accept: SSLv3 read client key exchange A [ttls] <<< TLS 1.0 ChangeCipherSpec [length 0001] [ttls] <<< TLS 1.0 Handshake [length 0010], Finished [ttls] TLS_accept: SSLv3 read finished A [ttls] >>> TLS 1.0 ChangeCipherSpec [length 0001] [ttls] TLS_accept: SSLv3 write change cipher spec A [ttls] >>> TLS 1.0 Handshake [length 0010], Finished [ttls] TLS_accept: SSLv3 write finished A [ttls] TLS_accept: SSLv3 flush data [ttls] (other): SSL negotiation finished successfully SSL Connection Established [ttls] eaptls_process returned 13 ++[eap] = handled +} # group authenticate = handled Finished request 28. Going to the next request Thread 5 waiting to be assigned a request Waking up in 0.8 seconds. Thread 1 got semaphore Thread 1 handling request 29, (7 handled so far) # Executing section authorize from file /usr/share/ii/wifiproxy/sites-enabled/default +group authorize { ++[preprocess] = ok ++[chap] = noop ++[mschap] = noop ++[digest] = noop [suffix] No '@' in User-Name = "levsky", looking up realm NULL [suffix] Found realm "NULL" [suffix] Adding Realm = "NULL" [suffix] Authentication realm is LOCAL. ++[suffix] = ok [eap] EAP packet type response id 5 length 63 [eap] Continuing tunnel setup. ++[eap] = ok +} # group authorize = ok Found Auth-Type = EAP # Executing group from file /usr/share/ii/wifiproxy/sites-enabled/default +group authenticate { [eap] Request found, released from the list [eap] EAP/ttls [eap] processing type ttls [ttls] Authenticate [ttls] processing EAP-TLS TLS Length 53 [ttls] Length Included [ttls] eaptls_verify returned 11 [ttls] eaptls_process returned 7 [ttls] Session established. Proceeding to decode tunneled attributes. [ttls] Got tunneled identity of levsky [ttls] Setting default EAP type for tunneled EAP session. # Executing section authorize from file /usr/share/ii/wifiproxy/sites-enabled/ttls-proxy +group authorize { rlm_perl: Added pair NAS-Port-Type = Wireless-802.11 rlm_perl: Added pair Service-Type = Framed-User rlm_perl: Added pair Tunnel-Type = VLAN rlm_perl: Added pair Called-Station-Id = 34dbfd24e9e0:iiNet Customer DEV rlm_perl: Added pair Airespace-Wlan-Id = 155 rlm_perl: Added pair FreeRADIUS-Proxied-To = 127.0.0.1 rlm_perl: Added pair Location-Capable = Civix-Location rlm_perl: Added pair II-Proxy-Realm = IIRADIUS rlm_perl: Added pair NAS-IP-Address = 10.13.6.8 rlm_perl: Added pair Tunnel-Private-Group-Id = 151 rlm_perl: Added pair Tunnel-Medium-Type = IEEE-802 rlm_perl: Added pair Calling-Station-Id = f0f61c739670 rlm_perl: Added pair Cisco-AVPair = audit-session-id=0a19d7cb0005280162131656 rlm_perl: Added pair User-Name = levsky rlm_perl: Added pair NAS-Identifier = wlc1.per3 rlm_perl: Added pair Chargeable-User-Identity = rlm_perl: Added pair EAP-Message = 0x0200000b016c6576736b79 rlm_perl: Added pair NAS-Port = 1 rlm_perl: Added pair Framed-MTU = 1300 rlm_perl: Added pair EAP-Type = MD5-Challenge ++[perl-innertunnels] = ok ++update control { expand: %{II-Proxy-Realm} -> IIRADIUS ++} # update control = noop +} # group authorize = ok [ttls] Tunneled authentication will be proxied to IIRADIUS [eap] Tunneled session will be proxied. Not doing EAP. ++[eap] = handled +} # group authenticate = handled WARNING: Empty pre-proxy section. Using default return values. Proxying request 29 to home server 10.10.24.1 port 1645 Going to the next request Thread 1 waiting to be assigned a request Waking up in 0.8 seconds. Thread 3 got semaphore Thread 3 handling request 29, (7 handled so far) # Executing section post-proxy from file /usr/share/ii/wifiproxy/sites-enabled/default +group post-proxy { [eap] Doing post-proxy callback [eap] Passing reply from proxy back into the tunnel. [eap] Got tunneled Access-Reject [eap] Reply was rejected [eap] Failed in post-proxy callback rlm_eap_ttls: Freeing handler for user levsky ++[eap] = reject +} # group post-proxy = reject Login incorrect (Home Server says so): [levsky/<via Auth-Type = EAP>] (from client wlc1.per3 port 1 cli f0f61c739670) Using Post-Auth-Type Reject # Executing group from file /usr/share/ii/wifiproxy/sites-enabled/default +group REJECT { [attr_filter.access_reject] expand: %{User-Name} -> levsky attr_filter: Matched entry DEFAULT at line 11 ++[attr_filter.access_reject] = updated +} # group REJECT = updated Delaying reject of request 29 for 1 seconds Going to the next request Thread 3 waiting to be assigned a request Sending delayed reject for request 29 Cleaning up request 23 ID 117 with timestamp +47 Waking up in 1.7 seconds. Cleaning up request 24 ID 119 with timestamp +49 Waking up in 2.0 seconds. Waking up in 0.9 seconds On 9 October 2015 at 21:16, Alan DeKok <aland@deployingradius.com> wrote:
On Oct 8, 2015, at 11:12 PM, Mark Haselden <levsky@gmail.com> wrote:
What I'm not getting is how come this isn't converting to straight MSCHAPV2 in the inner server definition. We have the eap directive in both post-proxy and authenticate stanzas defined for the server (perl-innertunnels is just a quick bit of perl to set the correct realm based on username)
OK.
Our inner tunnel server looks like:
No...
But what gets proxied to the (radiator) home servers looks like
And no...
Please post the debug output of *FreeRADIUS*, as suggested in the FAQ, "man" page, web pages, and daily on this list. We need to see what's going on, and *why* it's happening.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Le 8 oct. 2015 à 10:52, A.L.M.Buxey@lboro.ac.uk a écrit :
[…] no…..theres no change - its not TLS 1.2 yet - they pulled back […] correct…because thats the change - they now send EAP-MSCHAPv2 in the inner.
Hello Alan, Do you have some more detailed infos about Apple’s changes? I’m asking, because I’m struggling with ios/mac os x clients too (as Mark does), yet with other symptoms. I’m currently running FR 3.0.4, with OpenSSL 0.9.8y. ios9 clients, as well as Mac OS X 10.11 clients happily authenticate and connect to our APs, then authenticate and connect again, and so on… Apparently, there’s something the clients don’t like, and they blindingly try again and again. The problem is, the clients’ logs, even with increased verbosity, don’t provide any hint. Or I didn’t manage to have the clients to provide such hints. :-( I’m now trying to set up FR 3.0.10 with OpenSSL 1.0.2d. This is the kind of thing I intended to do anyway, but I would be sooo pleased to understand beforehand what those Apple devices expect. TIA, Axel
On 9 Oct 2015, at 16:55, Axel Luttgens <axel.luttgens@skynet.be> wrote:
Le 8 oct. 2015 à 10:52, A.L.M.Buxey@lboro.ac.uk a écrit :
[…] no…..theres no change - its not TLS 1.2 yet - they pulled back […] correct…because thats the change - they now send EAP-MSCHAPv2 in the inner.
Hello Alan,
Do you have some more detailed infos about Apple’s changes?
I’m asking, because I’m struggling with ios/mac os x clients too (as Mark does), yet with other symptoms.
I’m currently running FR 3.0.4, with OpenSSL 0.9.8y. ios9 clients, as well as Mac OS X 10.11 clients happily authenticate and connect to our APs, then authenticate and connect again, and so on… Apparently, there’s something the clients don’t like, and they blindingly try again and again. The problem is, the clients’ logs, even with increased verbosity, don’t provide any hint. Or I didn’t manage to have the clients to provide such hints. :-(
I’m now trying to set up FR 3.0.10 with OpenSSL 1.0.2d. This is the kind of thing I intended to do anyway, but I would be sooo pleased to understand beforehand what those Apple devices expect.
Pull v3.0.x HEAD. Just fixed some compatibility issues with OpenSSL 1.0.2 *sigh*. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Le 10 oct. 2015 à 00:20, Axel Luttgens a écrit :
Le 9 oct. 2015 à 23:02, Arran Cudbard-Bell a écrit :
[…]
Pull v3.0.x HEAD. Just fixed some compatibility issues with OpenSSL 1.0.2 *sigh*.
Hmm. I guess I’ll try that tomorrow. :-)
Thanks Arran, Axel
Marvelous! Up to yesterday, I was terribly concerned about such things: (6) eap_ttls: ERROR: Invalid ACK received: 256 (6) eap_ttls: ERROR: [eaptls verify] = invalid (6) eap_ttls: ERROR: [eaptls process] = invalid wondering where such an octet could come from. ;-) Now, the few tests I’m able to devise with eapol_test all pass without a glitch. All my thanks again, Axel
On 10 Oct 2015, at 07:34, Axel Luttgens <axel.luttgens@skynet.be> wrote:
Le 10 oct. 2015 à 00:20, Axel Luttgens a écrit :
Le 9 oct. 2015 à 23:02, Arran Cudbard-Bell a écrit :
[…]
Pull v3.0.x HEAD. Just fixed some compatibility issues with OpenSSL 1.0.2 *sigh*.
Hmm. I guess I’ll try that tomorrow. :-)
Thanks Arran, Axel
Marvelous!
Up to yesterday, I was terribly concerned about such things:
(6) eap_ttls: ERROR: Invalid ACK received: 256 (6) eap_ttls: ERROR: [eaptls verify] = invalid (6) eap_ttls: ERROR: [eaptls process] = invalid
wondering where such an octet could come from. ;-)
The depths of the OpenSSL code :(
Now, the few tests I’m able to devise with eapol_test all pass without a glitch.
I fixed up our suite of eapol_test tests too, just unbreaking the digest stuff, and i'll push it back with a travis build script for eapol_test. I'd like to say it'll help for next time, but with Travis still stuck on Ubuntu 12.04, it's not the greatest platform the catching these sorts of compatibility issues. Starting EAP test server... ok EAPOL_TEST eap-md5 EAPOL_TEST eap-mschapv2 EAPOL_TEST eap-pwd EAPOL_TEST eap-tls EAPOL_TEST eap-ttls-eap-mschapv2 EAPOL_TEST eap-ttls-mschapv2 EAPOL_TEST eap-ttls-pap EAPOL_TEST peap-client-mschapv2 EAPOL_TEST peap-mschapv2 All pass :) -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Just to ensure the loop is complete, this openssl 1.0.2 issue...... what versions of code are affected...is this something that came in with 3.0.10 related to tls 1.2 updates/fixes or is it older than that eg anything before 3.0.6 or 2.2.6? Cheers Alan
The problem is OpenSSL. They changed the way their api works. All versions of freeradius will have problems. Sent from my iPhone
On Oct 10, 2015, at 12:40 PM, Alan Buxey <A.L.M.Buxey@lboro.ac.uk> wrote:
Just to ensure the loop is complete, this openssl 1.0.2 issue...... what versions of code are affected...is this something that came in with 3.0.10 related to tls 1.2 updates/fixes or is it older than that eg anything before 3.0.6 or 2.2.6?
Cheers
Alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Right. I'll expect a lot of other pains with openssl 1.0.2 then. But basically, without distros doing wierd backporting well be looking at 2.2.10 and 3.0.11 being the minimum release version that works with EAP clients (and TLS 1.2?) if openssl 1.0.2 is being used? alan
On 10 Oct 2015, at 12:40, Alan Buxey <A.L.M.Buxey@lboro.ac.uk> wrote:
Just to ensure the loop is complete, this openssl 1.0.2 issue...... what versions of code are affected...is this something that came in with 3.0.10 related to tls 1.2 updates/fixes or is it older than that eg anything before 3.0.6 or 2.2.6?
All of v2.x.x all of v3.x.x. Blame for main/cb.c (where the tls callbacks live) shows commits from 2002. I don't know if a different mechanism was used before then. If not, then this would likely affect all versions of the server that support EAP-TLS. This is unrelated to the fixes for TLS 1.2. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
There's also: https://support.apple.com/en-gb/HT204932
On 9 Oct 2015, at 21:55, Axel Luttgens <axel.luttgens@skynet.be> wrote:
Le 8 oct. 2015 à 10:52, A.L.M.Buxey@lboro.ac.uk a écrit :
[…] no…..theres no change - its not TLS 1.2 yet - they pulled back […] correct…because thats the change - they now send EAP-MSCHAPv2 in the inner.
Hello Alan,
Do you have some more detailed infos about Apple’s changes?
I’m asking, because I’m struggling with ios/mac os x clients too (as Mark does), yet with other symptoms.
I’m currently running FR 3.0.4, with OpenSSL 0.9.8y. ios9 clients, as well as Mac OS X 10.11 clients happily authenticate and connect to our APs, then authenticate and connect again, and so on… Apparently, there’s something the clients don’t like, and they blindingly try again and again. The problem is, the clients’ logs, even with increased verbosity, don’t provide any hint. Or I didn’t manage to have the clients to provide such hints. :-(
I’m now trying to set up FR 3.0.10 with OpenSSL 1.0.2d. This is the kind of thing I intended to do anyway, but I would be sooo pleased to understand beforehand what those Apple devices expect.
TIA, Axel
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Le 9 oct. 2015 à 23:09, Nick Lowe a écrit :
There’s also: https://support.apple.com/en-gb/HT204932 […]
Damn! Last time I saw a similar yet recent support note from Apple, the recommended DH key size was 1024 bits. To be sure: as far as FR is concerned, this is related to the dh_key_length setting, yes? (and the dh file, of course) Since this is a global setting, aren’t interoperability problems with other clients to be feared? Thanks Nick, Axel
Feared, yes. Realised? So far no. You can mitigate this too by changing the SSL ciphers list to avoid DH methods totally. This may be how we default 3.x FR in the future. Having DH around makes things more interop sensitive alan
participants (7)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan Buxey
-
Alan DeKok -
Arran Cudbard-Bell -
Axel Luttgens -
Mark Haselden -
Nick Lowe