Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
Ernie
New Contributor II

Wireless client fails to receive DHCP when connecting to a Meraki AP / FortiAuthenticator

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?

 

1 Solution
Ernie
New Contributor II

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. 

 

View solution in original post

8 REPLIES 8
AEK
SuperUser
SuperUser

I see RADIUS puts you in VLAN 500.

  • Is it the correct VLAN ?
  • Can you check on Meraki if it really shows you in VLAN 500?
  • Can you try take static IP to see if at least you reach your default GW?
AEK
AEK
Ernie
New Contributor II

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. 

AEK

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.

AEK
AEK
Ernie
New Contributor II

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.

Ernie
New Contributor II

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.

Ernie
New Contributor II

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.

Jakob-AHHG

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?)

Jakob Peterhänsel,
IT System Admin,
Arp-Hansen Hotrel Group A/S, Copenhagen, DK
Jakob Peterhänsel,IT System Admin,Arp-Hansen Hotrel Group A/S, Copenhagen, DK
Ernie
New Contributor II

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. 

 

Announcements

Select Forum Responses to become Knowledge Articles!

Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

Labels
Top Kudoed Authors