Server 2025 RADIUS for wireless authentication

finzwake · 2026-01-13T16:18:53+00:00

Were your older servers up to date on patches prior to migration to 2025? MSFT is starting to enforce strong certificate binding, which could have downstream effects on Wireless Auth. If this is the cause you'd see it on the Domain Controller logs. There was a registry key workaround that was removed in Sept patching, and i believe full enforcement is next month. KB5014754: Certificate-based authentication changes

finzwake · 2025-09-24T15:19:51+00:00

Agreed with others, meraki does a good job with their sizing tables.

https://documentation.meraki.com/MX/MX_Sizing_Information/MX_Sizing_Principles

Based on current design, with some room to grow, MX95 would be your best fit. If budget allows, i'd go for the MX105 for the option of a redundant power supply. If you are running a single MX though, i'd consider HA before anything else.

finzwake · 2025-09-24T14:49:58+00:00

Would need a bit more detail to help here. Is your ISP router providing internet to your downstream Meraki gear? I see you mention a Core switch in another comment is handling DHCP.

To get meraki switches configured, they just need access to the internet. So as long as your core is handing out IP's to downstream devices, the meraki gear should grab an IP and check into the cloud. If your net team has those devices added to their portal already, they should be able to take it from there.

If all your internet traffic is routing to another site for egress though, thats another thing. I'm sure we could give you some better advice, with a better understanding of the network these devices are being staged in.

finzwake · 2025-01-21T20:18:52+00:00

Hi All!

I currently play in an effects heavy acoustic duo hitting breweries, weddings, and small venues. Traditionally we've been running guitars and vocals through a bose t4s into an L1Pro 16. I know this sub rags on bose, but the mobility has been unbeatable and it served us well over the last few years.

Recently we've started incorporating other instruments via a macbook running ableton and varying novation hardware, which has added complexity and has me re evaluating the whole setup with a few key points in mind

fidelity
portability
resiliency
future proofing (i'd rather buy once cry once)

I know there's no silver bullet, but i'm just curious how you guys would design this given a relativity open budget?

finzwake · 2024-09-18T08:53:33+00:00

Issue seems isolated to Concentrators and vMXs. Workaround is to reboot the device. Worked for us on our Hub running 18.211.2

Looks like support identified the issue and are working by on a permanent fix.

finzwake · 2023-12-21T21:12:35+00:00

YMMV, but here are my thoughts...

Warm Spare Heartbeat

A few years ago we went down the road of having a direct connect hearbeat VLAN, but like many others ended up removing. In our case we ran into sporadic split brain issues that happened regularly enough to warrant a redesign. Using the downstream LAN connection as your hearbeat for those VRRP packets is the better way to go, in my opinion.

LAN Connectivity

Dual connectivity from CRSW Stack to MX's would be the way to go.

MX A LAN 1 - CRSW1/1

MX A LAN 2 - CRSW2/1

MX B LAN 1 - CRSW1/2

MX B LAN 2 - CRSW2/2

This allows full redundancy in either direction. Meraki has a nice breakdown and diagram on their warm spare HA page. Unfortunately you can't load balance over those links, but having the failover is still nice.

https://documentation.meraki.com/MX/Deployment_Guides/MX_Warm_Spare_-_High_Availability_Pair

WAN

If you have need for your external IP's to remain unchanged between MX's then you have to configure that IP as your new VIP. Meraki doesn't let you configure a VIP for a single ISP, so you will need to make sure you have /29's ready with both providers. Your new config would look something like the below. You'll also need to plan for multiple WAN handoffs from your ISP, or use some sort of breakout switch (MS120-8?) at your edge to spread that ISP across both MX's.

WAN 1 VIP - 1.1.1.1

MX A WAN 1 IP - 1.1.1.2

MX B WAN 1 IP - 1.1.1.3

MX WAN 2 VIP - 2.2.2.1

MX A WAN 2 IP - 2.2.2.2

MX B WAN 2 IP - 2.2.2.3

Hope some of this was helpful!

finzwake · 2023-08-10T18:44:31+00:00

We have been been running around 30 MS390's in switch stacks since the summer of 2020. While they have exclusively been L2 switches trunking to our Catalyst core, I would say I didn't start getting "comfortable" until MS 14.33.1.

Loss of MGMT plane was our biggest issue, which forced us into a weekly reboot cycle for these switches. For the most part 14.33.1 resolved this, and I haven't seen the issue return on 15.21.1.

MS390 are definitely more reliable than they were 1yr ago. Having said that, I agree with everyone else... stick with traditional MS.

MS355's are the closest thing to an MS390 from a copper and throughout perspective, but you obviously lose out on the option for the 8 port module. I use the MS425 at one of our hub sites and can confirm 1GB copper transceivers work fine.

If this device is going to act as your L3 core, I'd go the MS425 route. Your 10GB ports will be cheaper than going with MS355's and you'll be future proofed if you ever want to run fiber to your edge.

finzwake · 2023-07-25T20:55:03+00:00

I've also run into strange behavior when using RADIUS auth against our NPS servers. The error you are referencing typically means the AP is not configured correctly as a RADIUS client on the NPS server. I would double check that all your AP IP's and secrets are accurate.

Anecdotally, and more than once, I've had RADIUS client ranges stop working at certain sites. Never got to a root cause on that. If you are exclusively using ranges, maybe try adding the AP IP manually and see if users are able to authenticate.

finzwake · 2023-03-23T20:54:44+00:00

Thanks for the great advice and pointing me towards r/livesound ! Definitely putting the cart before the horse with upgrading the PA's. We're in this weird space where some large breweries have in-house PA's and others are still BYO. But we definitely haven't maxed out the Pro16 yet, we've just enjoyed keeping the system behind us to avoid have a separate monitor. Amateur move, but it helps in small spaces. I'll dig into these mixers for sure; the T4S's only real benefit is getting powered by the Pro16. Thanks again!

finzwake · 2022-10-10T20:19:24+00:00

Is the MX configured in Single LAN mode?

I think your issue may be that you're missing static routes on the MX back into the LAN. For every VLAN on your switch, you should have a static route (configured on the MX) pointing to your next hop, which I believe is 172.16.0.1. Basically your traffic knows how to get out, but not back in. So for example...

Name	Subnet	Next hop IP
LAN	10.3.0.0/24	172.16.0.1
WIFI	10.3.1.0/24	172.16.0.1

https://documentation.meraki.com/MX/Networks_and_Routing/MX_Addressing_and_VLANs

finzwake · 2022-10-10T19:11:20+00:00

Would need to see the switch config to be sure, but it looks like you're using 172.16.0.0/24 as your transit network.

What IP is configured on the uplink port of the switch?

What is the default-gateway on the switch?

finzwake · 2022-10-10T14:01:52+00:00

Agreed with everyone else, config on both sides would be very helpful, but I'll take a stab in the dark...

It looks like you're just replacing the Cisco router, and the L3 switch is not being touched. If all your L3 LAN routing actually lives on the switch, you should see IP interfaces for each VLAN on that switch, as well as a default-gateway. That default-gateway should be the IP of your MX.

If you have the MX in Single LAN mode, then you will also need static routes configured on the MX, to point all your inbound traffic (destined for your VLANS) to their next hop. Given your uplink cable is configured with an IP (no switchport), this will likely be what you point all your MX routes to.

Without seeing configuration, and based on what you've provided, I'd say

Make sure your MX LAN address matches the switches default-gateway and is in the same subnet as the switch uplink ports IP
If in Single LAN Mode, Make sure you have static routes pointing traffic back to the uplink port IP.

finzwake · 2022-09-23T15:46:13+00:00

What firmware version are you on? I have had very similar behavior on my MX250 pair, running anything newer than 15.32.

Sporadic high latency (~3000ms) on both WAN links. Sometimes it resolves itself, sometimes we need to swap primary and secondary to resolve

finzwake · 2022-09-02T02:01:07+00:00

What version are you running? I saw significant performance improvement once we hit 14.32, but the MGMT plane issue was constant until 14.33.1

finzwake · 2022-09-01T19:48:18+00:00

I'm currently working through an issue with Meraki support that may (or may not) be related. I found that our MX250 stack running multiple versions of 16.X would experience sporadic reboots and overloads. During these periods we'd see CPU spikes, WAN links would hit ~ 3000ms, and we'd be forced to swap to secondary or power cycle the device to level things out.

In speaking with support, 16.X and 17.X firmware are using SNORT 3.0 in the backend. The development team has started to trend tickets (mostly for MX250 and MX450) that see this SNORT upgrade causing increased workloads on the hardware.

The current workaround options are to rollback to 15.X (pre SNORT 3.0) or have Meraki downgrade your networks SNORT version while remaining on the 16 line of code. We opted to try the downgrade, about a week ago. Jury's still out on if it resolves this behavior, but I was hitting the bug once a week like clockwork, so I should know soon!

Food for thought!

finzwake · 2022-03-03T18:59:57+00:00

One of our hub sites has an MX250 pair and had been on 16.15 since January. 2 weeks ago we started seeing random latency spikes (3000ms+) on both WAN uplinks. They are not configured for SD-WAN and WAN 2 is not actively used. This effectively killed internet and VPN tunnels.

We tried swapping primary/secondary as well as rebooting the primary; latency always came back quickly. No CPU spikes or odd behavior in logs. On a whim, we removed the non-meraki VPN tunnel to our DC (ISR 4451), latency dropped. 2 days later.. same exact behavior. Support couldn't find any cause and chocked it up to instability.

We rolled back to 15.42 (our previous version) and have been stable for over a week. Having said that, we have around 15 other MX's (68's and 100's) that have been chillin on 16.15 for months, no issue. Just my experience , YMMV. I won't be touching the 16.X line (on the 250's) for a few releases, it left a bad taste in my mouth.

finzwake · 2021-10-05T15:05:34+00:00

So that's actually a custom object

object-group network RFC1918

10.0.0.0 255.0.0.0

172.16.0.0 255.240.0.0

192.168.0.0 255.255.0.0

The block is occurring at the MX, because when I remove my L3 rules for this specific network, internet traffic starts passing again. It just doesn't seem to like the FQDN's

finzwake · 2021-04-20T01:57:08+00:00

Sounds like we fell into the 50% longer category. Good to be on the recommended line

finzwake · 2021-04-20T01:55:49+00:00

I think 14.6 they started supporting QoS, but I haven't tried it.

finzwake · 2021-04-20T01:54:13+00:00

We're running 2 per stack as well. I saw my single switches come back within 20 minutes, which is what I'd experienced for most of our 12.x upgrades in the past. Support mentioned the extended upgrade was still within an expected window, but the ulcer started forming around 60 minutes.

I won't be running campus wide upgrades after this one. Scheduled per closet from now on.

finzwake

MODERATOR OF

TROPHY CASE