Challenged Getting redirect-url to Redirect (Wired ISE)

[Marvin Rhoads]

I'm having an odd problem with an ISE deployment.

It's a greenfield ISE 2.1 distributed deployment with use case of wired MAB. The policy set is working, with the penultimate step (prior to deny) being to redirect to My Devices portal to register. We are using a custom pair of A-V attributes for the redirect-url and redirect-acl.

My NAD is a Catalyst 3560CG running IOS 15.2(2)E5, the recommended compatibility release.

CoA is happening as expected, with redirect acl and redirect url appearing in the authentication session details for unknown endpoints.

The problem is redirection is not actually happening. The connect action in the client browser just spins until timeout. We see the same symptoms on multiple browsers across multiple clients (Windows and OS X).

The client can resolve addresses (nslookup works fine). The client can also browse directly to the My Devices portal while subject to this AuthZ profile. There are no web proxies in the environment.

I have an open TAC case and the engineer said the config looks OK so far - he is labbing it up to see if he can reproduce before escalating.

Has anyone seen anything similar?

[nspasov]

"have you tried turning it off and on again?" :)

Hi Marvin, I am interested to see what the aaa and radius debugs look like as well as "show authentication session.."

Also, what about wireless and/or another switch model and/or another switch with different version of code?

[Marvin Rhoads · Accepted solution]

Hi Neno,

As a matter of fact I did try turning it off and back on again - several times. Great minds think alike. Haha.

I also observed the same problem with a 3560V2 running IOS 12.2(55)SE10.

With help from the Partner Security Community, I think I have it figured out - pending testing on-site tomorrow.

Note the caveats about using switch SVIs for redirection in this reference:

http://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/113362-config-web-auth-ise-00.html#anc15

The customer environment has the management networks wholly separate (think ACLs, VRFs and firewalls in a complex mix) from the user networks.

From what I've observed, it appears the redirect (coming from the switch's management SVI on an RFC1918 address in an isolated VRF) cannot reach the user networks (all with public IP addresses).

FYI Auth session looks all good:

Switch#sh authentication sessions int gi0/4 det
 Interface: GigabitEthernet0/4
 MAC Address: 00e0.7cc8.9c62
 IPv6 Address: Unknown
 IPv4 Address: <redacted>
 User-Name: 00-E0-7C-C8-9C-62
 Status: Authorized
 Domain: DATA
 Oper host mode: multi-domain
 Oper control dir: both
 Session timeout: N/A
 Restart timeout: N/A
 Session Uptime: 53s
 Common Session ID: 0A601608000000120032B3E5
 Acct Session ID: 0x00000008
 Handle: 0x05000006
 Current Policy: POLICY_Gi0/4

Local Policies:
 Service Template: DEFAULT_LINKSEC_POLICY_SHOULD_SECURE (priority 150)
 Security Policy: Should Secure
 Security Status: Link Unsecure

Server Policies:
 
 URL Redirect: https://mydevices.net.<redacted>
 URL Redirect ACL: CWA_R
 ACS ACL: xACSACLx-IP-dACL_WebAuth-57a3a48b

Method status list: 
 Method State

 mab    Authc Success

Switch#

[Ridma Ransara Jayaweera]

Hi Can you pls share the Switch port config?

Do you have redirect ACL applied to port.If so remove it and check.

[Marvin Rhoads]

Switch configuration was fine. It was as I noted earlier - the switch SVI subnet had an upstream ACL preventing access to the user subnet thus the redirection was never arriving.

[nspasov]

Good deal Marvin. Just to confirm: You were able to resolve the issue after testing with the suggestions from Partner Support Community?

Btw, I had one deployment where the customer had completely seperated network/out-of-band for management that resided on different VRF. This became an issue as that was the only SVI for the access layer switches. I could not get it to work even as the VRF could not be referenced in all of the RADIUS based configs. 

Regards, 

Neno

[Marvin Rhoads]

Yes Neno - it started working once I changed the configuration to give the switch an SVI in the user VLAN. That wasn't very operationally elegant though and would require assigning several hundred new SVIs across the campus.

We then discussed and got approval to modify the ACL that's on the gateway interface for the management subnet (and disable RPF checks).

We did that and the redirection is working in that use case as well.

Bottom line is that some IP address on the switch needs to be able to talk to whatever user addresses will be getting redirected.

[nspasov]

Fantastic! Thank you for sharing the solution with everyone here!

[Marvin Rhoads]

You're welcome. Thanks for the endorsement.