cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
13463
Views
10
Helpful
26
Replies

Cisco ISE - CWA Redirect

Gary Higgs
Level 1
Level 1

Why are the ISE nodes needed to be defined in the web authentication redirect acl that is configured locally on the switch?

All the documentation that I've found states this. I've setup my 2yr old ISE environment this way and was advised in the beginning to do so. But after thinking the whole authentication process through and then testing out my theories I don't understand why the ISE nodes need to be defined in the switch redirect acl. I am now testing with a simple "redirect www & 443" acl and it is working as expected.

The client connects to the network and, for our environment, is requested to do dot1x until that times out and then it shifts to mab. At which point, I do not have an authz rule defined for my test machine and therefore matches my catch-all authz rule of CWA which sends a CWA DACL. The switch lays the acls on the interface in this order: 1. Redirect 2. DACL 3. PACL. In my DACL I have access to the ISE nodes allowed (just to be safe) and the redirection still works because my test machine is not sending any www/443 traffic to the ISE nodes that I'm aware of (CWA is 8443).

Can someone explain (in detail) why a client machine would send www/443 traffic to the ISE nodes and therefore need to be defined in the CWA redirect acl local to the switch.

2 Accepted Solutions

Accepted Solutions

Poonam Garg
Level 3
Level 3

In fact, dACL will replace the pre-authentication ACL/PACL you have configured on the switchport. Traffic must be first allowed via dACL then it will hit redirect ACL.

View solution in original post

Hi Gary,

Please find the attached slide from Cisco supporting my above statement that the traffic must first be allowed in dACL or Port ACL (if dACL is not configured as dACL is optional, configured only if you want to restrict access on switch port based user authenticating the network.i.e per-user based) then only it will hit redirect ACL.

Hope that will clear the confusion on which ACL got hit first.

View solution in original post

26 Replies 26

Poonam Garg
Level 3
Level 3

Hello Gary,

You might be aware that in CWA the client is authenticated twice. As per my understanding PACL is the ACL-Default you apply on port manually. When you do First authentication then this ACL will be dynamically replaced by DACL. So now this is the acl that govern what traffic can pass through that port. so in this you need to permit DHCP, DNS,port  80,443 and traffic to ISE on port 8443.

Now when the traffic enters the switch Redirect ACL come in to picture. Here you need to permit only traffic that need to be redirected means port 80 and 443 traffic and you need to deny DHCP,DNS and traffic to ISE on port 8443 to get redirect.

So when the user try to access any web page,then first web browser needs to resolve domain name so it will issue a DNS query which dacl is allowing. then it hit redirect acl but it is denying that traffic to get redirected so client will resolve domain name. Now client try to send http traffic to the resolved ip address, http is allowed in DACL, then it hit redirect ACL which is permitting this http traffic to get redirected to ISE on port 8443. so client browser is redirected to new url.

Again DNS query for new url successful. client now send web traffic to ISE on port 8443 which is allowed in DACL, now hit redirect acl where it is denied to get redirected so client will be able to get Guest portal from ISE.

 

HTH

"Please mark the helpful posts"

Poonam,

I appreciate the response. I understand the process and flow of CWA but I still don't see why the ISE nodes need to be defined (as deny statements or at all) in the redirect acl that is locally configured on the switch. Let me try to explain it better (sorry for the novel):

 

1. a default PACL is statically applied to an unused interface. For my environment our PACL is a simple "permit ip any any" which allows an open fallback in case communication to ISE fails.

2. A client plugs in and the switch begins talking dot1x to the client. During this time the PACL is the ONLY acl that is applied to the interface/client.

3. The client does not run dot1x and therefore the switch eventually fails over to mab. At this time, the CWA authz rule comes into effect and ISE sends the DACL to the switch via radius and also references which RACL (redirect acl) to use.

4. Not many people seem to understand this part....The switch then rebuilds the ACL that is applied to the interface/user. The switch creates an ACL that consists of ALL THREE ACLs. The first portion of this ACL is the RACL with permit statements (which are the deny RACL statements configured on the switch) and then redirect statements (which are the permit RACL statements configured on the switch) and then the DACL from ISE is the next portion of this new ACL and then the very last portion is the original static PACL that is configured on the port.

 

Again, I've tested this out over and over again on several different platforms (6500, 3700, 3800) and because, during the stage where the interface is in CWA state, the ACL that is applied to the interface is ALL THREE ACLs in the order of RACL>DACL>PACL....it doesn't seem to make sense that you need to define the ISE nodes in the RACL because all you need to define is what traffic you want to redirect. You define what traffic you want allowed in the DACL which is where you state access to the ISE nodes (either complete access or only 8443 access).

 

Let me give you this example. Say I have the following confgured:

CONFIGURED SWITCH INTERFACE ACL (PACL)
  ip access-list standard ACL-ALLOW
   permit ip any any

CONFIGURED SWITCH REDIRECT ACL (RACL)
  ip access-list extended ACL-WEBAUTH-REDIRECT
   permit tcp any any eq www 443

CONFIGURED ISE DOWNLOADABLE ACL (DACL)
  permit tcp any host <psn01> eq 8443
  permit udp any host <dns01> eq 53
  deny ip any any

 

Then the process would look like this:

1. During dot1x negotiation the acl that is used is this:

permit ip any any     <<<<<PACL

2. Once CWA is in effect then the acl looks like this:

redirect tcp host <host ip> any eq www 443             <<<<<<RACL
permit tcp host <host ip> host <psn01 ip> eq 8443       <<<<<<DACL
permit udp host <host ip> host <dns01 ip> eq 53       <<<<<<DACL
deny ip any any      <<<<<<DACL
permit ip any any      <<<<<<PACL

Hello Gary,

As per my understanding, once the port get authenticated, the order of ACL is 1. dACL 2. Redirect ACL 3. Port ACl.

Secondly why the ISE nodes need to be defined (as deny statements or at all) in the redirect acl

When redirect acl is applied to the port, any HTTP or HTTPS traffic that the client sends triggers a web redirection. Deny statement in redirect ACL at first place denies the ISE IP address so traffic to the ISE goes to the ISE and does not redirect in a loop. (In this scenario, deny does not block the traffic; it just does not redirect the traffic)

This goes back to the heart of my question. It does not appear that the client is sending any port 80 or 443 traffic to the ISE nodes. It is only sending 8443 and therefore would not get caught up in the redirect loop. I've tested this out & it works.

Hi Gary / Poonam,

I find the conversation you guys are having very enlightening.  I'm having a similar issue with my ISE / Switch deployment. I'm using ISE v1.1.2 and switch 3560x v 15.2(1)E3.  Can seem to figure out how the ACL and dACL are applied to the interface.  However, I'm using the NAC agent instead of using the CWA option.

Basically, my configuration consists of a Machine AuthZ profile and a User AuthZ profile with the PostureStatus_NotEqual_Compliant.  Have you guys successfully deployed a wired solution using the NAC Agent ??  FYI, I have a wireless Cisco solution succesfully deployed.  It's the Wired part can't seem to figure it out.

Thanks for any suggestions !!

Tony

 

Tony,

I rolled out our ISE deployment almost 2 years ago and started off on the wired side first. Once we were able to stabilize our environment (after many patch upgrades on 1.1, upgrading to 1.2, Cisco BU guys doing a DB clean, many more "fun" stuff) we then rolled it out on the wireless side.

I have yet to fully deploy Posture Assessment due to a few quirky issues I've noticed with the NAC agent so for the most part I am just doing Dot1x authentication/authorization and MAB authentication/authorization. Although, the latest version of the NAC agent does seem more promising with regards to eliminating some of the quirky behavior that we've seen.

I am fairly confident that the order of the ACL, once an interface goes into a general "redirect" state whether that be for CWA or Posture Unknown, is rACL>dACL>pACL. For CWA, at least in my environment, I do not have much reason for placing anything else but a general "permit tcp any any eq www 443" in my rACL that is configured locally on the switch. I may have to add deny statements above this general permit statement but that would only be for something such as PC imaging which may communicate on port 80 or 443 which I am testing out now with the team that is responsible for doing PC imaging. For Posture Assessment it is a little bit of a different story, again at least for my environment, because I have to place deny statements for such things as IM & email because there is communication on ports 80 & 443 and if the deny statements are not placed in the rACL then you get certificate errors while the NAC agent is trying to evaluate the machine. The email & IM app are trying to communicate with their respective servers on port 443 and that traffic gets redirected to your PSN and your PSN responds with it's own certificate therefore creating a certificate pop-up message on the client machine. End users hate getting these certificate pop-ups while the NAC agent is running.

What specifically are you having issues with?

Hi Gary,

Thanks for your response, it's funny you started on the wired side.  I started on the wireless side and barely had any issues. The wired side is another beast.  For me anyways,

I'm using 3 Auth profile,

1- Machine Auth, I have a dACL created in ISE with permit DHCP, DNS, and all AD server.  Finally a deny all.

2 - User Auth, I have Web Authentication with Posture Discovery (this is the NAC Agent).  With this option, ISE forces me to add an ACL which needs to be created on the switch.  This is where I get stuck.

I have tried many flavours of ACL's, but presently I'm permitting DHCP, DNS, deny ISE nodes and finally permit all.

3- Finally User Auth, but this time with Posture compliant.  I use a pACL with Permit all.

Though, I have noticed by removing all ACL's and use only VLAN assignment, everything works.  As soon as I add any types of ACL's with Posture in the mix, I get inconsistent results. In some cases,  my workstation doesn't even have a valid IP address (with that I make sure all DHCP request goes through).

Contrary to your switch model, the 3560 doesn't allow me to verity the total ACL's that are applied to the port.  The command sh authentication sessions interface gig0/24 shows me the ACL by name but I can't tell if other ACL's are being appended or replaced.

Lately, I'm doing a lot of reading on this subject. As I mentioned before, your thread was most informative.
I wish Cisco would write a white paper that explains in detail every step of the process. (including how the ACL's are applied with posture assignment).

Thanks for your input !

Tony

 

 

I remember having to execute a "sh platform" command in order to see the tcam acl info on a 3800 series switch. I think this link might help you out for your 3500 series.http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3560/software/release/12-2_52_se/command/reference/3560cr/showplat.html#wp1008291

If I understand you correctly then I think your issue lies with #2 of your statement. The local rACL on your switch is just to define what traffic you want to redirect while the port is in a Posture Discovery state (I call this Posture Unknown state). So it looks like you're redirecting dhcp, dns, and all other traffic except for traffic destined to your PSNs. If that's the case...then that's not good. If you can, try this:

1. create a Posture rACL on your switch that just says "permit tcp any any eq www 443"

2. In ISE, in your Authz Posture Discovery/Unknown profile reference that new rACL that you created in step #1

3. In ISE, in your Authz Posture Discovery/Unknown profile reference a dACL that has your PSNs allowed and any other traffic that you want allowed through while the NAC agent is running on the client machine (dns, dhcp, etc)

 

All that rACL on the switch is doing is defining what traffic you want to redirect over to the PSNs while the interface is in the Posture Discovery/Unknown state. The only traffic that I think you need to redirect over to the PSNs is www & 443 traffic because when a user opens their browser that is typically one of the ports that gets used (unless their homepage is set to something unique) and this will redirect them to the ISE CPP (client provisioning) page for posture. The dACL is where you really want to define what traffic is truly allowed through during this stage. This allows you to centrally manage that allow/deny as opposed to having to place it in the rACL on every switch (almost 200 switches for me).

 

Hope that helps

 

Gary, the sh platform command looks interesting.  I'll set up my lab with your suggestion and I'll get back to you with the results.

Thanks for your help !!

 

Hi Gary,

My testing has yielded strange results.

I reboot the workstation, it goes through machine auth successfully, then it goes through User Auth and it's successful with Authentication but not with Authorization.  This is the weird part, without any config change, I shut and no shut the port. Now, the authorization is successful.
I'm including the screen shot of both messages.  Unless my config is incorrect, I might have some bug or compatibility issue.

Tony,

Sorry for the delayed response. Unfortunately, I don't have a good explanation as to why you're seeing that issue. Were you able to make any additional progress?

Hi Gary,

Unfortunately, this week I had other network issues so I didn't have a chance to do more testing. I might have to call Cisco on this one. I have spent lots of time trying to figure out what's going on.

But let me ask you something if you don't mind, when ISE sends a CoA to the client, does the client reauthenticate all over again without the user's knowledge ?

thx !

 

 

The way I've seen it in my environment:

1. For users that do not have Posture Assessment enabled

  • When a client reauthenticates they do not see anything. Everything is happening in the background (we use the native windows supplicant)

2. For users that do have Posture Assessment enabled

  • When a client reauthenticates they see the Cisco NAC agent pop up on their screen.

For most instances, I've set my reauthentication timer to 9-12hrs to cover a typical work shift.
 

Poonam Garg
Level 3
Level 3

In fact, dACL will replace the pre-authentication ACL/PACL you have configured on the switchport. Traffic must be first allowed via dACL then it will hit redirect ACL.

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: