topic Hello Gary,You might be aware in Network Access Control

Cisco ISE - CWA Redirect

Gary Higgs — Mon, 11 Mar 2019 04:46:10 GMT

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.

Hello Gary,You might be aware

Poonam Garg — Thu, 05 Jun 2014 06:02:25 GMT

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

Gary Higgs — Fri, 06 Jun 2014 03:16:56 GMT

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

Poonam Garg — Fri, 06 Jun 2014 11:51:09 GMT

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)

In fact, dACL will replace

Poonam Garg — Fri, 06 Jun 2014 12:24:41 GMT

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.

I have always seen it rebuild

Gary Higgs — Fri, 06 Jun 2014 12:30:02 GMT

I have always seen it rebuild the ACL as rACL>dACL>pACL while the switchport is in CWA state.

This goes back to the heart

Gary Higgs — Fri, 06 Jun 2014 12:34:07 GMT

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.

If you say rACL is first hit

Poonam Garg — Fri, 06 Jun 2014 12:36:39 GMT

If you say rACL is first hit then what is the use of dACL on switch port

The rACL is what provides the

Gary Higgs — Fri, 06 Jun 2014 12:43:31 GMT

The rACL is what provides the redirect statements in the ACL. Technically, you could put everything in your rACL as deny statements but it doesn't scale well because you have to place it on every switch in your environment whereas if you put it in ISE then it's centrally located/configured. Please test the process out if you have the chance, I promise you this is how it works & why I'm asking this question.

Thanks Gary, I will

Poonam Garg — Fri, 06 Jun 2014 12:51:31 GMT

Thanks Gary, I will definitely test this out. It was a great discussion. I really appreciate your way of clarifying things.

Thank you for the responses.

Gary Higgs — Fri, 06 Jun 2014 13:19:17 GMT

Thank you for the responses. Our discussion has brought up two more questions for me that I plan on testing when I get a chance.

1. Why do I even need the pACL if I'm only saying "permit ip any any".

2. Is it possible to place my redirect statements at the beginning of my ISE dACL & eliminating it off the switch config completely. This will allow me to centrally control the ACL via ISE.

Prior to software versions 12

Poonam Garg — Fri, 06 Jun 2014 13:40:00 GMT

Prior to software versions 12.2(55)SE on DSBU switches, a port ACL is required for dynamic ACLs from a RADIUS AAA server to be applied. Failure to have a default ACL will result in assigned dACLs being ignored by the switch. With 12.2(55)SE a default ACL will be automatically generated and applied. An ACL must be configured to prepend dACLs from AAA server.

Hi Gary,Please find the

Poonam Garg — Fri, 06 Jun 2014 19:32:08 GMT

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.

The slide doesn't state which

Gary Higgs — Fri, 06 Jun 2014 19:54:05 GMT

The slide doesn't state which ACL gets hit first but yes I agree that the static pACL is the first ACL to go into effect & I've stated that before. I don't know how else to explain this because part of my frustration is that the documentation all along has been inaccurate/inadequate & it's created a false understanding of what is actually happening at each stage. Again, I promise that when a port first goes live the pACL is used & when the port goes into "redirect/CWA" state a new ACL gets applied that consists of the rACL>dACL>pACL.

Take a windows laptop, disable dot1x on it, log into your switch with another laptop and then plug your first laptop into a switchport & watch the process. The pACL will be used until dot1x fails & when the port transitions to the CWA state a new ACL will be applied to that port & it will consist of the rACL statements, then the dACL statements, & then the original pACL statements.

I accidentally clicked the

Gary Higgs — Fri, 06 Jun 2014 20:47:08 GMT

I accidentally clicked the "correct answer" button when trying to click on the attachment. Not sure how to undo the mistake.

Poonam,Attached is a word

Gary Higgs — Tue, 10 Jun 2014 16:23:27 GMT

Poonam,

Attached is a word document showing the outputs from my 6500 switch while a switchport is transitioning from dot1x over to mab and in "CWA" state. I had to omit several items (IPs, etc) but I tried to provide some explanation. Please let me know your thoughts.

Gary,I have not worked on

Poonam Garg — Wed, 11 Jun 2014 07:00:11 GMT

Gary,

I have not worked on 6500 switches. Also never used this tcam command. I will study about how tcam display interface acl hit and will let you know about my analysis as in some document I saw the first entry is deny ip any any in the output and still a hit in other ace. See the link.

Hi Gary / Poonam,I find the

tonyp8581 — Wed, 11 Jun 2014 20:31:35 GMT

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

Gary Higgs — Wed, 11 Jun 2014 21:52:04 GMT

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

tonyp8581 — Thu, 12 Jun 2014 15:26:29 GMT

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