We are trying to authenticate a wireless client using EAP-TLS on a Meraki AP against a FortiAuthenticator (with RADIUS).
The EAP-TLS is successful but the wireless client doesn´t receive a DHCP IP address, nor does it have network access. However, a wired EAP-TLS (computer authentication) request from the same client works flawlessly.
Parts of the debug log show:
(2794) facauth: ===>NAS IP:192.168.100.96
(2794) facauth: ===>Username:host/W10CLIENT.company.local
(2794) facauth: ===>Timestamp:1707907999.157486, age:1ms
(2794) facauth: Comparing client IP 192.168.100.96 with authclient Meraki-AP1 (192.168.100.96, 1 IPs)
(2794) facauth: ------> matched!
(2794) facauth: Found authclient from preloaded authclients list for 192.168.100.96: Meraki-AP1 (192.168.100.96)
(2794) facauth: authclient_id:2 auth_type:'eap-tls'
(2794) facauth: Found authpolicy 'EAPTLS' for client '192.168.100.96'
<SNIP>
(2794) facauth: Updated auth log 'host/W10CLIENT.company.local' for attempt from 192.168.100.96: 802.1x authentication successful
(2794) facauth: User-Name: host/W10CLIENT.company.local (from request)
<SNIP>
(2794) Sent Access-Accept Id 23 from 192.168.0.100:1645 to 192.168.100.96:49544 length 220
(2794) MS-MPPE-Recv-Key = <<< secret >>>
(2794) MS-MPPE-Send-Key = <<< secret >>>
(2794) EAP-Message = 0x031b0004
(2794) Message-Authenticator = 0x00000000000000000000000000000000
(2794) User-Name = "host/W10CLIENT.company.local"
(2794) Framed-MTU += 994
(2794) Tunnel-Type += VLAN
(2794) Tunnel-Medium-Type += IEEE-802
(2794) Tunnel-Private-Group-Id += "500"
(2794) Finished request
Has anyone else experienced this issue?
Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
After multiple support calls with Fortinet and Meraki in the same call, the Meraki engineer concluded that this wasn´t an authentication issue... she asked us to disable 802.11r on the SSID and after that, RADIUS authentication worked instantly!
Also, it worked with the default Framed-MTU of 994 bytes communicated by the FortiAuthenticator in the Access-Accept.
I see RADIUS puts you in VLAN 500.
This is the correct VLAN indeed and static IP doesn´t make a difference.
The thing is, if we redirect the RADIUS request to the (to be phased out) Cisco ISE, the wireless client gets an IP and is allowed on the network instantly.
So it looks like I´m missing something. The way FortiAuthenticator handles the request or requires additional RADIUS attributes to be set.
That's good info, so probably the issue is in FAC's RADIUS response.
As we can see here is the response from FAC:
(2794) Framed-MTU += 994
(2794) Tunnel-Type += VLAN
(2794) Tunnel-Medium-Type += IEEE-802
(2794) Tunnel-Private-Group-Id += "500"
First thing I'd check is to compare if any difference between ISE response and FAC response. It can be MTU or any other missing parameter like ACL id or other.
On the other hand you can check on Meraki WebUI if it shows your client in VLAN 500 when it receives the response from FAC.
Created on 02-16-2024 04:18 AM Edited on 02-16-2024 04:19 AM
Looking at the Cisco ISE configuration: the only difference seems to be a Set ACL setting under Network Device Profile that sets Filter-ID as a RADIUS attribute. Although I can´t find in ISE what it is that is being set.
But to be sure, we´ll be doing a debug on the Cisco Switch.
The packet captures shows that the Cisco ISE sets the following RADIUS attributes in the Access-Accept packet:
- User-Name = W10CLIENT$@domain (weird?)
- Class (25)
FAC does the following:
- Framed-MTU = set to 994
- User-Name = same as in Access-Request: host/W10CLIENT.company.local
Also, no traffic is seen after the Access-Accept. So no DHCP nor Accounting-Request/Response packets.
Created on 03-06-2024 07:46 AM Edited on 03-06-2024 07:46 AM
We made some progress after switching the RADIUS ports 1812/1813 instead of 1645/1646.
Also we´ve changed the Framed-MTU to 1200 in the Access-Accept resulting in Accounting-Request packets shown in the Packet Capture... however, no Accounting-Response packet to that and the Wireless Client still doesn´t receive an IP via DHCP.
If client asks for DHCP and there is no responce, then you have an issue with packets from DHCP client to the DHCP server - most likely, is the client not enabled correctly on the AP.
Since you seem to have it working when ICE is doing the authentication, I will assume the basic infrastructure/vlan trunking to the DHCP server is working just fine, so as @AEK mention, there might be some Radius responces missing/different.
Long time since i last messed with Meraki, but can you log on the AP/Management and see status of the user/device?
Maybe logs from that side? (Or is the logs above from Meraki?)
After multiple support calls with Fortinet and Meraki in the same call, the Meraki engineer concluded that this wasn´t an authentication issue... she asked us to disable 802.11r on the SSID and after that, RADIUS authentication worked instantly!
Also, it worked with the default Framed-MTU of 994 bytes communicated by the FortiAuthenticator in the Access-Accept.
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1732 | |
1106 | |
752 | |
447 | |
240 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.