cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3149
Views
25
Helpful
12
Replies

ISE 3.0 patch 4, Cat sw 9200 7.3.1 Wire Redirect fail

KelvinT
Level 1
Level 1

ISE 3.0 patch 4

9200 Catalyst switch XE 7.3.1

Wired guest portal issue.  Redirect isn't working

 

- Test Guest portal on ISE work successfully

- Live logs and switch port shows ISE sending the redirect URL successfully

- IPDT is configured on the switch

- http and http secure is configured on the switch

- PC is able to ping the PSN and open it up on a browser

- ACL deny udp/dns,ISE PSN, allow www and 443

 

- browser show fail connection to cisco.com

- Tried pasting the redirected url in the browser but get error code 404

 

Any ideas?

Thanks

1 Accepted Solution

Accepted Solutions

KelvinT
Level 1
Level 1

The issue was the below command on the management SVI interface on the uplink switch.

 

ip verify unicast source reachable-via rx allow-self-ping

 

Since the access switch only layer 3 interface was the management interface and the only route was a default route to the management SVI on the uplink....

1- When the switch replied to the tcp "syn" with a "syn,ack" it sent the traffic to it's default gateway because the client was on a different vlan/subnet.  The switch's default gateway/SVI had the above command on it preventing the syn,ack respond.

 

This resolves the http redirect issue. 

 

Still have the https issue but I will close this discussion.

 

Thanks everyone for your support.

 

View solution in original post

12 Replies 12

Arne Bier
VIP
VIP

Tricky business, I know.

 

Can you please show us 

- show access-session int xxxx detail

- The ACL used for redirection (as specified in AuthZ Profile - and show us the ACL "show run" on the switch)

- The dACL applied in the pre-authentication  (should be defined in ISE)

 

It sounds like an ACL issue. I dealt with this recently and it was a pain

 

The URL redirection relies on the command "ip http server" to be enabled - I think you mentioned this already - but it has to be that exact command.

Hi Arne and that’s for your support. 

- show access-session int xxxx detail

it shows the proper redirect ACK and URL which is one of the PSN

 

- The ACL used for redirection (as specified in AuthZ Profile - and show us the ACL "show run" on the switch)

 

the ACL look like this:

deny udp any any eq domain

deny ip any host ISEPSN

permit tcp any any eq www

permit tcp any any eq 443

 

- The dACL applied in the pre-authentication  (should be defined in ISE)

I remove the dACL to troubleshoot. So that’s not the issue. 

FYI I also tried from the PC cmd “curl -v Cisco.com” but it failed. 

thanks again!

I am fairly sure I had to download an ACL in the pre-auth case - if anything, you can then try to ping the PSN for troubleshooting - (permit icmp) not necessarily recommended for production

This was the contents of the dACL for the pre-auth case (i.e. to get the web portal redirection phase to work)

permit udp any any eq 53
permit udp any eq bootpc any eq bootps
permit tcp any host <PSN_IP> eq 443
permit tcp any host <PSN_IP> eq 8443
permit icmp any any
deny ip any any

Hi Arne,

 

I added the dACL and it didn't help.  The browser continue to fail to open cisco.com and not redirect.

 

I'm thinking it's a possible cert issue on the access switch.  IDK.  I'm lost.  haha...

 

Is there a redirect debug command on the switch you are familiar with?  I was looking it up but didn't find anything.

 

Thanks again Arne

hslai
Cisco Employee
Cisco Employee

Please share the exact output from your curl command.

oh - have you configured the command below?

 

 

ip http server

 

It is required to allow the switch to process URL interception. If you have disabled this command on the switch, then URL redirection will not work

 

 

Hi Arne,

 

Yup and ip http secure-server.

KelvinT
Level 1
Level 1

Hello,

 

I found an interesting Cisco documentation that states:

 

"HTTPS traffic interception for central web authentication redirect is not supported."

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9200/software/release/17-7/configuration_guide/sec/b_177_sec_9200_cg/configuring_web_based_authentication.html

 

I saw this on all the cat9K documentation.  This contradicts the below ISE3.0 document that states it validated the cat9K.

https://www.cisco.com/c/en/us/td/docs/security/ise/3-0/compatibility_doc/b_ise_sdt_30.html

 

Any idea?

 

hslai
Cisco Employee
Cisco Employee

 

Note

HTTPS traffic interception for central web authentication redirect is not supported.

This note is about HTTPS, i.e. HTTP over SSL/TLS.

 

You might need an SVI on the client VLAN and subnet.

HTTP 404 means page not found. Try another ISE portal.

Hello Hslai,

 

Thanks for your rely.

 

"This note is about HTTPS, i.e. HTTP over SSL/TLS."

Correct.  Which is 99% of they browsing.  which is what Guest portal uses.  Are you saying this isn't related to guest portal redirect?

 

"You might need an SVI on the client VLAN and subnet."

Correct.  There is SVI for the end-device subnet but on the core switch...not the access switch.

 

"HTTP 404 means page not found. Try another ISE portal."

Correct.  hmmm....I'm thinking this is more related to the session ID added to the url.  To be continued....

 

 

hslai
Cisco Employee
Cisco Employee

AFAIK the connection attempts from the client endpoint need intercepted by the access switch so the client needs somehow reach to the SVI on the access switch. If that is not possible, try ISE Auth VLAN.

KelvinT
Level 1
Level 1

The issue was the below command on the management SVI interface on the uplink switch.

 

ip verify unicast source reachable-via rx allow-self-ping

 

Since the access switch only layer 3 interface was the management interface and the only route was a default route to the management SVI on the uplink....

1- When the switch replied to the tcp "syn" with a "syn,ack" it sent the traffic to it's default gateway because the client was on a different vlan/subnet.  The switch's default gateway/SVI had the above command on it preventing the syn,ack respond.

 

This resolves the http redirect issue. 

 

Still have the https issue but I will close this discussion.

 

Thanks everyone for your support.