ISE Web auth not working

[raga.fusionet]

Hey Guys,

I'm trying to configure Web Auth for users with no suplicant enabled.

I followed the steps mentioned on the ISE lab walkthough however when I open the browser on the client machine all I get is a "page cannot be displayed".

From the switch perspective I think everything looks fine however I can't really tell why the client never gets the login portal.

#sh authentication sessions int gi 1/0/36

            Interface:  GigabitEthernet1/0/36

          MAC Address:  c80a.a96e.367c

           IP Address:  172.16.14.32

            User-Name:  C8-0A-A9-6E-36-7C

               Status:  Authz Success

               Domain:  DATA

       Oper host mode:  multi-auth

     Oper control dir:  both

        Authorized By:  Authentication Server

           Vlan Group:  N/A

              ACS ACL:  xACSACLx-IP-CENTRAL_WEB_AUTH-4fe67b28

     URL Redirect ACL:  ACL-WEBAUTH-REDIRECT-ISE

         URL Redirect:  https://ISE.demo.local:8443/guestportal/gateway?sessionId=AC101065000000989BC260D4&action=cwa

      Session timeout:  N/A

         Idle timeout:  N/A

    Common Session ID:  AC101065000000989BC260D4

      Acct Session ID:  0x000000D8

               Handle:  0x61000098

Runnable methods list:

       Method   State

       mab      Authc Success

       dot1x    Not run

#sh run int gi 1/0/36

Building configuration...

Current configuration : 490 bytes

!

interface GigabitEthernet1/0/36

switchport access vlan 214

switchport mode access

switchport nonegotiate

switchport voice vlan 221

ip access-group ACL-ALLOW-ISE in

authentication host-mode multi-auth

authentication open

authentication order mab dot1x

authentication priority dot1x mab

authentication port-control auto

mab

dot1x pae authenticator

storm-control broadcast level 30.00

storm-control multicast level 30.00

storm-control action trap

spanning-tree portfast

end

sh access-lists ACL-ALLOW-ISE

Extended IP access list ACL-ALLOW-ISE

    10 permit ip any any (771 matches)

I can post screenshots from the ISE if needed.

Thanks in advance.

Raga

[Tarik Admani]

Can you post the contents of the ACL-WEBAUTH-REDIRECT-ISE ACL? It looks like you are referencing this ACL while sending a dACL that is defined in your authorization profile called "IP-CENTRAL_WEB_AUTH", you can start by removing the dACL from the authorization profile or if you want to use the dACL you will have to add the "radius vsa send authentication", here is a link to verify the radius commands you need:

http://www.cisco.com/en/US/docs/security/ise/1.1/user_guide/ise_sw_cnfg.html#wp1059651

Here is a link that covers the ACL configs:

http://www.cisco.com/en/US/docs/security/ise/1.1/user_guide/ise_sw_cnfg.html#wp1059724

I hope that helps!

-Tarik Admani

[raga.fusionet]

Tarik,

Thanks for your quick response,

Here are the ACLs that I have on the switch right now:

#sh access-lists

Extended IP access list ACL-ALLOW-ISE

    10 permit ip any any (2417 matches)

Extended IP access list ACL-DEFAULT-ISE

    10 permit udp any eq bootpc any eq bootps

    20 permit udp any any eq domain

    30 permit udp any any eq tftp

    40 deny ip any any log

Extended IP access list ACL-POSTURE-REDIRECT

    10 deny udp any host 172.16.10.50 eq 8905

    20 deny udp any host 172.16.10.50 eq 8906

    30 deny tcp any host 172.16.10.50 eq 8443

    40 deny tcp any host 172.16.10.50 eq 8905

    50 deny tcp any host 10.1.252.21 eq www

    60 permit ip any any

Extended IP access list ACL-WEBAUTH-REDIRECT-ISE

    10 deny ip any host 172.16.10.50 (896 matches)

    20 permit ip any any (14182 matches

Thanks.

[raga.fusionet]

172.16.10.50 is IP address of the ISE.

[raga.fusionet]

So I disabled the dACL from the Auth Profile and now I dont see any auth attempts from the switch side, actually I get this when I check the auth status:

sh authentication sessions int gi 1/0/36

No Auth Manager contexts match supplied criteria

I already had the

sh run | inc radius

aaa authentication dot1x default group radius

aaa authorization network default group radius

aaa accounting dot1x default start-stop group radius

aaa server radius dynamic-author

ip radius source-interface Vlan216

radius-server attribute 6 on-for-login-auth

radius-server attribute 8 include-in-access-req

radius-server attribute 25 access-request include

radius-server dead-criteria time 5 tries 3

radius-server host 172.16.10.50 auth-port 1812 acct-port 1813

radius-server key 7 02050D4808095E731F

radius-server vsa send accounting

radius-server vsa send authentication

Thanks.

[Tarik Admani]

Luis,

Did you bounce the port after removing the dACL? MAB should have been triggered.

[raga.fusionet]

ISE Config

[Tarik Admani]

Luis,

In the authentications report do you see the dACL request coming from the switch, when you issued the show auth sess int gig 1/0/36 in the first post, the username still had the mac address, this should have changed to the xACSACLx... as the username.

Thanks

tarik Admani

[Tarik Admani]

Are you able to resolve the web address of the initial requests i.e www.google.com, if so can you resolve ISE.demo.local? Also is the svi for vlan 214 on this switch or is this trunked up to your core? If vlan 214 is trunked to the core then you will need to allow the clients to access the management vlan of this switch on the redirection ports (80,443,8080, and 8443).

Let me knwo if this works,

Tarik Admani

Here is the reference guide for the ports to open if the 214 svi doesnt exist (note figure 3)

http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6638/app_note_c27-577494.html

thanks,

Tarik Admani

[raga.fusionet]

Ok, so I few pointers:

I did forget to bounce the port that is why I was not seeing auth attemps, with the DACL removed the MAB kicks in like you mentioned:

#sh authentication sessions

Interface  MAC Address     Method   Domain   Status         Session ID

Gi1/0/4    5475.d02b.152b  mab      VOICE    Authz Success  AC1010650000007A9B2B270E

Gi1/0/36   c80a.a96e.367c  mab      DATA     Authz Failed   AC101065000000A69BFE0DAE

Since it still didnt work, I went back and put the dACL back in

Also, for some reason I had an external DNS configured on my test machine therefore I couldnt resolve ISE.demo.local,

I can resolve now that I pointed it to my internal DNS.

The SVI is on the core, not on this switch. When you say allow the clients to access the managment vlan of this switch on the redirection ports where exactly are we talking about? Switch ACLs or ISE ACLs? And which one?

The username now shows as  xACSACLx. (I cant remember what it was before) on the ISE, but It still looks like a MAC on the switch:

sh authentication sessions int gi 1/0/36

            Interface:  GigabitEthernet1/0/36

          MAC Address:  c80a.a96e.367c

           IP Address:  172.16.14.32

            User-Name:  C8-0A-A9-6E-36-7C

               Status:  Authz Success

               Domain:  DATA

       Oper host mode:  multi-auth

     Oper control dir:  both

        Authorized By:  Authentication Server

           Vlan Group:  N/A

              ACS ACL:  xACSACLx-IP-CENTRAL_WEB_AUTH-4fe67b28

     URL Redirect ACL:  ACL-WEBAUTH-REDIRECT-ISE

         URL Redirect:  https://ISE.demo.local:8443/guestportal/gateway?sessionId=AC101065000000AA9C0C39F0&action=cwa

      Session timeout:  N/A

         Idle timeout:  N/A

    Common Session ID:  AC101065000000AA9C0C39F0

      Acct Session ID:  0x000000EB

               Handle:  0x4F0000AA

Runnable methods list:

       Method   State

       mab      Authc Success

       dot1x    Not run

Something I noticed on the report is that the posture is showing as "pending" I dont know if this has anything to do with my problem ...

Thanks again man!

[Tarik Admani]

No problem, I wanted to highlight the following:

If  the switch is not configured for SVIs on the data VLANs, the switch can  send the login page to the host using a default route. When a default  route is used, all traffic from the switch to the host is sent to the  default router, which may be one or more hops away. The default router  then routes the traffic to the host back through the access switch.  Figure 3 shows the initial TCP traffic flow for this situation.

Figure 3. TCP Traffic Flow for Login Page When No Layer 3 SVI for Host VLAN Exists on Access Switch

Although  this approach introduces additional hops in the return path from the  switch to the host, it produces negligible load on the default router  and intervening infrastructure since only the WebAuth traffic from the  switch to the host follows this path. In campus designs that do not use  SVIs on the data VLAN,⁶ a default route is typically already configured. In this case, no  additional configuration is required to support WebAuth. However,  problems may arise in the case in which traffic to the default router is  bridged through a stateful firewall. The original SYN packet in the TCP  handshake is consumed by the access switch, so the first packet that  the firewall sees is the SYN-ACK packet from the access switch. Stateful  firewalls typically drop SYN-ACK packets if they have not seen the  original SYN packet.
In this case, you will need to turn off stateful inspection for ports 80 and 443 on the firewall.

When  a non-crypto image is used, Cisco IOS Software will automatically  redirect all HTTP packets (TCP port 80) to itself. URLs that reference  HTTPS (TCP port 443) will not trigger redirection. If HTTPS support is  required, a Cisco IOS Software crypto image will be necessary. Cisco IOS  Software crypto images redirect HTTPS traffic and can be configured to  redirect HTTP traffic as well. URLs that contain a port other than 80 or  443 (for example, http://my-acs-server:2002) will not trigger redirection.

Note: WebAuth can intercept nonstandard ports using an IP port-to-application  map (PAM) entry that maps a new port to HTTP (or HTTPS). In addition,  the Cisco IOS Software HTTP server needs to be reconfigured to listen on  the nonstandard port. However, the Cisco IOS Software HTTP server can  run only on a single port. Therefore, support for port 80 and a  nonstandard port are mutually exclusive. If PAM is used to remap the  port used for HTTP, then URLs that reference the default port (80) will  not trigger redirection. In addition, if traffic to the default router  is bridged through a stateful firewall, that firewall will have to turn  off stateful inspection for the remapped port.

If  the crypto image is used and HTTPS is also configured, the switch will  initiate an SSL session, even if the initial HTTP request was to port  80. The advantage of this approach is that the user's credentials will  be sent over an encrypted channel to the switch and cannot be snooped.  The disadvantage is that the browser will prompt the end user to accept  the switch's certificate, adding another step to the authentication  process. By default, the switch sends a self-signed certificate. Some  browsers display a warning or error message when receiving a self-signed  certificate. This event can be mitigated by configuring the switch with  a certificate signed by a trusted third-party certificate authority.

This should be what you are running into at this point. Please use the above for reference (verify you are running k9) and also use PAM to map 8443 to https to see if that works for you. Also check and see if you are using a default route (which i am sure since radius is working).

Thanks,

Tarik admani

[raga.fusionet]

Tarik,

I went ahead and created port mapping for port 8443, however I still get a page cannot be displayed.

ip port-map https port 8443

The swiche does have a crypto image just in case. And the core switch is connected thru a trunk to this switch, they are actually cdp neighbors. The ISE is connected to the core. The SVI for vlan 214 and vlan 210 (where the ISE resides) are on the core.

Something I'm noticing and that I dont know if it is the expected behavior is that from the test machine if I try to do an nslookup to the ise it fails. If I disable the wired interface and do the same nslookup using the wireless interface it does resolve.

I dont know what else to check.

Thanks.

[Tarik Admani]

Luis,

First can you paste the show run | inc ip http (to make sure that http-server is enabled), if that is then lets check below.

I assume that the management vlan of the switch is on vlan 216? If so, is there an ACL on the core svi or the svi of the switch that is blocking traffic from vlan 214? If so we will need to open up the ports that the redirection traffic is destined to i.e. 80,443,8443..etc also do you see the browser changing its url to the redirection page after trying google?

Thanks,

[raga.fusionet]

Tarik, http and https are enabled and dont see anything that might be blocking the traffic as far as the interfaces go:

On the access switch:

RFNET-R1-P-SW1#sh run | inc http

ip port-map https port 8443

ip http server

ip http secure-server

RFNET-R1-P-SW1#sh ip int brie | ex una

Interface              IP-Address      OK? Method Status                Protocol

Vlan216                172.16.16.101   YES NVRAM  up                    up

RFNET-R1-P-SW1#sh run int vlan216

Current configuration : 98 bytes

!

interface Vlan216

ip address 172.16.16.101 255.255.255.0

ip helper-address 172.16.10.237

end

On the core switch:

RFNET-R2-P-SW3#sh run int vlan 216

!

interface Vlan216

ip address 172.16.16.3 255.255.255.0

end

RFNET-R2-P-SW3#sh run int vlan 214

interface Vlan214

ip address 172.16.14.3 255.255.255.0

end

RFNET-R2-P-SW3#sh run int vlan 210

interface Vlan210

ip address 172.16.10.3 255.255.255.0

end

Regular traffic works fine if I use the dot1x suplicant, so I dont think is an ACL issue.

If I check the browser it says "resolving google.com" and then sits there and eventually times out and says the page cannot be displayed.

So it basically fails to do the dns lookup, I can confirm this by opening a command prompt and trying to resolve google.com or ise.demo.local. It basically fails thru the wired connection.

If I enable the dot1x supplicant and try the same lookups they work just fine.

What can be blocking the DNS requests??

Thanks!

[Tarik Admani · Accepted solution]

Are you hitting the same authorization profiles for the dot1x and mab users? I saw the following in one of the previous posts:

Gi1/0/36   c80a.a96e.367c  mab      DATA     Authz Failed   AC101065000000A69BFE0DAE

Let me know if this is still the case, also try removing the port to application mapping and set that back to 443 and we will have to check as to why the authorization failing.

Thanks,

Can you ping the dns servers from the client?