cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3410
Views
0
Helpful
8
Replies

Challenged Getting redirect-url to Redirect (Wired ISE)

Marvin Rhoads
Hall of Fame
Hall of Fame

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?

1 Accepted Solution

Accepted Solutions

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#

View solution in original post

8 Replies 8

nspasov
Cisco Employee
Cisco Employee

"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?

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#

Hi Can you pls share the Switch port config?

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

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.

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

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.

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

You're welcome. Thanks for the endorsement.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: