Re: [RADIATOR] EAP-TLS not getting client cert
Hi, On Mon, 1 Feb 2016, Hartmaier Alexander wrote: > Hi, > I'd say the client doesn't trust the radiator certificate and stops the > EAP conversation. the same client worked when on site. It failed when offsite and the requests were coming over the vpn. It turned out to be a firewall with huge mtu on the inside interface that was sending jumbograms that got dropped on the radius. Greetings Christian > > Best regards, Alex > > On 2016-01-18 12:30, Christian Kratzer wrote: >> Hi Sami, >> >> On Mon, 18 Jan 2016, Sami Keski-Kasari wrote: >>> Hello Christian, >>> >>> Usually this kind of behaviour is due to MTU problems. >>> There can be differences between different vendors for example how they >>> do tunnelling and how it affects to MTUs etc. >>> >>> Please try to adjust maximum TLS fragment size to see if it helps. >>> >>> Please see more at page 92 >>> 5.21.39 EAPTLS_MaxFragmentSize >>> in ref.pdf. >> yes we already have that set to 500. >> >> Just for understanding EAPTLS_MaxFragmentSize would only affect what >> radiator sends. There is no way to limit the size of the fragements coming >> from the ap. >> >> The trace4 logs stop exactly at the point radiator has completed sending of >> it's certificate to the client. >> >> I would assume that I would at least see the first of the packets with the >> client certificates. If not this could perhaps also be an issue with the >> network dropping incoming udp fragments and the os never being able to >> reassemble incomplete packets. I will have the customer check into that as >> well. >> >> Greetings >> Christian -- Christian Kratzer CK Software GmbH Email: c...@cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer Web: http://www.cksoft.de/ ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] EAP-TLS not getting client cert
Hi, I'd say the client doesn't trust the radiator certificate and stops the EAP conversation. Best regards, Alex On 2016-01-18 12:30, Christian Kratzer wrote: > Hi Sami, > > On Mon, 18 Jan 2016, Sami Keski-Kasari wrote: >> Hello Christian, >> >> Usually this kind of behaviour is due to MTU problems. >> There can be differences between different vendors for example how they >> do tunnelling and how it affects to MTUs etc. >> >> Please try to adjust maximum TLS fragment size to see if it helps. >> >> Please see more at page 92 >> 5.21.39 EAPTLS_MaxFragmentSize >> in ref.pdf. > yes we already have that set to 500. > > Just for understanding EAPTLS_MaxFragmentSize would only affect what radiator > sends. There is no way to limit the size of the fragements coming from the > ap. > > The trace4 logs stop exactly at the point radiator has completed sending of > it's certificate to the client. > > I would assume that I would at least see the first of the packets with the > client certificates. If not this could perhaps also be an issue with the > network dropping incoming udp fragments and the os never being able to > reassemble incomplete packets. I will have the customer check into that as > well. > > Greetings > Christian > > *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien Handelsgericht Wien, FN 79340b *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* Notice: This e-mail contains information that is confidential and may be privileged. If you are not the intended recipient, please notify the sender and then delete this e-mail immediately. *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] radiator never gets to the 2nd authentication phase in PEAP - MSCHAPv2
Indeed - the old adage is very true: “Just because a packet can get somewhere does not mean that the reply can get back….” regards Hugh > On 1 Feb 2016, at 20:39, Hugo Veiga wrote: > > Hi, > > Heikki I bow to you. :) > > So the problem was this: > (Topology) > Radiator Machine/ IP: 10.253.1.12/24 > --Router--wireless switch/IP:10.240.1.1/24 > - The radiator machine receives requests from wireless switch. > - Wireless switch never receives the answer. > :: So Radiator machine is a virtual machine and installed by a colleague of > mine (system admin) that inserted the mask 255.0.0.0 in the network mask. > Radiator machine with the supplied mask will try to contact 10.240.1.1 > through arp discovery and will never find it because it's on a different > broadcast domain. The solution was obvious, insert the correct netmask and it > started to work perfectly. > > Problem solved. > Many thanks Heikki, > Hugo Veiga > > > > > > Code: Access-Request > > > > Identifier: 180 > > > > Authentic: <139><3>(<143><10><139>N<158><194><163><168><135>O > > > Radiator notices this and retransmits its previous reply > > > > Tue Jan 26 15:54:57 2016: INFO: Duplicate request id 180 received from > > > > 10.240.1.1(20004): retransmit reply > > > > Tue Jan 26 15:54:57 2016: DEBUG: Packet dump: > > > > *** Sending to 10.240.1.1 port 20004 > > > There are multiple retransmits back and forth and the authentication > does not proceed. > > I would check the Wi-Fi controller logs and make sure it is receiving > > the responses from Radiator. > ___ > radiator mailing list > radiator@open.com.au > http://www.open.com.au/mailman/listinfo/radiator -- Hugh Irvine 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, SIM, etc. Full source on Unix, Linux, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] radiator never gets to the 2nd authentication phase in PEAP - MSCHAPv2
Hi, Heikki I bow to you. :) So the problem was this: (Topology) Radiator Machine/ IP: 10.253.1.12/24 --Router--wireless switch/IP:10.240.1.1/24 - The radiator machine receives requests from wireless switch. - Wireless switch never receives the answer. :: So Radiator machine is a virtual machine and installed by a colleague of mine (system admin) that inserted the mask 255.0.0.0 in the network mask. Radiator machine with the supplied mask will try to contact 10.240.1.1 through arp discovery and will never find it because it's on a different broadcast domain. The solution was obvious, insert the correct netmask and it started to work perfectly. Problem solved. Many thanks Heikki, Hugo Veiga >* Code: Access-Request *>* Identifier: 180 *>* Authentic: <139><3>(<143><10><139>N<158><194><163><168><135>O * Radiator notices this and retransmits its previous reply >* Tue Jan 26 15:54:57 2016: INFO: Duplicate request id 180 received from *>* 10.240.1.1(20004): retransmit reply *>* Tue Jan 26 15:54:57 2016: DEBUG: Packet dump: *>* *** Sending to 10.240.1.1 port 20004 * There are multiple retransmits back and forth and the authentication does not proceed. I would check the Wi-Fi controller logs and make sure it is receiving the responses from Radiator. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
