topic Defining unique radius servers per VRF for different customers in Network Access Control

Defining unique radius servers per VRF for different customers

DLGNOC — Fri, 10 Jun 2022 15:29:09 GMT

Good afternoon, does anyone know if it is possible to define unique radius servers per VRF on a Cisco 9606 (17.3.4)

I respect that you can create a radius group, and attached it to a VRF, but for reachability only from source.

I have a situation where a customer wants to support multiple tenants on a pair of 9606 core switches (Stackwise virtual)

Each tenant is assigned their own unique VRF, but operates their own AAA environment and still wishes to use 802.1x wired authentication.

Example:

Customer A (VRF A) - Customer A Radius Server - 802.1x/MAB

Customer B (VRF B) - Customer B Radius Server - 802.1x/MAB

Customer C (VRF C) - Customer C Radius Server - 802.1x/MAB

I did find a feature called "Per VRF AAA" but it seems to be aimed at ISP's for PPP servcies, not 802.1x user/device auth.

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_usr_aaa/configuration/xe-16/sec-usr-aaa-xe-16-book/sec-per-vrf-aaa.pdf

Any assistance would be appreciated!

Re: Defining unique radius servers per VRF for different customers

MHM Cisco World — Mon, 13 Jun 2022 21:19:44 GMT

try this way
aaa group server radius <any name>

server-private x.x.x.x key xxxx

ip vrf forwarding XXX

ip radius source-interface XXXX

please note that
source-interface is config with same VRF you use for this server
the radius server must reachable via VRF source-interface
use ping x.x.x.x source <source-interface> <<--to check the reachability.

Re: Defining unique radius servers per VRF for different customers

Arne Bier — Mon, 13 Jun 2022 00:20:15 GMT

@DLGNOC

I can confirm that RADIUS can be VRF-aware - but I would also caution that I had to upgrade to 17.6.3 to allow COA to be VRF specific too. Don't forget that! The problem was that the switch was receiving the CoA from ISE (UDP/1700), it's re-auth'd the session, and then tried sending the CoA ACK back to ISE. That's where the problem started in versions prior to 17.4.x (it was trying to send the response by using the global routing table, and not the VRF).

I originally found the problem in 16.9 - then upgraded to 16.12 - then finally upgrade to 17.6.3 and now it works. All the of the RADIUS traffic is now VRF aware and the config is all done in the aaa group (no need for the global ip radius server source-interface command)

Re: Defining unique radius servers per VRF for different customers

DLGNOC — Mon, 13 Jun 2022 10:58:27 GMT

Thank you @Arne Bier would you happen to have a sample configuration please? And is this based on the "Per VRF AAA" feature?

Regards

Re: Defining unique radius servers per VRF for different customers

MHM Cisco World — Mon, 13 Jun 2022 11:06:26 GMT

Yes please Mr @Arne Bier
I interest to see the config of AAA vrf aware.
thanks a lot for your answer.

Re: Defining unique radius servers per VRF for different customers

Arne Bier — Mon, 13 Jun 2022 20:54:32 GMT

Ok - this VRF aware is not too tricky - in my case I have a L3 switch that has VRFs and the RADIUS traffic runs in a VRF called VRF123. All the other user traffic etc runs in different VRFs

Below is how the RADIUS is handled on the C9300 running 17.6.3

aaa new-model
!
aaa group server radius ISE-GROUP
 server name ISE01
 ip vrf forwarding VRF123
 ip radius source-interface Vlan123
!
aaa server radius dynamic-author
 client 172.16.1.10 vrf VRF123 server-key **************
!
radius-server attribute 6 on-for-login-auth
radius-server attribute 8 include-in-access-req
radius-server attribute 25 access-request include
radius-server attribute 31 mac format ietf upper-case
radius-server attribute 31 send nas-port-detail mac-only
radius-server dead-criteria time 10 tries 2
radius-server deadtime 10
radius server ISE01
 address ipv4 172.16.1.10 auth-port 1812 acct-port 1813
 timeout 10
 retransmit 2
 automate-tester username RADIUS-TEST ignore-acct-port probe-on
 key *****************
!
aaa authentication dot1x default group ISE-GROUP
aaa authorization network default group ISE-GROUP 
aaa accounting update newinfo periodic 2880
aaa accounting identity default start-stop group ISE-GROUP

Re: Defining unique radius servers per VRF for different customers

MHM Cisco World — Mon, 13 Jun 2022 21:00:04 GMT

sorry but it don't differ than I post before ? or there is some differ ?

Re: Defining unique radius servers per VRF for different customers

Arne Bier — Mon, 13 Jun 2022 21:16:00 GMT

Ok ok - @MHM Cisco World - can you re-state the question again? What are you guys asking for exactly? If you need more aaa groups (where each aaa group is in a different VRF then this would be a template). Or what exactly is the use-case?

Re: Defining unique radius servers per VRF for different customers

DLGNOC — Thu, 16 Jun 2022 15:37:03 GMT

@Arne Bier Thank you for the example Arne, yes was hoping it was possible to define method lists for each unique VRF?

Do you know if this is possible please?

aaa authentication dot1x default group ISE-GROUP123 - VRF123
aaa authorization network default group ISE-GROUP123 - VRF123

aaa authentication dot1x default group ISE-GROUP124 - VRF124
aaa authorization network default group ISE-GROUP124 - VRF124

Re: Defining unique radius servers per VRF for different customers

Arne Bier — Thu, 16 Jun 2022 20:20:25 GMT

Hello @DLGNOC and @MHM Cisco World

I think what you're referring to is called Differentiated Authentication and it's possible with IBNS 2.0 using a combination of Method Lists and different aaa Groups. The use-case that is mentioned in the ISE Secure Wired Access Prescriptive Guide is if you wanted to send 802.1X to Group A, and MAB to Group B (as an example). I think this can be made to be VRF-aware if you include the vrf commands in the aaa groups as required - and then also create the necessary dynamic author clients too.

Is this what you had in mind?

BTW, @DLGNOC your example in the previous post specifies different aaa groups, but you're always using the 'default' method list. The word 'default' is a reserved method list. If you look at the examples in the link I provided, you can see how Cisco recommends it be done, and how cool IBNS 2.0 is in using those method lists.

The aaa group is just the vehicle to then finally get the RADIUS traffic to the RADIUS servers, after the correct method list has been selected. In older IOS's you could debug the dot1x nicely to see the method list selection algorithm. New IOS-XE SMD debugging is tedious.

Re: Defining unique radius servers per VRF for different customers

DLGNOC — Thu, 23 Jun 2022 15:29:42 GMT

Thank you @Arne Bier Thats exactly what i was looking for! 🙂