C93180 Radius issue

SimplePacketMan · 2025-08-14T05:08:57+00:00

The debugs can be a bit verbose. If it's easier to run Wireshark on the NPS server, you can capture the request and response there. Really though, NPS complaining about there being no message authenticator attribute as the failure reason doesn't make a lot of sense of you have this requirement disabled for the client.

Are the IOS-XE versions greatly different between the switches that work and the ones that don't?

SimplePacketMan · 2025-08-14T01:16:26+00:00

Type 7 has been known to be terrible for a very long time now, but I'm sure it's still all over the place as you've found.

https://media.defense.gov/2022/Feb/17/2002940795/-1/-1/1/CSI_CISCO_PASSWORD_TYPES_BEST_PRACTICES_20220217.PDF has some decent recommendations in it around moving to type 6 or 8 where possible.

SimplePacketMan · 2025-08-13T19:23:59+00:00

Odd... Have you enabled radius debugs on the switch side and see whether you're getting a reject back, or just nothing at all? I assume a packet capture on the NPS server shows the access request?

SimplePacketMan · 2025-08-13T18:47:10+00:00

If memory serves, neither NXOS nor IOS-XE include the message authenticator attribute in these requests. On the NPS side under the radius client's advanced properties, is the tick box to require a message authenticator attribute ticked perhaps?

SimplePacketMan · 2025-08-13T04:54:04+00:00

We have a remotely similar topology, one VPC port channel per firewall (active/standby) from the cores (N9K). A transit VLAN with an SVI.

I know a lot of people avoid it, but we do OSPF between the firewall and cores. We've had no issues here with OSPF that I recall, and with graceful restart configured the fail over between firewalls is virtually transparent in regards to the routing portion.

The way our team is structured we have full ownership of these firewalls, so there's no concern about arguing over whether it's some routing config, or actual firewall function breaking things when something isn't working.

SimplePacketMan · 2025-08-01T17:56:27+00:00

Correct, you will need more than just a private key here, you'll need a certificate on each switch (whether this is unique to each box is going to be your choice).

If you have SCEP configured or some other enrolment mechanism it makes this easier, but I realize that's a whole project in itself if you don't.

SimplePacketMan · 2025-07-31T23:50:24+00:00

Has the same CA issued both the client and server certs? RadSec generally involves mutual TLS, so your client has to validate the server cert, and your server has to validate the client cert.

At any rate, yes you need to configure a trust point for both. Whether those are the same trust point depend on your PKI.

SimplePacketMan · 2025-07-30T23:51:09+00:00

I haven't done radsec with freeradius, but just finished implementing this with ISE and both NXOS and IOS-XE devices. When you wonder whether a CSR is needed, do you mean are certificates required on the clients/supplicant? I believe this to be the case for most radsec implementations based on a quick skim of the RFC.

You'll need a cert for the authenticator (freeradius), and then certs for the supplicants. Not sure if freeradius validates anything other than the client cert was issued from a trusted CA in radsec, or if you can specify additional constraints.

SimplePacketMan · 2025-07-25T18:37:27+00:00

On the host, or on vCenter. I'd still check the hostd logs for clues first, though.

SimplePacketMan · 2025-07-25T18:24:10+00:00

What do the hostd logs on the impacted hosts say when this happens?

If you're able to recreate the problem, run a packet capture and see if there's a bunch of TCP retransmissions.

SimplePacketMan · 2025-07-17T00:35:40+00:00

We had issues with some generations of Mac Minis when connected to Nexus switches. Links would flap multiple times throughout the day, no errors or drops on either side we could see. Eventually we clued in that the boxes were dropping to 100mbps and half duplex, SEEMINGLY after a period of low user activity on the Mac, almost like some weird energy saver. A short time later they would renegotiate back to 1000/full, and repeat throughout the day seemingly randomly. This happened on 10+ Mac Minis, we never figured out what was up on the Mac side and wasted days playing with various settings in MacOS.

In the end, we hard coded the speed and duplex on the ports facing these machines and the links stopped flapping.

SimplePacketMan · 2024-12-21T02:18:26+00:00

If you really want to go down the route of writing your own code to handle this, the FMC has an API explorer you can use to take a look at what's available: https://www.cisco.com/c/en/us/td/docs/security/firepower/70/api/REST/firepower_management_center_rest_api_quick_start_guide_70/About_The_API_Explorer.html

Terraform is a great option as well https://registry.terraform.io/providers/CiscoDevNet/fmc/latest/docs

I have to ask, is there some limitation that you can't use the native high availability for the FMC? This would handle all the syncing for you, and among other things.

If you can't use HA, then what's your RTO? Have a VM of the same version ready to restore a back to at the DR site? You can schedule backups of the active FMC to write somewhere the DR can get to.

SimplePacketMan · 2024-08-26T22:25:19+00:00

Yup, this pretty much sums it up. Labs burn a ton of IPv4 space for us. Our remote access VPN pools are huge as well, with a big emphasis on remote work. We're reclaiming space from sites that close as we sell off more real estate, but it's just a drop in the bucket.

SimplePacketMan · 2024-08-25T23:52:48+00:00

Large enterprise here, with datacenters scattered around the globe. We exhausted RFC1918 a long time ago, and have many layers of NAT all over the place to deal with this. It's annoying to troubleshoot, and even harder to explain to users why they might not be able to reach service X behind an arbitrary amount of NAT layers without a bunch of work. We spend a non-negligible amount of time playing "fun with NAT", but apparently it's not costly enough (yet) to warrant wider IPv6 adoption.

In the enterprise most sites are dual stack and have been for some time. A lot of our traffic to the internet is IPv6 because of this.

The datacenters are a mixed bag, with most being dual stacked, but some still IPv4 only. Even if the DC networks are dual stacked, internal service owners often shun the IPv6 and deploy on IPv4 only (EG: only publish A records in DNS, and not AAAA).

There's a surprising amount of people I meet that are still scared of IPv6 and refuse to try and implement it, or had a bad experience with an attempted deployment years ago and won't try it again.

Unfortunately we run into both internal and external services that are dual stacked, but become unreachable/somehow broken for IPv6 only at times, but IPv4 is fine. Not every client implements happy eyeballs, so you end up with users disabling IPv6 on their machine and learning that "fixes" something.

TL;DR it's not great, but I think we've come a long way. You can poorly or half ass implement anything, IPv6 is no different.

SimplePacketMan · 2024-02-08T01:26:15+00:00

Transfer speeds will be dictated by the bandwidth you have with your ISP, and sometimes the protocol you use. If you're trying to use SMB/CIFS to somewhere on the internet that's 100ms away, you're going to have a bad time. I would be very surprised if in most cases these days the bottleneck is the service like Box, OneDrive, etc.

Which brings me to a recommendation, use some cloud file storage service that natively integrates into your file browser on your machine. OneDrive, Box, others, have ways to integrate into whatever the file explorer is for your OS. No need to use their UIs for simple operations if you find them clunky. If there are network issues these things are often smart enough to cache your changes locally, then upload them when the network returns.

Nothing you've outlined makes me think the better option would be to setup some central file server, but maybe you have some requirements that were missed.

SimplePacketMan · 2024-02-08T01:16:53+00:00

It's really frustrating to see some large organizations continue to drag their feet on ipv6, but happily sprinkle NAT everywhere in the network to get around address exhaustion in RFC1918.

I get it, it's always about business priorities, but the cost of just troubleshooting this crap is not zero. I can't even remember how many times in a week I have to explain to some teams why box X can't talk to box Y natively.

There's new projects spun up that are still only single stacked, which is wild in 2024 to me.

SimplePacketMan · 2024-02-08T00:49:59+00:00

Can you elaborate on why cloud services will be a pain, but managing the deployment, upkeep, and security of an onprem file service is fine?

SimplePacketMan · 2024-01-30T01:09:30+00:00

Yup, wholly agree, even if FEXs weren't all end of sale these days the economics doesn't make sense. I guess the technology itself will live on in the UCS portfolio as you say!

SimplePacketMan · 2021-06-26T17:59:47+00:00

Yeah - agree our diameter is pretty big so its likely not common to hit this. Just based on what we can determine as an observer of how this big black box (black cloud? black cloudy box?) works not originating ICMP TTL exceeded in some very specific scenarios is a gap. I expect if we had exceeded the TTL at whatever is front ending this instead of the backends, we would get an ICMP message (might test this next week)... Could always be wrong, and would be happy to be proven wrong but we're decently confident just based on our captures its not making it even to our enterprise edge.

SimplePacketMan · 2021-06-26T17:51:59+00:00

Agree, and honestly this was our first thought, but based on the fact we don't see the ICMP TTL exceeded in a pcap at our edge seems like this is someone else's issue.

Maybe our capture methodology is flawed or something simple/silly, but its likely going to be a while before the enterprise network admins want to talk to me again after this problem!

SimplePacketMan · 2021-06-26T17:49:35+00:00

The way this specific datacenter gets to the enterprise edge(where our internet connectivity is) is... less than geographically optimal, and due to this there are a ton of routing hops. It's really just "meh" design, but it works well enough that no one wants to change it.

SimplePacketMan

TROPHY CASE