Solved: Re: Cisco 3750G not redirecting HTTP/HTTPS even though redirect ACL pushed to switch

glenn.dalcourt · ‎03-19-2018

ISE 2.3.0.298

Cisco IOS 15.0(2)SE11

Cisco 3750G allowing full network access even though 'show auth sess int' conveys that the switch should be redirecting traffic to guest web portal. I also see hits on the redirect ACL.

How can I troubleshoot the redirection of web traffic to ISE (10.223.2.2). (The switch is not a router on the pre-web-auth VLAN. I haven't seen in documentation where the switch needs to be L3 capable on the pre-web-auth VLAN to intercept ARPs however.)

***RUNTIME SNIPPETS***

LAB-S3750-1#show auth sess int g1/0/19
Interface: GigabitEthernet1/0/19
MAC Address: 000e.c68f.4089
IP Address: 10.223.254.11
User-Name: 00-0E-C6-8F-40-89
Status: Authz Success
Domain: DATA
Security Policy: Should Secure
Security Status: Unsecure
Oper host mode: multi-domain
Oper control dir: both
Authorized By: Authentication Server
Vlan Policy: 254
ACS ACL: xACSACLx-IP-WEBAUTH-5a9da3c9
URL Redirect ACL: ACL_WEBAUTH_REDIRECT
URL Redirect: https://LAB-ISE-PRI.labratory.local:8443/portal/gateway?sessionId=0ADF63020000001C003758F2&portal=f0ae43f0-7159-11e7-a355-005056aba474&action=cwa&token=3295083fba9273cff940b58a47b621fc
Session timeout: N/A
Idle timeout: 300s (local), Remaining: 209s
Common Session ID: 0ADF63020000001C003758F2
Acct Session ID: 0x00000024
Handle: 0xA300001D

Runnable methods list:
Method State
dot1x Failed over
mab Authc Success
webauth Not run

LAB-S3750-1#show access-list
Extended IP access list ACL_WEBAUTH_REDIRECT
10 deny ip any host 10.223.2.2
20 permit tcp any any eq www (332 matches)
30 permit tcp any any eq 443 (692 matches)
40 permit tcp any any eq 8443
50 deny ip any any log

Extended IP access list INTERFACE_DEFAULT
10 permit udp any eq bootpc any eq bootps
20 permit udp any any eq domain
30 permit tcp any any eq 443
40 permit tcp any any eq www

Extended IP access list xACSACLx-IP-PERMIT_ALL_TRAFFIC-57f6b0d3 (per-user)
10 permit ip any any

Extended IP access list xACSACLx-IP-WEBAUTH-5a9da3c9 (per-user)
10 permit tcp any any eq www
20 permit tcp any any eq 443
30 permit tcp any any eq 8443
40 permit udp any any eq domain
50 deny ip any any

***CODE SNIPPETS***

!

ip dhcp snooping
ip device tracking

!

ip admission name PROXY_HTTP proxy http

!

fallback profile WEBAUTH-PROFILE
ip access-group INTERFACE_DEFAULT in
ip admission PROXY_HTTP
!

interface GigabitEthernet1/0/19
switchport access vlan 254
switchport mode access
ip access-group INTERFACE_DEFAULT in
authentication event fail action next-method
authentication event server dead action authorize vlan 254
authentication event server dead action authorize voice
authentication event no-response action authorize vlan 254
authentication event server alive action reinitialize
authentication host-mode multi-domain
authentication order dot1x mab webauth
authentication priority dot1x mab webauth
authentication port-control auto
authentication timer inactivity 300
authentication fallback WEBAUTH-PROFILE
mab
dot1x pae authenticator
dot1x timeout quiet-period 5
dot1x timeout server-timeout 5
dot1x timeout tx-period 5
dot1x timeout supp-timeout 2
dot1x max-req 1
dot1x max-reauth-req 1
spanning-tree portfast

!

ip access-list extended ACL_WEBAUTH_REDIRECT
deny ip any host 10.223.2.2
permit tcp any any eq www
permit tcp any any eq 443
permit tcp any any eq 8443
deny ip any any log

!
ip access-list extended INTERFACE_DEFAULT
permit udp any eq bootpc any eq bootps
permit udp any any eq domain
permit tcp any any eq 443
permit tcp any any eq www

glenn.dalcourt · ‎03-19-2018

I don't fully understand the flow of packets nor the sources of the packets when redirection occurs...When I take the firewall out of the picture redirection occurs fine.

What I can say is that the client traffic flowed through the firewall. The switches control plane traffic bypassed the firewall and hit the upstream router. I think some sort of asymmetric routing was the issue somewhere in the flow of redirect traffic.

Client > L2 switch > ASA > R1 > ISE

L2 Switch Control Plane > R1 > ISE

I redesigned the lab based off of this:

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

"Important Note about Switch SVIs

At this time, the switch needs a switch virtual interface (SVI) in order to reply to the client and send the web portal redirection to the client. This SVI does not necessarily have to be on the client subnet/VLAN. However, if the switch has no SVI in the client subnet/VLAN, it has to use any of the other SVIs and send traffic as defined in the client routing table. This typically means traffic is sent to another gateway in the core of the network; this traffic comes back to the access switch inside the client subnet.

Firewalls typically block traffic from and to the same switch, as in this scenario, so redirection might not work properly. Workarounds are to allow this behavior on the firewall or to create an SVI on the access switch in the client subnet."

View solution in original post

Rob Ingram · ‎03-19-2018

Hi,
You need "ip http server" configured for redirect, I can't see it in your config output. Can you confirm you have it configured?

glenn.dalcourt · ‎03-19-2018

Confirmed this is configured. Accidentally left it out of the code snippets.

***CODE SNIPPETS***

ip http server
ip http secure-server
ip http secure-active-session-modules none
ip http active-session-modules none

Rob Ingram · ‎03-19-2018

What aaa commands do you have defined?

glenn.dalcourt · ‎03-19-2018

Confirming that dot1x and MAB are functioning.

As requested:

aaa new-model
!
!
aaa group server radius RAD
server 10.223.2.2
server 10.223.10.4
server 10.223.10.5
!
aaa group server tacacs+ TAC
server 10.223.2.2
ip tacacs source-interface Vlan99
!
aaa authentication login default group tacacs+ group radius local
aaa authentication enable default group tacacs+ group radius enable
aaa authentication dot1x default group radius
aaa authorization exec default group tacacs+ local
aaa authorization commands 15 default group tacacs+ local
aaa authorization network default group radius
aaa accounting dot1x default start-stop group radius
aaa accounting exec default start-stop group tacacs+ group radius
aaa accounting system default start-stop group tacacs+ group radius
!
aaa server radius dynamic-author
client 10.223.2.2 server-key
!
aaa session-id common

Rob Ingram · ‎03-19-2018

When the redirect acl is active on the interface and redirect is not working, is the client computer able to resolve the portal fqdn of the PSN?

Can you take a packet capture from the PSN when the client attempts to connect to the portal? See what, if any traffic hits the PSN.

glenn.dalcourt · ‎03-19-2018

See attached. (change extension to pcap)

glenn.dalcourt · ‎03-19-2018

The host is not resolving lab-ise-pri.labratory.local. Changed the authorization policy to point to ISE's IP as opposed to hostname. Still a no go. No redirection:

LAB-S3750-1#
Mar 19 18:21:51.528: %AUTHMGR-5-SUCCESS: Authorization succeeded for client (000e.c68f.4089) on Interface Gi1/0/19 AuditSessionID 0ADF63020000003400A9E542
LAB-S3750-1#show auth sess int g1/0/19
Interface: GigabitEthernet1/0/19
MAC Address: 000e.c68f.4089
IP Address: 10.223.254.11
User-Name: 00-0E-C6-8F-40-89
Status: Authz Success
Domain: DATA
Security Policy: Should Secure
Security Status: Unsecure
Oper host mode: multi-domain
Oper control dir: both
Authorized By: Authentication Server
Vlan Policy: 254
ACS ACL: xACSACLx-IP-WEBAUTH-5a9da3c9
URL Redirect ACL: ACL_WEBAUTH_REDIRECT
URL Redirect: https://10.223.2.2:8443/portal/gateway?sessionId=0ADF63020000003400A9E542&portal=f0ae43f0-7159-11e7-a355-005056aba474&action=cwa&token=37634fa389238c30cfa47fe499ab6df3
Session timeout: N/A
Idle timeout: 300s (local), Remaining: 297s
Common Session ID: 0ADF63020000003400A9E542
Acct Session ID: 0x00000047
Handle: 0x4F000035

Runnable methods list:
Method State
dot1x Failed over
mab Authc Success
webauth Not run

glenn.dalcourt · ‎03-19-2018

I know the portal is functioning because if I manually input the Redirect URL from the 'show auth sess int' command into the browser on the client I can authenticate against AD and CoA occurs and places me on the correct VLAN.

Rob Ingram · ‎03-19-2018

So the client is not attempting to resolve any DNS names? From your previous output below, I would have thought DNS should hit ace # 50.

LAB-S3750-1#show access-list
Extended IP access list ACL_WEBAUTH_REDIRECT
10 deny ip any host 10.223.2.2
20 permit tcp any any eq www (332 matches)
30 permit tcp any any eq 443 (692 matches)
40 permit tcp any any eq 8443
50 deny ip any any log

This guide says to explicitly "deny udp any any eq 53"

glenn.dalcourt · ‎03-19-2018

I don't fully understand the flow of packets nor the sources of the packets when redirection occurs...When I take the firewall out of the picture redirection occurs fine.

What I can say is that the client traffic flowed through the firewall. The switches control plane traffic bypassed the firewall and hit the upstream router. I think some sort of asymmetric routing was the issue somewhere in the flow of redirect traffic.

Client > L2 switch > ASA > R1 > ISE

L2 Switch Control Plane > R1 > ISE

I redesigned the lab based off of this:

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

"Important Note about Switch SVIs

At this time, the switch needs a switch virtual interface (SVI) in order to reply to the client and send the web portal redirection to the client. This SVI does not necessarily have to be on the client subnet/VLAN. However, if the switch has no SVI in the client subnet/VLAN, it has to use any of the other SVIs and send traffic as defined in the client routing table. This typically means traffic is sent to another gateway in the core of the network; this traffic comes back to the access switch inside the client subnet.

Firewalls typically block traffic from and to the same switch, as in this scenario, so redirection might not work properly. Workarounds are to allow this behavior on the firewall or to create an SVI on the access switch in the client subnet."

glenn.dalcourt · ‎03-19-2018

If you could detail out the packet flow/paths in CWA redirection via a link that'd be greatly appreciated.