ISE Multiple Interfaces for Management/TACACS+/RADIUS/Guest

[jordanburnett]

Hello,

I've been trying to find an answer to this question but can't seem to find an up-to-date article on it.

I have a customer with a distributed deployment that wants to limit management traffic to a single IP/subnet on ISE. This part is easy, as we can utilize GigabitEthernet0 for this purpose (physical or virtual).

However, the trickier part is they do NOT want RADIUS or TACACS+ traffic from Network Devices to traverse this link (TACACS+ and RADIUS). The only traffic they want traversing this link is true management traffic (HTTPS/SSH from a Network Admin).

Here's a visual of what they want (on PSNs):

Gig0: Management Only (HTTPS/SSH)

Gig1: TACACS+/RADIUS to/from NADs

Gig2: Guest Interface (Tied to WebAuth Portal)

I can't seem to find a definitive answer on whether or not this will work. I know that per the deployment guide, RADIUS will listen on any port, and that management is only available on Gig0.I see no reference on which interfaces TACACS+ will listen.

Also, if you'd like to chime in on whether or not this separation is even necessary from an architecture perspective, please do so. I personally think they would be fine with two interfaces (One for Management/TACACS+/RADIUS, one for the Guest Portal). I think it might be slightly unnecessary to separate all the different functions across separate interfaces. I think this would work better:

Gig0: Management/TACACS/RADIUS

Gig1: Guest Interface (Tied to WebAuth Portal)

Thanks in advance,

[Jason Kunst]

You’re correct cannot do that, you could however firewall the different interfaces if they wanted. I also agree its not needed. These are all secured traffic flows.

https://www.cisco.com/c/en/us/td/docs/security/ise/2-3/install_guide/b_ise_InstallationGuide23/b_ise_InstallationGuide23_chapter_0110.html

In the guide it says about RADIUS listening on all interfaces but not TACACs guide defect I will ask for that to be corrected

[jordanburnett]

Thanks Jason, so to clarify, we cannot separate the management functions from the RADIUS/TACACS+ functions with multiple interfaces?

[Jason Kunst]

correct

[Craig Hyps · Accepted solution]

Let me qualify a bit.

Can you separate services to different interfaces?  The short answer is "Yes".

Some guidelines and caveats:

• Gig0 is required for core management including inter-node communications and ERS API.
• RADIUS and T+ can be performed on a separate interface (listen on any interface), but symmetric routing ensures ingress traffic on a given interface exits same interface. 
  • Caveat #1: You cannot turn off (not listen) for these services, but could certainly leverage upstream switch/router/FW rules to enforce.
  • Caveat #2: RADIUS CoA is initiated by PSN to NAD, so cannot rely on routing to use same path as ingress RADIUS requests/accounting. It will need to follow PSN route table.  If willing to allow CoA out a single default gateway--even if Gig0--then this is achievable.  If expect to send out a specific interface other than global default, then configuration may be complex to maintain Gig0 traffic and account for all target NADs.  Details are a bit beyond scope of a Community forum, but I do touch on these topics in Cisco Live session BRKSEC-3699 (reference version of presentation)
• Profiling can be assigned to a specific interface, particularly for inbound probes like DHCP helper, DHCP SPAN, HTTP SPAN, SNMP Traps, Netflow, etc.
• Guest/Sponsor/MyDevices/CA portals can configured and restricted for specific interfaces and symmetric routing will ensure correct pathing for the inbound requests.
• ISE SXP can be configured for a specific interface.

Hope that helps.

Craig

[jordanburnett]

Thanks Craig! That's the info I was looking for, and kind of confirms my suspicions. I figured we would run into some kind of asymmetric routing issues (for lack of a better description) on inbound/outbound services without some specific routes, since they are not always initiated from the NAD.

I'm going to guide them toward utilizing only two interfaces--one for management/RADIUS/T+, and one for the Guest Web Portal.

Thanks again for your help,

Jordan

[Craig Hyps]

To be clear, symmetric traffic is possible by following the information in BRKSEC-3699.  Essentially, if create default routes for each interface where symmetry required.  When traffic enters on GigX, it will automatically exit on GigX.  However, this symmetry does not apply to ISE server initiated traffic and must rely on the route table--either specific route or global default.

Craig

[jsteffensen]

Hi Craig

Since the CoA is originating from the Management interface of the ISE,

- what is the reccomended configuration on IOS Switches?

 I guess this is no big issue just adding the ise mgmt interface to the "aaa server radius dynamic-author"'s

- what is reccomended for WLC?

How can we ensure enabeling ISE-NAC but ensure that Radius requests are only sendt to the "ISE Radius interface" but the CoA allowed from the Mgmt interface?

- what is reccomended for ASA? and other Cisco Products?

DOes all products understand the difference between Radius request and recieving the radius CoA? and is it possible to configure this induvidually on all cisco products?

When adding the complexity of Tustsec? as some CoA are sent from PAN and not the PSN.

To solve the issues addressed, I believe you (cisco) schould consider making it possible to select sourceinterfaces for different traffic related to ISE - I hardly believe the other workarounds will scale.

Best Regards

Jarle Steffensen