Florian, Do you have the icon in your task bar for you ethernet interface disabled? (The "Show icon on task bar when connected" option in the interface properties should be *enabled*). Windows XP pops up a bubble from that icon when it needs to communicate with the user (for things like accepting a CA certificate as trusted). If the icon is disabled, it can't pop up this bubble. I'd look there first, then double check that you've selected "Smart Card or other Certificate" instead of "PEAP" as the authentication method. If that doesn't turn up anything, run the Windows version of ethereal on that interface to see if the switch is forwarding on the EAP-TLS start packet.
--Mike On Mon, 2004-05-17 at 09:21, Florian-Daniel Otel wrote: > [First, I'm a newcomer to this list. If this was already answered > before (although I search through the archives before posting) please > appologize and point me to the appropriate resorce] > > > Dear all, > > > Here's "yet another new bee biting the EAP-TLS dust" (tm). > > My set-up: > - Authenticating server: > * Debian/Unstable w. 2.6.5 vanilla kernel > * freeradius-snapshot-20040513 > * openssl-0.9.7-stable-SNAP-20040513. > > Side note: Stock Debian "openssl", "libssl" and "libssl-dev" packages > were removed i.e. this is the only SSL on my system (in case you'd ask). > > - Authenticator: Ethernet switch Netgear FSM 726S with 2.3.2 > firmware. For the purpose of this mail it has the IP addie 192.168.0.1 > and hostname "netgear-switch.domain.com" > > - Supplicant: WinXP Pro. SP1 + usual cruft. > > Documentation Sources: > [1] "FreeRADIUS/WinXP Authentication Setup" from > http://www.dslreports.com/forum/remark,9286052~mode=flat > [2] "FreeRADIUS EAP/TLS - WinXP HOWTO" from > http://www.impossiblereflex.com/8021x/eap-tls-HOWTO.htm > > > My problem: > > After following the EAP-TLS mantra at [1], generating certificates > and installing them successfully (AFAICT) EAP-TLS doesn't work. After > carefully combing through the logs and comparing w/ the ones given > [2] it seems that the EAP-TLS authentication doesn't succeed as I do > not even reach the TLS handshake phase: The only thing the > (freeradius) server does is it receives "Access-Request", answers > back w/ an "Access-Challenge", receives a new "Accesss-Request" to > which it answers w/ a new "Access-Challenge", and so on, in an > infinite loop, with no TLS establish and no EAP transaction peformed > beyond the above steps. > > At the end of this mail I'll attach a sever debug output (the > output is cropped for bervity purposes to leave only the relevant parts. > Of course the full monty is avail on request ;). > > > My questions: > > 1) All "Access-Challenge" messages rightfully (?) have the same "id" > as the triggering "Access-Request". However, the latter are > non-sequential. If this is supposed to be a 3-way handshake of sorts > (is it ?) than in response to the server's "Access-Challenge" I > should get an "Access-Request" with the "id" incremented ? > > In other words, how do I get to distiguish btw. new "Access-Requests" and > the ones that should (??) come in response to server's own "Access-Challenge" ? > > The reason I'm asking is that in the logs at [2] the second "Access-Request" > received from the client has an "id" incremented w.r.t previous one, > making me suspecting that this is how the server detects the previous request > and consequently reports in the log: > > [...] > rlm_eap: Request found, released from the list. > [...] > > OTOH in my own server logs I never find smth similar. > > 2) After processing each "Access-Request", my server always reports: > > [...] > rlm_eap: EAP Identity > rlm_eap: processing type tls > rlm_eap_tls: Requiring client certificate > rlm_eap_tls: Initiate > rlm_eap_tls: Start returned 1 > [...] > > but never any TLS handske appears to be starting. > IAny idea what/where to look for ? > > > Thanks for any help and/or pointers to relevent info, > > > Florian > > > P.S. Here is the server log describing message exchange. I left aside > the blurb printed out by the server before the "Listening on ports..." > line (there's no suspicious message there anyways). IP > addies/hostnames changed to "protect the innocent" :) > > > [...] > Starting - reading configuration files ... > > <trimmed > > > Listening on authentication *:1812 > Listening on accounting *:1813 > Listening on proxy *:1814 > Ready to process requests. > rad_recv: Access-Request packet from host 192.168.0.1:1027, id=1, length=167 > User-Name = "802.1x client (i.e. supplicant)" > NAS-IP-Address = 192.168.0.1 > NAS-Port = 1 > State = 0x300257fa5ecadec2b33ab1cc00d55927 > NAS-Identifier = "netgear-switch.domain.com" > NAS-Port-Type = Ethernet > EAP-Message = > 0x02010024013830322e317820636c69656e742028692e652e20737570706c6963616e7429 > Message-Authenticator = 0x1f90d93abedd0aa9c21f7e1c7e3d7ba0 > Processing the authorize section of radiusd.conf > modcall: entering group authorize for request 0 > modcall[authorize]: module "preprocess" returns ok for request 0 > modcall[authorize]: module "chap" returns noop for request 0 > modcall[authorize]: module "mschap" returns noop for request 0 > rlm_realm: No '@' in User-Name = "802.1x client (i.e. supplicant)", looking up > realm NULL > rlm_realm: No such realm "NULL" > modcall[authorize]: module "suffix" returns noop for request 0 > rlm_eap: EAP packet type response id 1 length 36 > rlm_eap: No EAP Start, assuming it's an on-going EAP conversation > modcall[authorize]: module "eap" returns updated for request 0 > users: Matched 802.1x client (i.e. supplicant) at 65 > modcall[authorize]: module "files" returns ok for request 0 > modcall: group authorize returns updated for request 0 > rad_check_password: Found Auth-Type EAP > auth: type "EAP" > Processing the authenticate section of radiusd.conf > modcall: entering group authenticate for request 0 > rlm_eap: EAP Identity > rlm_eap: processing type tls > rlm_eap_tls: Requiring client certificate > rlm_eap_tls: Initiate > rlm_eap_tls: Start returned 1 > modcall[authenticate]: module "eap" returns handled for request 0 > modcall: group authenticate returns handled for request 0 > Sending Access-Challenge of id 1 to 192.168.0.1:1027 > EAP-Message = 0x010200060d20 > Message-Authenticator = 0x00000000000000000000000000000000 > State = 0x300257fa5ecadec2d8b4b19c39257dbc > Finished request 0 > Going to the next request > --- Walking the entire request list --- > Waking up in 6 seconds... > --- Walking the entire request list --- > Cleaning up request 0 ID 1 with timestamp 40a8bdd8 > Nothing to do. Sleeping until we see a request. > rad_recv: Access-Request packet from host 192.168.0.1:1028, id=4, length=149 > User-Name = "802.1x client (i.e. supplicant)" > NAS-IP-Address = 192.168.0.1 > NAS-Port = 1 > NAS-Identifier = "netgear-switch.domain.com" > NAS-Port-Type = Ethernet > EAP-Message = > 0x02040024013830322e317820636c69656e742028692e652e20737570706c6963616e7429 > Message-Authenticator = 0x80fb70a84b04a49a6b73fff351374948 > Processing the authorize section of radiusd.conf > modcall: entering group authorize for request 1 > modcall[authorize]: module "preprocess" returns ok for request 1 > modcall[authorize]: module "chap" returns noop for request 1 > modcall[authorize]: module "mschap" returns noop for request 1 > rlm_realm: No '@' in User-Name = "802.1x client (i.e. supplicant)", looking up > realm NULL > rlm_realm: No such realm "NULL" > modcall[authorize]: module "suffix" returns noop for request 1 > rlm_eap: EAP packet type response id 4 length 36 > rlm_eap: No EAP Start, assuming it's an on-going EAP conversation > modcall[authorize]: module "eap" returns updated for request 1 > users: Matched 802.1x client (i.e. supplicant) at 65 > modcall[authorize]: module "files" returns ok for request 1 > modcall: group authorize returns updated for request 1 > rad_check_password: Found Auth-Type EAP > auth: type "EAP" > Processing the authenticate section of radiusd.conf > modcall: entering group authenticate for request 1 > rlm_eap: EAP Identity > rlm_eap: processing type tls > rlm_eap_tls: Requiring client certificate > rlm_eap_tls: Initiate > rlm_eap_tls: Start returned 1 > modcall[authenticate]: module "eap" returns handled for request 1 > modcall: group authenticate returns handled for request 1 > Sending Access-Challenge of id 4 to 192.168.0.1:1028 > EAP-Message = 0x010500060d20 > Message-Authenticator = 0x00000000000000000000000000000000 > State = 0xdc43108973cf13e5b8040cd7af21e587 > Finished request 1 > Going to the next request > --- Walking the entire request list --- > Waking up in 6 seconds... > --- Walking the entire request list --- > Cleaning up request 1 ID 4 with timestamp 40a8bdf6 > Nothing to do. Sleeping until we see a request. > rad_recv: Access-Request packet from host 192.168.0.1:1029, id=6, length=149 > User-Name = "802.1x client (i.e. supplicant)" > NAS-IP-Address = 192.168.0.1 > NAS-Port = 1 > NAS-Identifier = "netgear-switch.domain.com" > NAS-Port-Type = Ethernet > EAP-Message = > 0x02060024013830322e317820636c69656e742028692e652e20737570706c6963616e7429 > Message-Authenticator = 0xce799670b6b88832fe175ba83b5bc6db > Processing the authorize section of radiusd.conf > modcall: entering group authorize for request 2 > modcall[authorize]: module "preprocess" returns ok for request 2 > modcall[authorize]: module "chap" returns noop for request 2 > modcall[authorize]: module "mschap" returns noop for request 2 > rlm_realm: No '@' in User-Name = "802.1x client (i.e. supplicant)", looking up > realm NULL > rlm_realm: No such realm "NULL" > modcall[authorize]: module "suffix" returns noop for request 2 > rlm_eap: EAP packet type response id 6 length 36 > rlm_eap: No EAP Start, assuming it's an on-going EAP conversation > modcall[authorize]: module "eap" returns updated for request 2 > users: Matched 802.1x client (i.e. supplicant) at 65 > modcall[authorize]: module "files" returns ok for request 2 > modcall: group authorize returns updated for request 2 > rad_check_password: Found Auth-Type EAP > auth: type "EAP" > Processing the authenticate section of radiusd.conf > modcall: entering group authenticate for request 2 > rlm_eap: EAP Identity > rlm_eap: processing type tls > rlm_eap_tls: Requiring client certificate > rlm_eap_tls: Initiate > rlm_eap_tls: Start returned 1 > modcall[authenticate]: module "eap" returns handled for request 2 > modcall: group authenticate returns handled for request 2 > Sending Access-Challenge of id 6 to 192.168.0.1:1029 > EAP-Message = 0x010700060d20 > Message-Authenticator = 0x00000000000000000000000000000000 > State = 0x51fda03f50417a07a57694d709af6669 > Finished request 2 > Going to the next request > --- Walking the entire request list --- > Waking up in 6 seconds... > > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- --Mike ----------------------------------- Michael Griego Wireless LAN Project Manager The University of Texas at Dallas - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
