Re: freeradius denies to authentocate with eap-tls

Hello Stuart.

I've created a separate thread about this in misc with
Subject:(fragmented ipv4[udp] ignored by server.) . And sorry for this.

Don't know why posts to this thread was not accepted.

Basic set-up, recommended by you previously already working. Also if set
fragment_size to less lower value - for example 1212 in
wpa_supplicant.conf - this eap tls too works. Question - how to avoid
client configuration by fragments_size and get it working? Cause some
clients could not be altered so easily.

Also certificate key size is 2048b.

Thank you.

On 3/6/23 12:03, Stuart Henderson wrote:
> On 2023/03/02 17:24, Mikhael Lialin wrote:
>> Hello and good day.
>>
>> Finally found the actual reason.
>>
>> The outer client is failed eap tls because of packet fragmentation. on
>> interface mtu is set as 1500, and packet is 1514.
>>
>> from tshark:
>>
>> RADIUS 1514 Access-Request id=4[BoundErrorUnreassembled Packet]
>> RADIUS 1514 Access-Request id=4, Duplicate Request[BoundErrorUnreassembled
>> Packet]
>> RADIUS 1514 Access-Request id=4, Duplicate Request[BoundErrorUnreassembled
>> Packet]
>> RADIUS 1514 Access-Request id=4, Duplicate Request[BoundErrorUnreassembled
>> Packet]
> What do you see from freeradius debug output when this happens?
>
>> if set fragment_size to wpa_supplicant.conf to a little below value, it
>> helps and eap_tls is successful.
>>
>> It's good for configurable client, however how about phones where all
>> parameters are default ?
> It doesn't help you, but the RADIUS client is not the device trying to
> connect to wifi, it's the AP.
>
> It wasn't clear from your report, does it work with non-cert-based
> methods e.g. EAP MSCHAPv2 or not?
>
> If that's working and the problem is only with certificate auth, one
> thought, are you able to shrink the certs at all? If you're using
> 3072/4096 bit RSA keys, try 2048bit instead.
>
> I would try asking on the freeradius mailing list too. Be clear exactly
> what you're testing (e.g. show the config on the client) and include the
> full radiusd debug output, maybe also include packet dumps (full rather
> than just the 1-line summary you showed here).
>
> I don't think this is likely to be openbsd-specific.