02-10-2019 05:26 AM
Hello,
Do we support passcode cache replication between PSNs in a node group, environment has an F5 load-balancer and we are persisting on the NAD IP-Address. If not, any recommendations on persistence to ensure admins are always sent to the same PSN so passcode caching works from same admin to multiple NAD access?
Pease keep in mind RADIUS and TACACS packet encryption through the F5 with no desire to decrypt. This is for device administration for both RADIUS and TACACS .
Thanks
Solved! Go to Solution.
02-11-2019 11:34 AM
I recently took some time examining how TACACS works from a protocol level when the failover wasn't working on NADs through an F5. Moving away from the caching between nodes discussion, there is an alternate solution that you could try using persistence. You would have to investigate whether or not the F5 will support this layer 4 session ID, but each unique login via TACACS generates a unique session ID that is unencrypted in the header. Packets 1-3 are TCP handshake/setup and have no TACACS relevance, packet 4 on contains a TACACS session ID. It persists as long as the connection remains between the NAD and F5.
Transmission Control Protocol, Src Port: 16997 (16997), Dst Port: tacacs (49), Seq: 1, Ack: 1, Len: 42
Source port: 16997 (16997)
Destination port: tacacs (49)
...Trimmed...
TACACS+
Major version: TACACS+
Minor version: 0
Type: Authentication (1)
Sequence number: 1
Flags: 0x00 (Encrypted payload, Multiple Connections)
.... ...0 = Unencrypted: Not set
.... .0.. = Single Connection: Not set
Session ID: 2960870317
Packet length: 30
Encrypted Request
For RADIUS I have used a pairing of attribute 4 (NAS IP) and attribute 31 (Calling Station ID) to persist all authentication related flows with great success.
02-10-2019 08:52 AM - edited 02-10-2019 09:14 AM
Please keep in mind ISE 2.4 allows this cache up to 300 seconds (5 minutes) only! AFAIK the cache is in memory on each PSN and no replication or persistent upon restart. I will verify this with our engineering team.
If using IPSec or DTLS encryption between ISE and NADs, then I think the F5 rules can only base on the NAD IP addresses. Thus, you might consider paring the PSNs as active and standby.
02-11-2019 11:22 AM
My reference to encryption here is typical operations for TACACS and RADIUS, we are not doing any IPSEC or DTLS. Under normal conditions the F5 will not see encrypted info.
02-11-2019 11:34 AM
I recently took some time examining how TACACS works from a protocol level when the failover wasn't working on NADs through an F5. Moving away from the caching between nodes discussion, there is an alternate solution that you could try using persistence. You would have to investigate whether or not the F5 will support this layer 4 session ID, but each unique login via TACACS generates a unique session ID that is unencrypted in the header. Packets 1-3 are TCP handshake/setup and have no TACACS relevance, packet 4 on contains a TACACS session ID. It persists as long as the connection remains between the NAD and F5.
Transmission Control Protocol, Src Port: 16997 (16997), Dst Port: tacacs (49), Seq: 1, Ack: 1, Len: 42
Source port: 16997 (16997)
Destination port: tacacs (49)
...Trimmed...
TACACS+
Major version: TACACS+
Minor version: 0
Type: Authentication (1)
Sequence number: 1
Flags: 0x00 (Encrypted payload, Multiple Connections)
.... ...0 = Unencrypted: Not set
.... .0.. = Single Connection: Not set
Session ID: 2960870317
Packet length: 30
Encrypted Request
For RADIUS I have used a pairing of attribute 4 (NAS IP) and attribute 31 (Calling Station ID) to persist all authentication related flows with great success.
02-11-2019 11:53 AM
Thanks, this is helpful. Will look into it.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide