Sun May 26, 2024 11:28 am
OK, I restarted from scratch.
My setup (topology see the image) :
PC1
Freeradius 3.0
user :
- user2 with password
R1 (default configuration)
- Usermanager
enabled authentication port (and accounting port)
added client (NAS in radius-speach) with ip-address and secret.
2 users :
- user1, with password
- user2, with same password as on Freeradius
both in "user group" "default"
S1 (default configuration)
- 2 RADIUS entries :
- IP-address pointing to R1 with corresponding secret
- IP-address pointing to freeradius-server with corresponding secret (disabled)
- Dot1X server
- ethers 1 to 6 and spfplus1 as dot1x (via an interface list).
- Auth.Types : dot1x checked
- Retrans. Timeout : 5sec.
S2 (default configuration)
- Dot1X client
Interface : sfpplus1
EAP Methods : EAP MSCHAPv2
identity : user1
password : <as on R1>
Anon. Identity : anonymous
PC2 : Kubuntu 24.04LTS with NetworkManager
not connected to the network
Procedure :
To have a baseline I started with pure mikrotik, so RADIUS on S1 pointing to R1. The result was an authenticated sfp-sfpplus1.
Next I connected PC2 to ether3 and tried to connect withouth autentication, this failed as axpected.
Then I set up PC2 to connect with 801.1x authentication as user2, but that failed, no matter what authentication methods I tried.
Now, on S1 I disabled the RADIUS entry to R1 and enabled that to Freeradius.
I tried to connect PC2 to ether3 with 801.x authentication, again as user2, with PEAP/MSCHAPv2 and I could connect.
So there is a difference between freeradius and mikrotik's User Manager in the handling of dot1x.
On PC2 I sniffed the traffic on the network port and there it shows :
after the "Client Hello" of the PC, the mikrotik-port answers "Alert (Level: Fatal, Description: Handshake Failure)".
See the (zipped) pcap-file.
FWIW, Windows 11 with PEAP/MSCHAPv2 behaves the same, i.e. no access with mikrotik User Manager.
You do not have the required permissions to view the files attached to this post.