Issue with EAP authentication on packet loss

[jm+freeradiususer at roth.lu]

On 4/25/2018 4:51 PM, Alan DeKok wrote:
> On Apr 25, 2018, at 10:45 AM, jm+freeradiususer at roth.lu wrote:
>> Unfortunately, that doesn't seem to be the case.
>>
>> Final packet sent to the NAS (which is lost):
>> (5) eap: Expiring EAP session with state 0x88491844885a1c9c
>> (5) eap: Finished EAP session with state 0x88491844885a1c9c
>> (5) eap: Previous EAP request found for state 0x88491844885a1c9c, released from the list
>>
>> NAS retries after 15 < cleanup_delay = 20 seconds: No success: (even Wireshark detects it as a duplicate, so I guess it is actually a repetition of the initial packet)
>    If it's a duplicate packet, then the duplicate detection cache should catch it.  Especially if cleanup_delay is 20 seconds, and the NAS retransmits after 15.
>
>> (6) eap: ERROR: rlm_eap (EAP): No EAP session matching state 0x88491844885a1c9c
>> (6) eap: Either EAP-request timed out OR EAP-response to an unknown EAP-request
>> (6) eap: Failed in handler
>    That means the packet *wasn't* found in the duplicate detection cache.
>
>    If it can be reproduced in 6 packets, then do "radiusd -Xx" and send that to the list.  This is one of the few times where the extra 'x' is useful.
>

Ha! The 3.x branch has a limit:

Thu Apr 26 17:04:35 2018 : Warning: WARNING: Ignoring "cleanup_delay = 
20", forcing to "cleanup_delay = 10"

The docs talk about "useful ranges", not ranges being capped ;-) Well 
guess I need to find out how to tweak the NAS then (and hope a delay < 
10 solves the issue)


Sidenotes:

At first I was not sure if simulating packet loss using iptables was the 
correct way because it generated :
Wed Apr 25 17:21:53 2018 : ERROR: (5) Failed sending reply: sendto 
failed: Operation not permitted

Then I tried NATing the concerned output packets to a blackhole address 
but for some reason the freeradius traffic does not seem to go through 
netfilter's NAT tables even though I am able to use its filter tables 
(as I outlined above). Strange.

Then I tried blackhole routing the reply which seems to have worked, so 
for future reference:
iptables -t mangle -A OUTPUT -j MARK --set-mark 6 -p udp --sport 1812 -m 
string --algo bm --string "123456789ABC"
ip route add table 6 default via 127.0.0.1
ip route flush cache

To reset:
ip route flush table 6
ip route flush cache