Greetings programs!

In this post, I’m going to go through my troubleshooting workflow for webauth redirect.

Introduction

Webauth redirect is a core function of providing Network Access control with Identity Services Engine ISE.  It’s used for a number of critical authentication flows, and when it does not work, you will not be able to provide guest access or onboard devices.

Taken as a whole the configuration and processes between ISE and the Network Access devices (NADs, which are Switches, and Wireless LAN Controllers) is quite complex, especially in the case of the switches.  Trying to troubleshoot by staring at pages and pages of config, and making random google searches is going to be slow and painful.  It’s much better to understand the information flow and dependencies, and using the device output to logically deduce where the problem lies.

Lab Setup

Network Topology

This is the toplogy we’re going to use for our example. It’s a cobbled together lab.  ISE is running in a remote location, the vWLC is running in esxi on an intel NUC in my home lab.

ISE Configuration

Our ISE configuration is going to as simple as I can make it. This will be our policy:

Policy Sets

There will be separate policy sets for wired and wireless for the sake of clarity.

Authentication policy

• Mac Address Bypass (MAB)
  Continue if authentication fails

Authorization Policy

• IT – MAC addresses in the IT group get full access to the network
• GUEST – Guest users Will have access to the internet only
• Webauth Redirect – If the connecting device is unknown to ISE, we’ll:
  • Apply an ACL that restricts network access to the bare minimum
  • Redirect the user to a registration portal.

Guest Registration Portal Configuration

To keep things simple, we’re going to allow self registration, which is not something you would normally do.  After registering, the MAC address of the user’s device will be placed in the GuestEndpoints Group, which is the default for ISE.

 

WebAuth Redirect process flow

At a high level a basic flow works like this:

1. Unkown device connects to network
2. ISE returns a result to the Network Access Device (NAD) with a redirect URL.
3. when the user tries to connect to a website the NAD intercepts the HTTP get request and returns a 302 redirect, pointing towards the web portal on ISE.  The redirect also contains the Radius session ID and the original url the user was trying to reach.
4. The user and device are onboarded.
   1. in the case of guests, the mac address of the device is stored in the endpoint database and associated with a guest endpoint group
   2. for BYOD, the device will be issued a certificate for dot1x authentication
5. after onboarding, ISE will send a Change of Authorization (CoA) to the NAD.  This re-triggers the authentication process as if the user had just connected.
6. Because the Device is now known to ISE, it should match an authorization rule, giving the device network access.

Troubleshooting workflow

To troubleshoot efficiently, it’s important to have a workflow that produces consistent results, then you need to trust it!  It can be tempting to take shots in the dark hoping for the quick fix, but in the long run a process oriented approach will be consistently more productive and less stressful.

Troubleshooting workflow summary:

1. Trigger the process
   1. connect to network
   2. issue http get via web brower
2. Check the radius log on ISE to verify output
3. Check the Authentication result on the Switch/WLC to verify output
4. Determine what stage of the flow the fault is occurring at
5. Check dependencies for the failed portion of the flow
6. Correct what appears to be the problem.
7. Trigger the process again
   1. If it’s still not working did we fix a fault?
      1. if not, put the change back
         1. return to step 1
      2. If still not working but a fault was fixed
         1. go to step 5

Now that we have our troubleshooting flow written down, let’s get started

 

Wireless WebAuth Redirect

on the WLC, the Redirect ACL uses opposite processing logic from the switches.   Permit means “dot not redirect this traffic”.  All other traffic will be redirected.  This means we don’t have to bother with referencing an airespace ACL on the WLC as the implicit deny will prevent the remaining traffic from going anywhere.

Additionally, ACLs on the WLC have the following additional differences.

1. They use natural masks not wildcard masks
2. They’re bidirectional
   1. you must define the flow in both directions

Dependencies on the WLC

1. Redirect ACL
   1. must be defined on the WLC
2. CoA support
   1. disabled by default when defining a radius server
3. MAC filtering on the layer 2 security configuration

Troubleshooting a wireless problem

Portal page doesn’t load in the browser

Typically a problem with the redirect ACL on the WLC.  Steps to investigate:

1. Check ISE livelog for webauth redirect status
2. Check Client Status on WLC
3. Check webauth ACL.
   1. Make sure DNS is able to resolve hostname in URL
   2. Ensure ACL is permitting the ip address of the ISE node

User does not gain access to the network after logging in to portal

Common causes:

VLAN change in portal config without Java capable browser

Changing VLANs at the end of a guest flow requires the the user to download and run the NAC Agent to release and renew the IP address of the client. The NAC agent is Java based, and not supported in current web browsers. Vlan change for guest flows is not a good idea.

Enabling this setting will trigger a java applet download to run the NAC agent when the users completes log in.  Probably not a good idea.

Change of authorization Failure

CoA is disabled by default in the Radius server configuration on the WLC, so it’s probably a common fault.  Let’s use this one as an example of how to look at the device output to work out what’s going on.

First place to look is the Radius LiveLog.  Looking at the sequence of events, we can see that the client hit the webauth rule, logged in, and then something went wrong.

We already know from glancing at this that first few steps worked and the user access the portal, but let’s take the opportunity to look at output on ISE and WLC for the webauth redirect step.

Checking the initial log entry on ISE (this is at the very bottom):

there’s the redirect with the with the session id.  The user-name is the mac address of the wireless in the client.

Now let’s go to the WLC and take a look:

the redirect URL and redirect ACL have been applied to the client.  The WLC has client in a Central Web Auth State.

Let’s take a quick look at the redirect ACL.

Redirect ACL allows DNS and traffic to and from ISE.  all non http/s traffic will be dropped.  HTTP/s traffic will be intercepted and the redirect mesages with the redirect URL will be send to the client.

So everything looks good until the end.  Let’s take a look at that last log entry in ISE.

Change of Authorization Failure.

Ok, let’s go take a look at the configuration on the WLC.

Sure enough.  Change of Authorization was disabled.

Ok, let’s enable CoA, delete the endpoint and guest account from ISE, and give it another try.

Let’s break down what’s going on here.

1. User gets redirected
2. He signs in
3. mac address of the deivce is added to the guest endpoints Identity group
4. Change of Authorization is sent to the WLC
5. The WLC authenticates the user against ISE
6. The authentication request loops back through our Authorization policy only this time it it hits on our wireless guest rule because the device is now in the guest endpoints group.

Ok that was cool right?

 

Wired WebAuth Redirect

From the perspective of ISE

 

This screenshot depicts the set of Radius attributes that are sent down to the NAD.  There are 4 items.

1. Radius Access-Accept
2. The Downloadable ACL to restrict network access
3. The redirect URL for guest registration portal
4. The Redirect ACL

The Redirect ACL is the always the confusing part.  Put simply, The redirect ACL tells the switch what traffic NOT to redirect and what traffic to intercept for redirection.  This solves a chicken and egg problem.  If http get requests to ISE were intercepted by the switch, what you would have is a redirect loop and you would never reach the portal.

Short answer: Permit means “redirect this traffic”.  Deny means “leave this traffic alone”.

Keep in mind however only http/https traffic can actually be redirected.  The Switch uses the built in web server to create the http redirect message that’s sent back to the client web browser.

Dependencies on the Switch

In addition to the normal radius and dot1x stuff that’s required, WebAuth requires some additional items.

1. Redirect ACL
   1. is defined locally on the switch
2. Authentication proxy
   1. needed to support web authentication feature
3. CoA Support
   1. needed to initiate re-authentication after registering in the portal
4. IP Device tracker
   1. Needed for the Enforcement Policy Module (EPM) to have awareness of the endpoint’s ip address.
5. HTTP/HTTPS server enabled
   1. The switches onboard web server is what intercepts the connection request, handshakes with the client’s web browsers, sends the redirect message.

Ok, let’s apply our troubleshooting workflow to a wired problem.

Troubleshooting a Wired problem

User doesn’t get portal page when connecting.

Just like with wireless, we start by looking at log and device output to narrow the scope.

Let’s start with the radius log.  It looks like we’re stopped at webauth redirect.

Let check the switch.

we can see we’re on switchport g1/0/1 and that the port is in the state we expect.  so why isn’t it working?  Let’s check the Redirect ACL.

Redirect ACL looks good.  hmm.  What are our other dependencies?  Ah!

Http server is not running.  ok let’s fix that and try again.

What?  Why is the switch sending a reset instead of redirecting?  we know the http server being shut off was an problem.  It must mean there’s another fault with the switch.  Let’s check for ip device tracking.

What?

What’s this, command doesn’t work?  Better check the documentation.

Ah, looks like our trusty dot1x template for ios-xe 15 isn’t working so well for ios 16, now we have to use some different commands to get ip device tracking to work.  So let’s do that:

Working.

These are hard problems to solve because you have multiple faults and when the first thing you find doesn’t fix it, it’s easy to start doubting yourself.  maybe it’s a problem with the endpoint etc.  But by trusting the Radius logs, device output, and our knowledge of the process flow, we can deduce where the problem has to be, and you have to follow the output where it leads you.

I hope this was helpful.  It’s helpful for me to write it down.

 

Until next time.

-s