Meraki MR12 AP and FortiAuthenticator as RADIUS

[_Ernie_]

We are migrating our RADIUS server from a Cisco ISE to a FortiAuthenticator (FAC) for our Meraki equipment.

A packet capture shows a successful Access-Accept in a packet capture, however the wireless client behind the Meraki doesn´t get DHCP nor network connectivity when authenticating against the FAC. When authenticating against the ISE, it works instantly.

The difference in the packet capture between ISE and FAC are that the ISE returns a rewritten User-Name value and a Class while the FortiAuthenticator doesn´t:

ISE:

• Access-Request: User-Name = host/W10CLIENT.company.local
• Access-Accept: User-Name = W10CLIENT$@domain
• Class (25) AVP

FortiAuthenticator:

• Access-Request: User-Name = host/W10CLIENT.company.local
• Access-Accept: User-Name = host/W10CLIENT.company.local
• No Class (25) AVP

My question now is, what does the Meraki MR12 Access Point expects as the minumum required RADIUS attributes (AVP) packets for allowing the user onto the network?

[alemabrahao]

Refer the documentation.

MR Meraki RADIUS 2.0 - Cisco Meraki Documentation

Configuring RADIUS Authentication with WPA2-Enterprise - Cisco Meraki Documentation

[_Ernie_]

Trust me, I did. Over and over again... 😉

There´s nothing in there about the RADIUS attributes User-Name* or Class.

*EDIT* nothing in there about the way User-Name is expected or that it needs to be rewritten.

And it would surprise me if Filter-ID is needed because we are not using group policies and the Cisco ISE doesn´t return this AVP either.

[alemabrahao]

[alemabrahao]

Maybe it will help you.

https://docs.fortinet.com/document/fortinac-f/7.2.0/cisco-meraki-mr-access-points-integration/174691...

[_Ernie_]

Thanks Alessandro for helping, much appreciated.

I´ve seen this document too... unfortunately we are not using Group Policies, so the only difference would be "RADIUS CoA support" which is set to enabled. However, with Cisco ISE as the RADIUS server, we don´t see CoA packets in the capture so it wouldn´t make any sense. 😞

[alemabrahao]

Look, I'll be very honest, I've already configured 802.1x using Freeradius, NPS and ISE and I've never had any problems.

There is probably some configuration missing in FortiAuthenticator, but unfortunately I don't have expertise with this tool.

It would be interesting to open a support case with Fortinet.

[alemabrahao]

Take a look at this discussion.

https://community.meraki.com/t5/Wireless-LAN/MR-Access-Point-Integration-with-FortiGate/m-p/79617

And also this document.

https://fortinetweb.s3.amazonaws.com/docs.fortinet.com/v2/attachments/2c24abee-23c3-11ed-9eba-fa163e...

[_Ernie_]

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.

[CptnCrnch]

---

ISE:

• Access-Request: User-Name = host/W10CLIENT.company.local
• Access-Accept: User-Name = W10CLIENT$@domain
• Class (25) AVP

FortiAuthenticator:

• Access-Request: User-Name = host/W10CLIENT.company.local
• Access-Accept: User-Name = host/W10CLIENT.company.local
• No Class (25) AVP

Your FortiSomething is giving back the wrong Username and class. Therefore, it has to be configured correctly.

On a sidenote: why would anybody even think about replacing ISE with that FortThing? Serious question.

[_Ernie_ · Accepted solution]

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.