On 03/07/2012 07:19 PM, Amândio Antunes Gomes Silva wrote: > I followed Heikki's instructions, but with no success. I made some > further investigation and realized that the Access-Accept received by > Radiator from the IAS server isn't forwarded to the client.
I rechecked the log you had previously sent to the list, one question about the log: did you cut it short or was the last Access-Challenge (id 204) really missing Message-Authenticator attribute? Are you using the latest Radiator? Thanks! Heikki > I 'sniffed' > the Ethernet traffic using tcpdump in the radiator server, and the > Access-Accept packet isn't sent to the client. I sniffed a PEAP-MSCHAPV2 > (which works) and a TTLS/MSCHAPV2 and compared the packets. In the > TTLS/MSCHAPV2, the process ends with a Challenge issued by Radiator, and > sent to the NAS, but it seemed that the NAS doesn't send it back to the > client. I then investigate further and discovered that the AP tries to > send packets to the client, but it reports an error (see below). After > this, I suppose that it's a problem related to the Mac OS Supplicant. > Any hint on how to solve this? > > > > Best regards, > > > > Amândio > > > > Additional Info: > > > > TCPDUMP (between NAS and radiator radius server): > > > > reading from file MacOS-TTLS-MSCHAPV2-7.pcap, link-type EN10MB (Ethernet) > > 16:47:16.536506 IP 172.16.45.66.datametrics > radius-server.radius: > RADIUS, Access Request (1), id: 0x2b length: 217 > > 16:47:16.560307 IP radius-server.radius > 172.16.45.66.datametrics: > RADIUS, Access Challenge (11), id: 0x2b length: 46 > > 16:47:16.570428 IP 172.16.45.66.datametrics > radius-server.radius: > RADIUS, Access Request (1), id: 0x2c length: 356 > > 16:47:16.628723 IP radius-server.radius > 172.16.45.66.datametrics: > RADIUS, Access Challenge (11), id: 0x2c length: 1082 > > 16:47:16.710643 IP 172.16.45.66.datametrics > radius-server.radius: > RADIUS, Access Request (1), id: 0x2d length: 198 > > 16:47:16.738682 IP radius-server.radius > 172.16.45.66.datametrics: > RADIUS, Access Challenge (11), id: 0x2d length: 1078 > > 16:47:16.895393 IP 172.16.45.66.datametrics > radius-server.radius: > RADIUS, Access Request (1), id: 0x2e length: 198 > > 16:47:16.931681 IP radius-server.radius > 172.16.45.66.datametrics: > RADIUS, Access Challenge (11), id: 0x2e length: 1078 > > 16:47:17.027529 IP 172.16.45.66.datametrics > radius-server.radius: > RADIUS, Access Request (1), id: 0x2f length: 198 > > 16:47:17.053752 IP radius-server.radius > 172.16.45.66.datametrics: > RADIUS, Access Challenge (11), id: 0x2f length: 1078 > > 16:47:17.208341 IP 172.16.45.66.datametrics > radius-server.radius: > RADIUS, Access Request (1), id: 0x30 length: 198 > > 16:47:17.230283 IP radius-server.radius > 172.16.45.66.datametrics: > RADIUS, Access Challenge (11), id: 0x30 length: 659 > > 16:47:17.243674 IP 172.16.45.66.datametrics > radius-server.radius: > RADIUS, Access Request (1), id: 0x31 length: 530 > > 16:47:17.309004 IP radius-server.radius > 172.16.45.66.datametrics: > RADIUS, Access Challenge (11), id: 0x31 length: 109 > > 16:47:17.552920 IP 172.16.45.66.datametrics > radius-server.radius: > RADIUS, Access Request (1), id: 0x32 length: 351 > > 16:47:17.637727 IP radius-server.radius > 172.16.45.66.datametrics: > RADIUS, Access Challenge (11), id: 0x32 length: 263 > > 16:47:19.932943 IP 172.16.45.66.datametrics > radius-server.radius: > RADIUS, Access Request (1), id: 0x33 length: 217 > > 16:47:19.956708 IP radius-server.radius > 172.16.45.66.datametrics: > RADIUS, Access Challenge (11), id: 0x33 length: 46 > > 16:47:19.963244 IP 172.16.45.66.datametrics > radius-server.radius: > RADIUS, Access Request (1), id: 0x34 length: 388 > > 16:47:19.991490 IP radius-server.radius > 172.16.45.66.datametrics: > RADIUS, Access Challenge (11), id: 0x34 length: 1082 > > 16:47:20.022300 IP 172.16.45.66.datametrics > radius-server.radius: > RADIUS, Access Request (1), id: 0x35 length: 198 > > 16:47:20.052285 IP radius-server.radius > 172.16.45.66.datametrics: > RADIUS, Access Challenge (11), id: 0x35 length: 1078 > > 16:47:20.181138 IP 172.16.45.66.datametrics > radius-server.radius: > RADIUS, Access Request (1), id: 0x36 length: 198 > > 16:47:20.216984 IP radius-server.radius > 172.16.45.66.datametrics: > RADIUS, Access Challenge (11), id: 0x36 length: 1078 > > 16:47:20.339282 IP 172.16.45.66.datametrics > radius-server.radius: > RADIUS, Access Request (1), id: 0x37 length: 198 > > 16:47:20.360917 IP radius-server.radius > 172.16.45.66.datametrics: > RADIUS, Access Challenge (11), id: 0x37 length: 1078 > > 16:47:20.372684 IP 172.16.45.66.datametrics > radius-server.radius: > RADIUS, Access Request (1), id: 0x38 length: 198 > > 16:47:20.403901 IP radius-server.radius > 172.16.45.66.datametrics: > RADIUS, Access Challenge (11), id: 0x38 length: 659 > > > > MacOS syslog (via console): > > > > Mar 7 16:47:16 macbookproscom eapolclient[4092]: en1 START > > Mar 7 16:47:17 macbookproscom eapolclient[4092]: TTLS: authentication > failed with status 1 > > > > Access Point: > > > > Mar 7 16:47:20 apb-scom-0b-glt 45: Mar 7 16:47:19.444 WET: > %DOT11-4-MAXRETRIES: Packet to client f0b4.7916.ce7b reached max > retries, removing the client > > > > Note: The IP address of apb-scom-0b-glt is 172.16.45.66. > > > > TIA, > > > > Best regards, > > *Amândio Antunes Gomes da Silva* > > ----------------------------------------------------------------------------------------------------------------------------------- > > Serviços de Comunicações da Universidade do Minho > > Campus de Gualtar, 4710-057 Braga - Portugal > > Tel.: + 351 253 60 40 20, Fax: +351 253 60 40 21 > > VoIP: aman...@scom.uminho.pt <sip:aman...@scom.uminho.pt> > > email: aman...@scom.uminho.pt <mailto:aman...@scom.uminho.pt> | > http://www.scom.uminho.pt <http://www.scom.uminho.pt/> > > ----------------------------------------------------------------------------------------------------------------------------------- > > This email is confidential. If you are not the intended recipient, > > you must not disclose or use the information contained in it. > > If you have received this mail in error, please tell us immediately > > by return email and delete the document. > > > > > > -----Mensagem original----- > > De: Heikki Vatiainen [mailto:h...@open.com.au] > > Enviada: segunda-feira, 5 de Março de 2012 22:59 > > Para: Amândio Antunes Gomes Silva > > Cc: radiator@open.com.au > > Assunto: Re: [RADIATOR] eap + apple products - failed auth > > > > On 03/01/2012 06:35 PM, Amândio Antunes Gomes Silva wrote: > > > >> I'm struggling to solve a problem similar to this one for a while, but > >> the scenario is a little bit different: in our wireless network (eduroam > >> with WPA/Enterprise) we support TTLS/PAP, TTLS/MSCHAPv2 and PEAP > >> authentication methods, which works fine for all kind of devices, but > >> Apple one's, which work fine with all of this, but TTLS/MSCHAPv2. The > >> Apple clients get authenticated, the connections last for 5 to 10 > >> seconds and then it drops, never getting the IP address. Analyzing the > >> logs, I see an Access-Accept just followed by a Challenge which, I > >> think, makes the connection to not succeed. > > > > Yes, the client would need to reply so that Access-Accept could be sent > > back to the NAS. > > > > The problem here might with the attributes that get tunnlled back to the > > client. If you search the log for "Returned TTLS tunnelled", there are > > e.g. Framed-IP-Address, MS-MPPE-* and Tunnel-* attributes that are sent > > to the client. > > > > I would try changing this by adding StripFromRequest to the inner > > Handler to strip Framed-IP-Address and MS-MPPE-* attributes. The > > MS-MPPE-* attributes will be added by the outer Handler for > > Access-Accept. If they are received over the tunnelled request, they > > could just confuse the client. > > > > Thanks! > > Heikki > > > > > >> Once TTLS/MSCHAPv2 is the default authentication method in Apple > >> devices, it's impossible for our new users to connect to the eduroam > >> for the first time (by simply enter their username/password when > >> prompted) without edit the connection properties, what can be tricky, > >> especially now that Mac OSX Lion don't let you do this manually, > >> unless you have a mobile.config configuration file with the proper > >> parameters. Anyone have some idea on how to solve this? > > > > > > > >> > >> > >> > >> Some important notes: > >> > >> 1. The PEAP and TTLS/MSCHAPV2 requests, as you can see, are > >> proxied to an ISA server, which I don’t have admin rights on. > >> > >> 2. The TTLS/PAP requests are handled by an <AuthBy LDAP>, with the > >> ServerChecksPassword enabled (that’s why it doesn’t handle MSCHAPV2). > >> > >> 3. There is a ReplyHook used to correct some attributes that are > >> sent by the ISA server, mainly the Tunnel-Private-Group-ID, used to put > >> each user in his VLAN, according to his type. > >> > >> 4. Mac OSX 10.6.8 (Snow Leopard) with TTLS/MSCHAP, PEAP and > >> TTLS/PAP works fine. > >> > >> 5. Mac OSX 10.6.8 doesn’t work with TTLS/MSCHAPV2 (mac syslog > >> reports “TTLS: authentication failed with status 1”). > >> > >> > >> > >> > >> > >> Our config is: > >> > >> > >> > >> The authenticator for PEAP/MSCHAPV2: > >> > >> > >> > >> <AuthBy RADIUS> > >> > >> NoEAP > >> > >> # RewriteUsername s/^([^@]+).*/$1\@%{W}/ > >> > >> Identifier PEAPnoSAPIA > >> > >> Host ***.***.***.*** > >> > >> Secret ******** > >> > >> AuthPort 1812 > >> > >> AcctPort 1813 > >> > >> EAPType PEAP,TTLS,TLS,MSCHAP-V2,MSCHAPV2 > >> > >> Description PEAP no SAPIA > >> > >> Retries 5 > >> > >> RetryTimeout 30 > >> > >> ReplyHook file:"/etc/radiator/rh-postauth.pl" > >> > >> EAPTLS_PEAPVersion 0 > >> > >> </AuthBy> > >> > >> > >> > >> The Handlers > >> > >> ... > >> > >> <Handler ConvertedFromEAPMSCHAPV2=1> > >> > >> AuthByPolicy ContinueUntilAcceptOrChallenge > >> > >> AuthLog peaplog > >> > >> StripFromRequest ConvertedFromEAPMSCHAPV2 > >> > >> AuthBy PEAPnoSAPIA > >> > >> </Handler> > >> > >> > >> > >> <Handler TunnelledByPEAP=1> > >> > >> AuthByPolicy ContinueUntilAcceptOrChallenge > >> > >> <AuthBy FILE> > >> > >> # Dont really need this > >> > >> Filename %D/users > >> > >> > >> > >> # This tells the PEAP client what types of inner EAP requests > >> > >> # we will honour > >> > >> EAPType MSCHAP-V2 > >> > >> > >> > >> # This flag tells EAPType MSCHAP-V2 to convert the inner > >> EAP-MSCHAPV2 request into > >> > >> # an ordinary Radius-MSCHAPV2 request and redespatch to to a Handler > >> > >> # that matches ConvertedFromEAPMSCHAPV2=1 (see above) > >> > >> EAP_PEAP_MSCHAP_Convert 1 > >> > >> </AuthBy> > >> > >> PostProcessingHook file:"/etc/radiator/eap_acct_username_orig.pl" > >> > >> </Handler> > >> > >> > >> > >> <Handler TunnelledByTTLS=1, MS-CHAP-Challenge =/.+$/> > >> > >> AcctLogFileName /var/log/radius/radacct/%Y%m > >> > >> AuthByPolicy ContinueUntilAcceptOrChallenge > >> > >> AuthBy PEAPnoSAPIA > >> > >> PostProcessingHook file:"/etc/radiator/eap_acct_username_orig.pl" > >> > >> </Handler> > >> > >> > >> > >> <Handler TunnelledByTTLS=1> > >> > >> AcctLogFileName /var/log/radius/radacct/%Y%m > >> > >> AuthByPolicy ContinueUntilAcceptOrChallenge > >> > >> AuthBy Auth-SAPIA > >> > >> PostProcessingHook file:"/etc/radiator/eap_acct_username_orig.pl" > >> > >> </Handler> > >> > >> > >> > >> <Handler Realm=/uminho.pt$/ > > >> > >> AcctLogFileName /var/log/radius/radacct/%Y%m > >> > >> AuthBy SQLAccounting > >> > >> Description SSID eduroam para utilizadores uminho.pt > >> > >> Identifier REALM-UMINHO > >> > >> RejectHasReason > >> > >> <AuthBy FILE> > >> > >> # the %D/users file can be empty, its there for normal PAP > >> > >> # authentication. This can however be used for the WEB captive > >> > >> # portals. > >> > >> Filename %D/users > >> > >> EAPTLS_CAFile /etc/radiator/certs/8675909-usertrust.ca-bundle > >> > >> EAPTLS_CertificateFile /etc/radiator/certs/server.crt > >> > >> EAPTLS_CertificateType PEM > >> > >> EAPTLS_MaxFragmentSize 1024 > >> > >> EAPTLS_PrivateKeyFile /etc/radiator/certs/server.key > >> > >> EAPType TTLS, PEAP > >> > >> AutoMPPEKeys > >> > >> </AuthBy FILE> > >> > >> PreProcessingHook file:"/etc/radiator/radius.rewriteMAC.pl" > >> > >> </Handler> > >> > >> > >> > >> The Logs: > >> > >> See attached file. > >> > >> > >> > >> > >> > >> Best regards, > >> > >> > >> > >> *Amândio Antunes Gomes da Silva* > >> > >> > ----------------------------------------------------------------------------------------------------------------------------------- > >> > >> Serviços de Comunicações da Universidade do Minho > >> > >> Campus de Gualtar, 4710-057 Braga - Portugal > >> > >> Tel.: + 351 253 60 40 20, Fax: +351 253 60 40 21 > >> > >> VoIP: aman...@scom.uminho.pt <sip:aman...@scom.uminho.pt> > >> > >> email: aman...@scom.uminho.pt <mailto:aman...@scom.uminho.pt> | > >> http://www.scom.uminho.pt <http://www.scom.uminho.pt/> > >> > >> ----------------------------------------------------------------------------------------------------------------------------------- > >> > >> This email is confidential. If you are not the intended recipient, > >> > >> you must not disclose or use the information contained in it. > >> > >> If you have received this mail in error, please tell us immediately > >> > >> by return email and delete the document. > >> > >> > >> > >> > >> > > CUT > -- Heikki Vatiainen <h...@open.com.au> Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. _______________________________________________ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
