Security

Hi,

using 7205 controllers.

I have RADIUS setup and in use fine, for user authentication on the WLANs, and also working for physical oob mgmt interface access.

However, the radius entries when logging into mgmt interface are sourced from the controller ip, so when the production interface is down, we cannot login to the dedicated management interface.
I cannot seem to see how to keep traffic coming via the mgmt vrf to also source as the mgmt vrf, particularly this RADIUS traffic.

I do not want to source all RADIUS traffic through the mgmt interface for the main network user authentication, only traffic accessing the mgmt interface.

Regards,

Craig

Why not add the management interface as a NAD in ClearPass?

Hi,

using 7205 controllers.

I have RADIUS setup and in use fine, for user authentication on the WLANs, and also working for physical oob mgmt interface access.

However, the radius entries when logging into mgmt interface are sourced from the controller ip, so when the production interface is down, we cannot login to the dedicated management interface.
I cannot seem to see how to keep traffic coming via the mgmt vrf to also source as the mgmt vrf, particularly this RADIUS traffic.

I do not want to source all RADIUS traffic through the mgmt interface for the main network user authentication, only traffic accessing the mgmt interface.

Regards,

Craig

The controller IP and the oob management IP are both added, but traffic is never sourced as the mgmt IP. That is the problem.

The radius traffic is only sourced as the controller IP which is a problem if we lose the production switch/connection, as radius auth requests are then never sent from the oob interface when trying to login.

It looks like i might be able to swap the source to the oob mgmt ip, but that means all production authentication traffic would then have to also use the oob network, rather than just oob admin access authentication.

Why not add the management interface as a NAD in ClearPass?

Hi,

using 7205 controllers.

I have RADIUS setup and in use fine, for user authentication on the WLANs, and also working for physical oob mgmt interface access.

However, the radius entries when logging into mgmt interface are sourced from the controller ip, so when the production interface is down, we cannot login to the dedicated management interface.
I cannot seem to see how to keep traffic coming via the mgmt vrf to also source as the mgmt vrf, particularly this RADIUS traffic.

I do not want to source all RADIUS traffic through the mgmt interface for the main network user authentication, only traffic accessing the mgmt interface.

Regards,

Craig

The controller IP and the oob management IP are both added, but traffic is never sourced as the mgmt IP. That is the problem.

The radius traffic is only sourced as the controller IP which is a problem if we lose the production switch/connection, as radius auth requests are then never sent from the oob interface when trying to login.

It looks like i might be able to swap the source to the oob mgmt ip, but that means all production authentication traffic would then have to also use the oob network, rather than just oob admin access authentication.

Why not add the management interface as a NAD in ClearPass?

Hi,

using 7205 controllers.

I have RADIUS setup and in use fine, for user authentication on the WLANs, and also working for physical oob mgmt interface access.

However, the radius entries when logging into mgmt interface are sourced from the controller ip, so when the production interface is down, we cannot login to the dedicated management interface.
I cannot seem to see how to keep traffic coming via the mgmt vrf to also source as the mgmt vrf, particularly this RADIUS traffic.

I do not want to source all RADIUS traffic through the mgmt interface for the main network user authentication, only traffic accessing the mgmt interface.

Regards,

Craig

Is the CPPM IP currently routed only through the production interface? If so, the route will be deleted as soon as the interface goes down. You can set up a second route with a higher cost metric via the gateway in the OOBM network; then you don't need to use the new VIP.

In both cases (with or without a new VIP), you must enter the OOBM IP in ClearPass as the NAD IP, as @ahollifield mentioned.

------------------------------
Regards,

Waldemar
ACCX # 1377, ACEP, ACX - Network Security
If you find my answer useful, consider giving kudos and/or mark as solution

Original Message:
Sent: Apr 21, 2026 04:31 AM
From: cpszx
Subject: different radius source for mgmt and production

The controller IP and the oob management IP are both added, but traffic is never sourced as the mgmt IP. That is the problem.

The radius traffic is only sourced as the controller IP which is a problem if we lose the production switch/connection, as radius auth requests are then never sent from the oob interface when trying to login.

It looks like i might be able to swap the source to the oob mgmt ip, but that means all production authentication traffic would then have to also use the oob network, rather than just oob admin access authentication.

Original Message:
Sent: Apr 20, 2026 04:05 PM
From: ahollifield
Subject: different radius source for mgmt and production

Why not add the management interface as a NAD in ClearPass?

Original Message:
Sent: Apr 20, 2026 06:35 AM
From: cpszx
Subject: different radius source for mgmt and production

Hi,

using 7205 controllers.

I have RADIUS setup and in use fine, for user authentication on the WLANs, and also working for physical oob mgmt interface access.

However, the radius entries when logging into mgmt interface are sourced from the controller ip, so when the production interface is down, we cannot login to the dedicated management interface.
I cannot seem to see how to keep traffic coming via the mgmt vrf to also source as the mgmt vrf, particularly this RADIUS traffic.

I do not want to source all RADIUS traffic through the mgmt interface for the main network user authentication, only traffic accessing the mgmt interface.

Regards,

Craig

-------------------------------------------

I thought the mgmt was a separate vrf already, but i see that was wrong assumption, as i have been configuring a number of other devices for same service recently, the capabilities had become mixed up for me.

I had just been thinking about specific route to different server ip, but this approach with the higher cost route is nicer.

However, if i try to add any route via the default gateway mentioned on the mgmt interface i get this error:

Error: Static route cannot be added on management interface on /mm/mynode

I see it more of the routing problem you mention now, as this controller also has RAP service, it has the default route via an external interface vlan, with  specific routes for internal subnets. My assumption was the default gateway defined for the mgmt interface would apply to traffic leaving the mgmt ip, but the traffic is just leaving via the standard routing.

Just seeing if there is a way to use a mgmt vlan in that way to stay up and tie a route to, but that previous error prevents other routes when the ip is attached to the mgmt interface. 

Original Message:
Sent: Apr 21, 2026 05:45 AM
From: Lord
Subject: different radius source for mgmt and production

Is the CPPM IP currently routed only through the production interface? If so, the route will be deleted as soon as the interface goes down. You can set up a second route with a higher cost metric via the gateway in the OOBM network; then you don't need to use the new VIP.

In both cases (with or without a new VIP), you must enter the OOBM IP in ClearPass as the NAD IP, as @ahollifield mentioned.

------------------------------
Regards,

Waldemar
ACCX # 1377, ACEP, ACX - Network Security
If you find my answer useful, consider giving kudos and/or mark as solution

Original Message:
Sent: Apr 21, 2026 04:31 AM
From: cpszx
Subject: different radius source for mgmt and production

The controller IP and the oob management IP are both added, but traffic is never sourced as the mgmt IP. That is the problem.

The radius traffic is only sourced as the controller IP which is a problem if we lose the production switch/connection, as radius auth requests are then never sent from the oob interface when trying to login.

It looks like i might be able to swap the source to the oob mgmt ip, but that means all production authentication traffic would then have to also use the oob network, rather than just oob admin access authentication.

Original Message:
Sent: Apr 20, 2026 04:05 PM
From: ahollifield
Subject: different radius source for mgmt and production

Why not add the management interface as a NAD in ClearPass?

Original Message:
Sent: Apr 20, 2026 06:35 AM
From: cpszx
Subject: different radius source for mgmt and production

Hi,

using 7205 controllers.

I have RADIUS setup and in use fine, for user authentication on the WLANs, and also working for physical oob mgmt interface access.

However, the radius entries when logging into mgmt interface are sourced from the controller ip, so when the production interface is down, we cannot login to the dedicated management interface.
I cannot seem to see how to keep traffic coming via the mgmt vrf to also source as the mgmt vrf, particularly this RADIUS traffic.

I do not want to source all RADIUS traffic through the mgmt interface for the main network user authentication, only traffic accessing the mgmt interface.

Regards,

Craig

-------------------------------------------

Sorry for the confusion; I got things mixed up. That's the difference between theory and practice-the approach only works for regular VLANs; the OOBM interface actually has a separate routing table.

For the MGMT interface, a default gateway can be set:

[mynode] (config) #ip default-gateway mgmt
<nexthop>               A.B.C.D IP address of default gateway

I thought the mgmt was a separate vrf already, but i see that was wrong assumption, as i have been configuring a number of other devices for same service recently, the capabilities had become mixed up for me.

I had just been thinking about specific route to different server ip, but this approach with the higher cost route is nicer.

However, if i try to add any route via the default gateway mentioned on the mgmt interface i get this error:

Error: Static route cannot be added on management interface on /mm/mynode

I see it more of the routing problem you mention now, as this controller also has RAP service, it has the default route via an external interface vlan, with  specific routes for internal subnets. My assumption was the default gateway defined for the mgmt interface would apply to traffic leaving the mgmt ip, but the traffic is just leaving via the standard routing.

Just seeing if there is a way to use a mgmt vlan in that way to stay up and tie a route to, but that previous error prevents other routes when the ip is attached to the mgmt interface. 

Original Message:
Sent: Apr 21, 2026 05:45 AM
From: Lord
Subject: different radius source for mgmt and production

Is the CPPM IP currently routed only through the production interface? If so, the route will be deleted as soon as the interface goes down. You can set up a second route with a higher cost metric via the gateway in the OOBM network; then you don't need to use the new VIP.

In both cases (with or without a new VIP), you must enter the OOBM IP in ClearPass as the NAD IP, as @ahollifield mentioned.

------------------------------
Regards,

Waldemar
ACCX # 1377, ACEP, ACX - Network Security
If you find my answer useful, consider giving kudos and/or mark as solution

Original Message:
Sent: Apr 21, 2026 04:31 AM
From: cpszx
Subject: different radius source for mgmt and production

The controller IP and the oob management IP are both added, but traffic is never sourced as the mgmt IP. That is the problem.

The radius traffic is only sourced as the controller IP which is a problem if we lose the production switch/connection, as radius auth requests are then never sent from the oob interface when trying to login.

It looks like i might be able to swap the source to the oob mgmt ip, but that means all production authentication traffic would then have to also use the oob network, rather than just oob admin access authentication.

Original Message:
Sent: Apr 20, 2026 04:05 PM
From: ahollifield
Subject: different radius source for mgmt and production

Why not add the management interface as a NAD in ClearPass?

Original Message:
Sent: Apr 20, 2026 06:35 AM
From: cpszx
Subject: different radius source for mgmt and production

Hi,

using 7205 controllers.

I have RADIUS setup and in use fine, for user authentication on the WLANs, and also working for physical oob mgmt interface access.

However, the radius entries when logging into mgmt interface are sourced from the controller ip, so when the production interface is down, we cannot login to the dedicated management interface.
I cannot seem to see how to keep traffic coming via the mgmt vrf to also source as the mgmt vrf, particularly this RADIUS traffic.

I do not want to source all RADIUS traffic through the mgmt interface for the main network user authentication, only traffic accessing the mgmt interface.

Regards,

Craig

-------------------------------------------

Yes, thats what i had, and all that you can set for the oobm interface.

With a valid default route on a working external interface, i have lost the internal routes to the rest of the network with the loss of the internal interface and vlans.

So i can only conclude at the moment that the oobm doesn't actually work as i would expect it to, as i also cannot set it as a source interface for specific traffic.
I only have console access to rely on in that case, or open up for management externally which is not going to happen, or dedicated a standard interface as a management interface and ignore the oobm altogether.

ok thanks for the help, looks like i am out of other options.

Sorry for the confusion; I got things mixed up. That's the difference between theory and practice-the approach only works for regular VLANs; the OOBM interface actually has a separate routing table.

For the MGMT interface, a default gateway can be set:

[mynode] (config) #ip default-gateway mgmt
<nexthop>               A.B.C.D IP address of default gateway

I thought the mgmt was a separate vrf already, but i see that was wrong assumption, as i have been configuring a number of other devices for same service recently, the capabilities had become mixed up for me.

I had just been thinking about specific route to different server ip, but this approach with the higher cost route is nicer.

However, if i try to add any route via the default gateway mentioned on the mgmt interface i get this error:

Error: Static route cannot be added on management interface on /mm/mynode

I see it more of the routing problem you mention now, as this controller also has RAP service, it has the default route via an external interface vlan, with  specific routes for internal subnets. My assumption was the default gateway defined for the mgmt interface would apply to traffic leaving the mgmt ip, but the traffic is just leaving via the standard routing.

Just seeing if there is a way to use a mgmt vlan in that way to stay up and tie a route to, but that previous error prevents other routes when the ip is attached to the mgmt interface. 

Original Message:
Sent: Apr 21, 2026 05:45 AM
From: Lord
Subject: different radius source for mgmt and production

Is the CPPM IP currently routed only through the production interface? If so, the route will be deleted as soon as the interface goes down. You can set up a second route with a higher cost metric via the gateway in the OOBM network; then you don't need to use the new VIP.

In both cases (with or without a new VIP), you must enter the OOBM IP in ClearPass as the NAD IP, as @ahollifield mentioned.

------------------------------
Regards,

Waldemar
ACCX # 1377, ACEP, ACX - Network Security
If you find my answer useful, consider giving kudos and/or mark as solution

Original Message:
Sent: Apr 21, 2026 04:31 AM
From: cpszx
Subject: different radius source for mgmt and production

The controller IP and the oob management IP are both added, but traffic is never sourced as the mgmt IP. That is the problem.

The radius traffic is only sourced as the controller IP which is a problem if we lose the production switch/connection, as radius auth requests are then never sent from the oob interface when trying to login.

It looks like i might be able to swap the source to the oob mgmt ip, but that means all production authentication traffic would then have to also use the oob network, rather than just oob admin access authentication.

Original Message:
Sent: Apr 20, 2026 04:05 PM
From: ahollifield
Subject: different radius source for mgmt and production

Why not add the management interface as a NAD in ClearPass?

Original Message:
Sent: Apr 20, 2026 06:35 AM
From: cpszx
Subject: different radius source for mgmt and production

Hi,

using 7205 controllers.

I have RADIUS setup and in use fine, for user authentication on the WLANs, and also working for physical oob mgmt interface access.

However, the radius entries when logging into mgmt interface are sourced from the controller ip, so when the production interface is down, we cannot login to the dedicated management interface.
I cannot seem to see how to keep traffic coming via the mgmt vrf to also source as the mgmt vrf, particularly this RADIUS traffic.

I do not want to source all RADIUS traffic through the mgmt interface for the main network user authentication, only traffic accessing the mgmt interface.

Regards,

Craig

-------------------------------------------

Would it be an option for you to fallback to the local controller or conductor user database if the production interface goes down and the ClearPass server becomes unreachable? That way, you would still be able to log in via the MGMT interface even if the ClearPass server is unavailable.

Yes, thats what i had, and all that you can set for the oobm interface.

With a valid default route on a working external interface, i have lost the internal routes to the rest of the network with the loss of the internal interface and vlans.

So i can only conclude at the moment that the oobm doesn't actually work as i would expect it to, as i also cannot set it as a source interface for specific traffic.
I only have console access to rely on in that case, or open up for management externally which is not going to happen, or dedicated a standard interface as a management interface and ignore the oobm altogether.

ok thanks for the help, looks like i am out of other options.

Sorry for the confusion; I got things mixed up. That's the difference between theory and practice-the approach only works for regular VLANs; the OOBM interface actually has a separate routing table.

For the MGMT interface, a default gateway can be set:

[mynode] (config) #ip default-gateway mgmt
<nexthop>               A.B.C.D IP address of default gateway

I thought the mgmt was a separate vrf already, but i see that was wrong assumption, as i have been configuring a number of other devices for same service recently, the capabilities had become mixed up for me.

I had just been thinking about specific route to different server ip, but this approach with the higher cost route is nicer.

However, if i try to add any route via the default gateway mentioned on the mgmt interface i get this error:

Error: Static route cannot be added on management interface on /mm/mynode

I see it more of the routing problem you mention now, as this controller also has RAP service, it has the default route via an external interface vlan, with  specific routes for internal subnets. My assumption was the default gateway defined for the mgmt interface would apply to traffic leaving the mgmt ip, but the traffic is just leaving via the standard routing.

Just seeing if there is a way to use a mgmt vlan in that way to stay up and tie a route to, but that previous error prevents other routes when the ip is attached to the mgmt interface. 

Original Message:
Sent: Apr 21, 2026 05:45 AM
From: Lord
Subject: different radius source for mgmt and production

Is the CPPM IP currently routed only through the production interface? If so, the route will be deleted as soon as the interface goes down. You can set up a second route with a higher cost metric via the gateway in the OOBM network; then you don't need to use the new VIP.

In both cases (with or without a new VIP), you must enter the OOBM IP in ClearPass as the NAD IP, as @ahollifield mentioned.

------------------------------
Regards,

Waldemar
ACCX # 1377, ACEP, ACX - Network Security
If you find my answer useful, consider giving kudos and/or mark as solution

Original Message:
Sent: Apr 21, 2026 04:31 AM
From: cpszx
Subject: different radius source for mgmt and production

The controller IP and the oob management IP are both added, but traffic is never sourced as the mgmt IP. That is the problem.

The radius traffic is only sourced as the controller IP which is a problem if we lose the production switch/connection, as radius auth requests are then never sent from the oob interface when trying to login.

It looks like i might be able to swap the source to the oob mgmt ip, but that means all production authentication traffic would then have to also use the oob network, rather than just oob admin access authentication.

Original Message:
Sent: Apr 20, 2026 04:05 PM
From: ahollifield
Subject: different radius source for mgmt and production

Why not add the management interface as a NAD in ClearPass?

Original Message:
Sent: Apr 20, 2026 06:35 AM
From: cpszx
Subject: different radius source for mgmt and production

Hi,

using 7205 controllers.

I have RADIUS setup and in use fine, for user authentication on the WLANs, and also working for physical oob mgmt interface access.

However, the radius entries when logging into mgmt interface are sourced from the controller ip, so when the production interface is down, we cannot login to the dedicated management interface.
I cannot seem to see how to keep traffic coming via the mgmt vrf to also source as the mgmt vrf, particularly this RADIUS traffic.

I do not want to source all RADIUS traffic through the mgmt interface for the main network user authentication, only traffic accessing the mgmt interface.

Regards,

Craig

-------------------------------------------

That is how we have the configuration working at the moment, local admin fallback.

All access had stopped working while i was trying different configurations yesterday, and had to reboot. The fact i can get to the admin interface over mgmt obviously means the oobm vrf is almost working, for incoming connections, just not for controller initiated outbounds.

Overnight, i thought of a different approach which should work: configure a RADIUS server in WLC that is in the same subnet as oobm, but NAT that address through the firewall/router that is the gateway for that subnet to the live RADIUS server.

Alternatively, if the internal production interface is down, then i could shut the external interface switch port down as well, because everything will have already transferred over to another WLC, and then the oobm default gateway is the only route left.

Thank you very much for the replies, because the dialogue and interaction helps massively to work through different ideas and approaches.

Regards,

Craig

Would it be an option for you to fallback to the local controller or conductor user database if the production interface goes down and the ClearPass server becomes unreachable? That way, you would still be able to log in via the MGMT interface even if the ClearPass server is unavailable.

Yes, thats what i had, and all that you can set for the oobm interface.

With a valid default route on a working external interface, i have lost the internal routes to the rest of the network with the loss of the internal interface and vlans.

So i can only conclude at the moment that the oobm doesn't actually work as i would expect it to, as i also cannot set it as a source interface for specific traffic.
I only have console access to rely on in that case, or open up for management externally which is not going to happen, or dedicated a standard interface as a management interface and ignore the oobm altogether.

ok thanks for the help, looks like i am out of other options.

Sorry for the confusion; I got things mixed up. That's the difference between theory and practice-the approach only works for regular VLANs; the OOBM interface actually has a separate routing table.

For the MGMT interface, a default gateway can be set:

[mynode] (config) #ip default-gateway mgmt
<nexthop>               A.B.C.D IP address of default gateway

I thought the mgmt was a separate vrf already, but i see that was wrong assumption, as i have been configuring a number of other devices for same service recently, the capabilities had become mixed up for me.

I had just been thinking about specific route to different server ip, but this approach with the higher cost route is nicer.

However, if i try to add any route via the default gateway mentioned on the mgmt interface i get this error:

Error: Static route cannot be added on management interface on /mm/mynode

I see it more of the routing problem you mention now, as this controller also has RAP service, it has the default route via an external interface vlan, with  specific routes for internal subnets. My assumption was the default gateway defined for the mgmt interface would apply to traffic leaving the mgmt ip, but the traffic is just leaving via the standard routing.

Just seeing if there is a way to use a mgmt vlan in that way to stay up and tie a route to, but that previous error prevents other routes when the ip is attached to the mgmt interface. 

Original Message:
Sent: Apr 21, 2026 05:45 AM
From: Lord
Subject: different radius source for mgmt and production

Is the CPPM IP currently routed only through the production interface? If so, the route will be deleted as soon as the interface goes down. You can set up a second route with a higher cost metric via the gateway in the OOBM network; then you don't need to use the new VIP.

In both cases (with or without a new VIP), you must enter the OOBM IP in ClearPass as the NAD IP, as @ahollifield mentioned.

------------------------------
Regards,

Waldemar
ACCX # 1377, ACEP, ACX - Network Security
If you find my answer useful, consider giving kudos and/or mark as solution

Original Message:
Sent: Apr 21, 2026 04:31 AM
From: cpszx
Subject: different radius source for mgmt and production

The controller IP and the oob management IP are both added, but traffic is never sourced as the mgmt IP. That is the problem.

The radius traffic is only sourced as the controller IP which is a problem if we lose the production switch/connection, as radius auth requests are then never sent from the oob interface when trying to login.

It looks like i might be able to swap the source to the oob mgmt ip, but that means all production authentication traffic would then have to also use the oob network, rather than just oob admin access authentication.

Original Message:
Sent: Apr 20, 2026 04:05 PM
From: ahollifield
Subject: different radius source for mgmt and production

Why not add the management interface as a NAD in ClearPass?

Original Message:
Sent: Apr 20, 2026 06:35 AM
From: cpszx
Subject: different radius source for mgmt and production

Hi,

using 7205 controllers.

I have RADIUS setup and in use fine, for user authentication on the WLANs, and also working for physical oob mgmt interface access.

However, the radius entries when logging into mgmt interface are sourced from the controller ip, so when the production interface is down, we cannot login to the dedicated management interface.
I cannot seem to see how to keep traffic coming via the mgmt vrf to also source as the mgmt vrf, particularly this RADIUS traffic.

I do not want to source all RADIUS traffic through the mgmt interface for the main network user authentication, only traffic accessing the mgmt interface.

Regards,

Craig

-------------------------------------------

Hi Craig,
I'm glad to hear you're getting closer to a solution.
Are you really using a separate network for OOBM? Or is it just a VLAN within the production network?
Most of our customers use a VLAN and secure it with firewalls. They configure controller ports as LAGs or port channels in AOS syntax and route authentication traffic to ClearPass.

The controllers respond to all connections on the MGMT port that come in via the MGMT port. However, the authentication traffic is initiated by the controller and goes to the routing table for standard traffic. This is what's causing the problem you're experiencing.

I'm afraid the NAT approach won't work either; the controller will route the NATed IP via the normal routing table-I tested this in my lab:

I configured an IP address and a gateway in the MGMT interface:

[mynode] (config) #show ip interface brief

Interface                   IP Address / IP Netmask        Admin   Protocol   VRRP-IP
vlan 81                  192.168.81.11 / 255.255.255.0     up      up         192.168.81.10
loopback                    unassigned / unassigned        up      up
mgmt                   192.168.102.181 / 255.255.255.0     up      up 

[mynode] (config) #show ip route

Codes: C - connected, O - OSPF, R - RIP, S - static, B - Bgw peer uplink
       M - mgmt, U - route usable, * - candidate default, V - RAPNG VPN/Branch
       I - Ike-overlay, N - not redistributed

Gateway of last resort is 192.168.81.1 to network 0.0.0.0 at cost 1
S*    0.0.0.0/0  [0/1] via 192.168.81.1*

M    192.168.102.0/24 is directly connected to mgmt interface

Management Gateway of last resort is 192.168.102.1 to network 0.0.0.0
M   0.0.0.0/0  via 192.168.102.1

When I send a traceroute to the gateway in the MGMT network, it is routed via the MGMT interface.

[mynode] (config) #traceroute 192.168.102.1
Tracing the route to 192.168.102.1 ....

traceroute to 192.168.102.1 (192.168.102.1), 30 hops max, 46 byte packets
 1  192.168.102.1 (192.168.102.1)  0.671 ms  0.664 ms  0.490 ms

When I send a traceroute to another IP address in the MGMT network, it is routed via the normal gateway.

[mynode] (config) #traceroute 192.168.102.100
Tracing the route to 192.168.102.100 ....

traceroute to 192.168.102.100 (192.168.102.100), 30 hops max, 46 byte packets
 1  192.168.81.1 (192.168.81.1)  0.860 ms  0.893 ms  0.699 ms
 2  192.168.81.1 (192.168.81.1)  3112.917 ms !H  3046.261 ms !H  3016.799 ms !H

Only when I specify the MGMT interface IP as the source IP does it go out via the MGMT interface.

[mynode] (config) #traceroute 192.168.2.100 source 192.168.102.181
Tracing the route to 192.168.2.100  from 192.168.102.181....

traceroute to 192.168.2.100 (192.168.2.100) from 192.168.102.181, 30 hops max, 46 byte packets
 1  192.168.102.1 (192.168.102.1)  0.337 ms  0.332 ms  0.260 ms
 2  192.168.102.1 (192.168.102.1)  3097.490 ms !H  3014.138 ms !H  3033.254 ms !H

The problem is that, in the syntax for TACACS or RADIUS servers, the controller only allows a VLAN, the MGMT interface or a simple IP address cannot be specified.

[mynode] (TACACS Server "my-cppm-01.tac") #source-interface
vlan                    Select VLAN of outgoing TACACS requests to this server

By specifying the Source IP as the MGMT interface or MGMT IP address, we could control whether authentication traffic should be routed via the MGMT interface or a VLAN. But the controller does not allow this.

That is how we have the configuration working at the moment, local admin fallback.

All access had stopped working while i was trying different configurations yesterday, and had to reboot. The fact i can get to the admin interface over mgmt obviously means the oobm vrf is almost working, for incoming connections, just not for controller initiated outbounds.

Overnight, i thought of a different approach which should work: configure a RADIUS server in WLC that is in the same subnet as oobm, but NAT that address through the firewall/router that is the gateway for that subnet to the live RADIUS server.

Alternatively, if the internal production interface is down, then i could shut the external interface switch port down as well, because everything will have already transferred over to another WLC, and then the oobm default gateway is the only route left.

Thank you very much for the replies, because the dialogue and interaction helps massively to work through different ideas and approaches.

Regards,

Craig

Would it be an option for you to fallback to the local controller or conductor user database if the production interface goes down and the ClearPass server becomes unreachable? That way, you would still be able to log in via the MGMT interface even if the ClearPass server is unavailable.

Yes, thats what i had, and all that you can set for the oobm interface.

With a valid default route on a working external interface, i have lost the internal routes to the rest of the network with the loss of the internal interface and vlans.

So i can only conclude at the moment that the oobm doesn't actually work as i would expect it to, as i also cannot set it as a source interface for specific traffic.
I only have console access to rely on in that case, or open up for management externally which is not going to happen, or dedicated a standard interface as a management interface and ignore the oobm altogether.

ok thanks for the help, looks like i am out of other options.

Sorry for the confusion; I got things mixed up. That's the difference between theory and practice-the approach only works for regular VLANs; the OOBM interface actually has a separate routing table.

For the MGMT interface, a default gateway can be set:

[mynode] (config) #ip default-gateway mgmt
<nexthop>               A.B.C.D IP address of default gateway

I thought the mgmt was a separate vrf already, but i see that was wrong assumption, as i have been configuring a number of other devices for same service recently, the capabilities had become mixed up for me.

I had just been thinking about specific route to different server ip, but this approach with the higher cost route is nicer.

However, if i try to add any route via the default gateway mentioned on the mgmt interface i get this error:

Error: Static route cannot be added on management interface on /mm/mynode

I see it more of the routing problem you mention now, as this controller also has RAP service, it has the default route via an external interface vlan, with  specific routes for internal subnets. My assumption was the default gateway defined for the mgmt interface would apply to traffic leaving the mgmt ip, but the traffic is just leaving via the standard routing.

Just seeing if there is a way to use a mgmt vlan in that way to stay up and tie a route to, but that previous error prevents other routes when the ip is attached to the mgmt interface. 

Original Message:
Sent: Apr 21, 2026 05:45 AM
From: Lord
Subject: different radius source for mgmt and production

Is the CPPM IP currently routed only through the production interface? If so, the route will be deleted as soon as the interface goes down. You can set up a second route with a higher cost metric via the gateway in the OOBM network; then you don't need to use the new VIP.

In both cases (with or without a new VIP), you must enter the OOBM IP in ClearPass as the NAD IP, as @ahollifield mentioned.

------------------------------
Regards,

Waldemar
ACCX # 1377, ACEP, ACX - Network Security
If you find my answer useful, consider giving kudos and/or mark as solution

Original Message:
Sent: Apr 21, 2026 04:31 AM
From: cpszx
Subject: different radius source for mgmt and production

The controller IP and the oob management IP are both added, but traffic is never sourced as the mgmt IP. That is the problem.

The radius traffic is only sourced as the controller IP which is a problem if we lose the production switch/connection, as radius auth requests are then never sent from the oob interface when trying to login.

It looks like i might be able to swap the source to the oob mgmt ip, but that means all production authentication traffic would then have to also use the oob network, rather than just oob admin access authentication.

Original Message:
Sent: Apr 20, 2026 04:05 PM
From: ahollifield
Subject: different radius source for mgmt and production

Why not add the management interface as a NAD in ClearPass?

Original Message:
Sent: Apr 20, 2026 06:35 AM
From: cpszx
Subject: different radius source for mgmt and production

Hi,

using 7205 controllers.

I have RADIUS setup and in use fine, for user authentication on the WLANs, and also working for physical oob mgmt interface access.

However, the radius entries when logging into mgmt interface are sourced from the controller ip, so when the production interface is down, we cannot login to the dedicated management interface.
I cannot seem to see how to keep traffic coming via the mgmt vrf to also source as the mgmt vrf, particularly this RADIUS traffic.

I do not want to source all RADIUS traffic through the mgmt interface for the main network user authentication, only traffic accessing the mgmt interface.

Regards,

Craig

-------------------------------------------