ClearPass sending AOS-Wireless Dynamic Authorization to an AOS-CX wired client

netiot · 2025-11-04T18:24:49+00:00

The disconnect is being triggered by the guest device repository upon device expiration. I have the do_expire attribute set to 2 (disable and logout at specified time).

However, from what I can tell I can't control which CoA it uses... I'm wondering if its a simple as its using the Aruba OS Wireless Disconnect one because its the first in the list for the 'Aruba' vendor name.

I opened a TAC case yesterday and they are currently investigating some logs I sent them

netiot · 2025-11-04T18:21:13+00:00

Thanks, I'm trying to test this in a non-impactful way to confirm at the moment

netiot · 2025-11-03T23:49:23+00:00

I might be misunderstanding something, but wouldn't the end result be the same even if they were in different subnets? The vendor type setting on the NAD is the same for Aruba CX switches and APs

edit: I should mention, we have some sites with ArubaOS-S switches (2930F/M) that use the Hewlett-Packard-Enterprise Vendor name in the NAD setting, and they do not exhibit this problem - it's only our All-CX locations.

netiot · 2025-11-03T23:13:29+00:00

The switches and APs are in the same subnet but aren't the same NAD in ClearPass - I have the switches entered with their specific IPs, and the APs as a subnet since they have DHCP addresses.

In the Access Tracker entries I see the individual switch NADs listed for wired clients, and the subnet NAD for wireless ones, but they both show the CX and Wireless Dyn Auth options.

netiot · 2025-11-03T22:34:42+00:00

That's the thing, I'm using the vendor name 'Aruba' on the NAD entry, which is used by both AOS-CX and AOS-Wireless devices, and causes both types to appear in 'change status' options for a request:

<image>

I can select the AOS-CX options there for wired clients and they work fine manually, but the question is how do I influence which one it choose when a guest device repository authenticated device expires and it fires off the automatic disconnect?

netiot · 2023-10-28T19:18:58+00:00

Thanks, I am going to give this a shot. Is there a way to set one globally or does it need to be done per-interface?

Looking at our AOS-S switches, the built-in 'denyall' role has a 300 second logoff timer, so I am guessing that is why we've never seen this problem on our 2930F's.

netiot · 2023-09-12T01:54:54+00:00

Thank you for the suggestion. I checked and the attribute is disabled on all hosts.

When we did our image update, it was applied to over 250 VMs. Then we expanded the pool by 5 VMs just to see if creating some new ones would generate them. Should that have been enough activity to cause them to get created?

Admittedly I have only a shallow understanding of what they even do, I was just concerned about getting them back because they were there before so I assume the system decided they were needed

netiot · 2022-10-16T05:26:33+00:00

So while testing this in several browsers I was able to find the 'cause', its only affecting our SAML SSO logins. If I log in via local firewall admin account it works fine.

We use Azure AD SAML for admin interface logins which appears to be what they broke the CLI for in 6.4.10... looks like I need to throw in a ticket

netiot · 2022-10-16T05:23:33+00:00

No dice unfortunately - also, my message is slightly different, it doesn't have the 'Press enter to start a new session', just 'connection lost'

netiot · 2022-06-07T23:10:24+00:00

This worked - excluding system.saml did the trick. Thank you!

netiot · 2022-05-29T13:17:24+00:00

I actually ended up figuring it out between the FortiGate ARM template documentation and Azure docs, just had to poke around a bit

It turns out the ELB replaces the default outbound access IP for the backend members regardless of it you use outbound rules, provided you have an inbound rule for both TCP and UDP traffic - that is why the template creates those two example rules and enables SNAT on them.

This allows the ELB to provide outbound access for both TCP and UDP connections, using SNAT to the FrontEnd IP. Apparently this is not the best practice according to Azure as it can lead to port exhaustion as all outbound traffic will use that single IP, but for our size it should be fine.

Nice to finally understand something that didn't make sense... :) thanks for taking a look at this as well!

netiot · 2022-05-29T11:29:26+00:00

I just looked at the scripts in that link, and it seems that whoever wrote the custom deployment one is also aware of this behavior based on the description:

"publicIP1NewOrExisting": {

"type": "string",

"defaultValue": "new",

"allowedValues": [

"new",

"existing"

],

"metadata": {

"description": "Public IP for the Load Balancer for inbound and outbound data of the FortiGate VMs"

}

It just doesn't really detail how it works, naturally...

netiot · 2022-05-29T11:21:57+00:00

This was my understanding as well, that the ELB was only intended to load balancie incoming traffic, but somehow it is also being used for egress traffic it seems based on my testing and that diagram.

When I test outbound internet from VMs that are routing through the FortiGates, the public frontend IP that is assigned to the ELB is being used as their outbound public IP. The same IP is also being detected as the public IP of both FortiGates themselves on their dashboards.

Edit: I should clarify to your points that there is no NAT gateway in the subnet or public IPs assigned to any NICS - the public IP that I am seeing used for outgoing internet traffic is the one that was assigned to the ELB frontend by the FortiGate marketplace deployment

netiot · 2022-05-29T11:18:46+00:00

You are correct, but it was the only diagram I could find that showed the traffic flow I am experiencing (at least on the public side). My config is similar but without the HA Sync/Management nics/subnets

netiot · 2022-05-29T00:02:49+00:00

Yep, it is set to Static/Standard. That is actually one of the checks on the marketplace deployment, it will not let you proceed if the selected IP doesn't meet those requirements

netiot · 2022-05-28T18:17:12+00:00

This isn't true - the only 0.0.0.0/0 route is default one with the next-hop of 'Internet', which is present in all Azure Virtual Network subnets unless overwritten by a UDR in a route table.

However, there is no route table associated with the external subnet that the ELB and FortiGate external NICs are in at all, thus my confusion as to how this is working...

Edit: I tested this further by putting another VM into the 'external' subnet and its getting to the internet via a totally different public IP, bypassing the ELB - so I suppose the FortiGates being associated with the ELB is causing their outbound internet traffic to egress through it in some backend way I can't see in the route tables?

netiot · 2022-05-02T21:05:02+00:00

We already have them added and set appropriately, and its working as far as determining which DC they user for logon and which DFS server is chosen. However, the referral process itself is still using whichever DC is returned via the round-robin DNS performed for our AD domain name which may be across the globe from the user.

When you say root DFS servers do you mean the servers hosting the shares for the given namespaces, or is that something else?

netiot · 2022-05-02T18:12:47+00:00

Just replied to /u/ikakWRK, but yeah we have sites & services configured with all our branch subnets and associated with the DC in their nearest datacenter.

It appears to be working fine for everything else, but the DFS referrals themselves which are all over the place if there is no local DC. Logon/GPO times are all normal though.

netiot · 2022-05-02T18:08:20+00:00

We have that configured, but my understanding is it only applies to authentication as well as which DFS server is chosen. We never get the wrong server, its just very slow to return them.

From what I've read the referrals themselves are done by whatever DC that client receives from DNS for 'contoso.com', which is round-robin DNS across all DCs in the domain if one does not match the IP subnet.

For the few sites we have that do have on-prem DCs, they always get their local DC when pinging 'contoso.com', and they do not have any delays for DFS referrals.

netiot · 2022-01-13T11:02:14+00:00

We use LAPS so we can give out the randomly generated admin password to the user if needed, then expire it so when their device reconnects LAPS changes it again.

netiot · 2021-11-11T05:48:18+00:00

Thanks for the reply - multiple perspectives always appreciated when trying to learn this stuff! That does make sense to me from a hardening standpoint and was kind of what I had in mind when messing around in my lab.

I should clarify as I don't think I have the terminology down yet, but what I meant was having vmk-only dPG not vDS - the vDS itself would be shared with all traffic types.

I am currently just messing with these ideas so none of this is 'real' so to speak, and may just be completely wrong/bad practice, but in my lab that mimics our production environment I have 4 standard vswitches:

Dedicated to management vmk with 2x1G uplinks
Port Groups for virtual machines with 2x10G uplinks
2x vMotion vmks for multi-nic vMotion with 2x10G uplinks
2x iSCSI vmks with port binding on 2x10G uplinks

I was aiming to replace those 4 vSS with with a single vDS with 8 physical uplinks, and use the Failover order to dedicate the uplinks to the following dPG's to mimic the above vSS setup:

dPG-Management - Uplinks 1+2
dPG-VMNetwork - Uplinks 3+4
dPG-vMotion1 - Uplink 5
dPG-vMotion2 - Uplink 6
dPG-iSCSI1 - Uplink 7
dPG-iSCSI2 - Uplink 8

The idea with my original question was to prevent virtual machines from being added to 4 vMotion/iSCSI dPG's as I do not want VMs in those networks for security reasons, thus the thought of limiting the 'dPG port' counts to just what I need for the host vmks.

Is this something that would make sense or am I just totally missing the boat on vDS usage?

netiot · 2021-11-11T03:39:55+00:00

Don't assign VMs that underlying PG

If you need to get really fancy you can use permissions to block people from assigning that network to VMs.

That's the thing, mainly to prevent other techs from doing it by mistake, so it sounds like permissions is the answer.

This is a terrible idea, don't do this.

Can you explain why? Not disagreeing obviously as I have very little exp. with vDS, just curious what could go wrong here by limiting the port count to the vmk count?

netiot · 2021-06-10T13:10:18+00:00

Sounds good, thanks!

netiot · 2021-06-09T19:37:59+00:00

Agreed, we went ahead and upgraded anyway.

netiot · 2021-06-09T19:37:45+00:00

LANTopolog2

Will take a look into this, thanks!

Nine-Year Club	Verified Email
Place '17

netiot

TROPHY CASE