cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2190
Views
30
Helpful
9
Replies

Configure ISE interface 2 for Radius

manvik
Level 3
Level 3

Should I do any separate configuration for Tacacs+/Radius to work in a interface 2 of ISE. ISE Gb0 is used for management only.

I think by default Radius request is listened on all interfaces.

Should any configuration done to separate management and Tacacs+ traffic in separate interfaces.

2 Accepted Solutions

Accepted Solutions

Arne Bier
VIP
VIP

I would think long and hard before adding another link into any ISE node. I guess it makes sense to restrict this to PSNs only since the PAN/MNT has no use for it at all.

I am not a friend of multiple interfaces on PSNs. For the following reasons:

  • Not required to add more bandwidth - PSNs don't handle a lot of traffic
  • Not required to "secure" TACACS+ from RADIUS traffic - all roads lead to Rome ... so what are we achieving, other than complexity?
  • Putting web server interface in a DMZ VLAN. That could be a use case, but the PSN is still attached to that VLAN - any attack on the DMZ VLAN could potentially harm the PSN. If in doubt, spin up a separate ISE VM in the DMZ, and then dedicate that PSN just for Guest Portals. Besides, having a PSN with gig0 for RADIUS, and gig1 for Portals is cool in theory, but quite puzzling to anyone who looks at the WLC/Switch config. RADIUS requests go to IP for gig0 but the URL redirects have to go to IP of gig1 - this means careful DNS config and also the pre-auth ACLs will look strange to anyone who doesn't know this is going on. If you only have Web access to an ISE node you cannot determine the IP address of any secondary ISE interfaces. Seems like an oversight to me. You need CLI access to a PSN to confirm the interface IP addresses.

Security by obscurity?

RADIUS, TACACS+, SSH, NTP, SNMP, SYSLOG etc are all management traffic - therefore, IMHO they belong on gig0. Even the good old Sponsor Portal should ride on gig0 - it's internal traffic.

As for the Guest Portal, this is where opinions are divided. I see most customers putting this on gig0 and then secure their intranet by making the pre-auth and post-auth ACLs VERY VERY tight. Down to the exact destinations for DNS servers, ISE TCP https ports. In fact, you could reduce the threat landscape by putting the guest portal FQDNs into the public DNS (most hosting providers will allow RFC1918 addresses in DNS records) and use a public DNS provider for your guest traffic (instead of pointing guests to your own infrastructure). As for attack vector, that leaves the TCP/8443 on the PSN (typical guest portal) - perhaps that is vulnerable to SYN attacks and cross site scripting? To my knowledge this has not been discussed on these forums. I guess in theory it's possible. It would be nice to know what protection ISE provides in those situations (pen testing results)

View solution in original post

9 Replies 9

manvik
Level 3
Level 3

is there any specific configuration for this or just create two interfaces and assign IP addresses. In my case there are only 2 interfaces - one for MGMT and other for Radius/Tacacs

@manvik aside from assigning an IP address to the interface, you will need to define a static route on the PSNs - "ip route 0.0.0.0 0.0.0.0 x.x.x.x"

Arne Bier
VIP
VIP

I would think long and hard before adding another link into any ISE node. I guess it makes sense to restrict this to PSNs only since the PAN/MNT has no use for it at all.

I am not a friend of multiple interfaces on PSNs. For the following reasons:

  • Not required to add more bandwidth - PSNs don't handle a lot of traffic
  • Not required to "secure" TACACS+ from RADIUS traffic - all roads lead to Rome ... so what are we achieving, other than complexity?
  • Putting web server interface in a DMZ VLAN. That could be a use case, but the PSN is still attached to that VLAN - any attack on the DMZ VLAN could potentially harm the PSN. If in doubt, spin up a separate ISE VM in the DMZ, and then dedicate that PSN just for Guest Portals. Besides, having a PSN with gig0 for RADIUS, and gig1 for Portals is cool in theory, but quite puzzling to anyone who looks at the WLC/Switch config. RADIUS requests go to IP for gig0 but the URL redirects have to go to IP of gig1 - this means careful DNS config and also the pre-auth ACLs will look strange to anyone who doesn't know this is going on. If you only have Web access to an ISE node you cannot determine the IP address of any secondary ISE interfaces. Seems like an oversight to me. You need CLI access to a PSN to confirm the interface IP addresses.

Security by obscurity?

RADIUS, TACACS+, SSH, NTP, SNMP, SYSLOG etc are all management traffic - therefore, IMHO they belong on gig0. Even the good old Sponsor Portal should ride on gig0 - it's internal traffic.

As for the Guest Portal, this is where opinions are divided. I see most customers putting this on gig0 and then secure their intranet by making the pre-auth and post-auth ACLs VERY VERY tight. Down to the exact destinations for DNS servers, ISE TCP https ports. In fact, you could reduce the threat landscape by putting the guest portal FQDNs into the public DNS (most hosting providers will allow RFC1918 addresses in DNS records) and use a public DNS provider for your guest traffic (instead of pointing guests to your own infrastructure). As for attack vector, that leaves the TCP/8443 on the PSN (typical guest portal) - perhaps that is vulnerable to SYN attacks and cross site scripting? To my knowledge this has not been discussed on these forums. I guess in theory it's possible. It would be nice to know what protection ISE provides in those situations (pen testing results)

Thank you @Arne Bier that was a detailed explanation. we just need separate interface for devices in two separate networks.

All the interfaces serve RADIUS/TACACS authentication.

Devices in Network 1 communicates with INT1

Devices in Network 2 communicates with INT2

 

where in ISE GUi can I give an IP address for interface 2, 3, 4. Can it be done only from CLI

This is done in CLI

 

thank you, any commands for that???