topic Re: ISE Multiple Interfaces for Management/TACACS+/RADIUS/Guest in Network Access Control

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

jordanburnett — Tue, 23 Jan 2018 20:46:14 GMT

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,

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

Jason Kunst — Tue, 23 Jan 2018 21:00:13 GMT

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

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

jordanburnett — Tue, 23 Jan 2018 21:03:24 GMT

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

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

Jason Kunst — Tue, 23 Jan 2018 21:07:26 GMT

correct

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

Craig Hyps — Tue, 23 Jan 2018 22:56:33 GMT

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

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

jordanburnett — Tue, 23 Jan 2018 23:56:09 GMT

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

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

Craig Hyps — Wed, 24 Jan 2018 01:08:42 GMT

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

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

jsteffensen — Fri, 07 Dec 2018 14:04:40 GMT

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