This community is for technical, feature, configuration and deployment questions.
For production deployment issues, please contact the TAC! We will not comment or assist with your TAC case in these forums.
Please see How to Ask the Community for Help for other best practices.
ISE 2.3 patch 3
HP Comware switch: Version 7.1.070, Release 3208P03
I am seeing this very weird behavior with AnyConnect.
We are using an ACL for posture redirection, so here when I have these two statements:
rule 135 deny tcp destination-port eq 443
rule 140 deny tcp destination-port eq www
AnyConnect says that, its failed to launch downloader
But when I change them to:
rule 135 permit tcp destination-port eq 443
rule 140 permit tcp destination-port eq www
AnyConnect says, no policy server detected
Any idea why this could be happening?
Following is the complete ACL:
[NAC-5130-2]display acl 3003
Advanced IPv4 ACL 3003, 29 rules,
ACL's step is 5, start ID is 0
rule 0 permit ip destination <ISE Server> 0
rule 5 permit udp destination-port eq dns
rule 10 permit udp source-port eq bootpc destination-port eq bootps
rule 15 permit udp source-port eq bootps destination-port eq bootpc
rule 20 permit tcp destination-port eq 2967
rule 25 permit tcp source-port eq 2967
rule 30 permit tcp destination-port eq 7070
rule 35 permit tcp source-port eq 7070
rule 40 permit ip destination <AV Server> 0
rule 45 permit tcp destination <AV Server> 0 destination-port eq 443
rule 50 permit tcp destination <AV Server> 0 destination-port eq www
rule 55 permit tcp destination <AV Server> 0 destination-port eq 443
rule 60 permit tcp destination <AV Server> 0 destination-port eq www
rule 65 permit tcp destination <AV Server> destination-port eq 443
rule 70 permit tcp destination <AV Server> destination-port eq www
rule 75 permit tcp destination <SCCM Server> 0 destination-port eq 443
rule 80 permit tcp destination <SCCM Server> 0 destination-port eq www
rule 85 permit tcp destination <SCCM Server> 0 destination-port eq 443
rule 90 permit tcp destination <SCCM Server> 0 destination-port eq www
rule 95 permit tcp destination <SCCM Server> 0 destination-port eq 443
rule 100 permit tcp destination <SCCM Server> 0 destination-port eq www
rule 105 permit tcp destination <SCCM Server> 0 destination-port eq 443
rule 110 permit tcp destination <SCCM Server> 0 destination-port eq www
rule 115 permit tcp destination <SCCM Server> 0 destination-port eq 443
rule 120 permit tcp destination <SCCM Server> 0 destination-port eq www
rule 125 permit tcp destination <SCCM Server> 0 destination-port eq 443
rule 130 permit tcp destination <SCCM Server> 0 destination-port eq www
rule 135 deny tcp destination-port eq www
rule 140 deny tcp destination-port eq 443
Solved! Go to Solution.
I suggest using AnyConnect DART for more details. But, looks like denying 80 & 443 is the right config based on your result. You may be getting failed to launch downloader error if you are not getting redirected to the client provisioning portal so make sure when the deny is hit the endpoint can get to the portal. You can test this by opening up a web browser to confirm that browser is getting redirected to the client provisioning portal. Another cause may be that you don't have the client provisioning policy with AnyConnect defined for the client OS.
There is a client provisioning policy defined for all version of this OS this machine is running.
I see that this client is reported as Microsoft-Workstation, so that is normal, right? If I wanted to check what OS this client is running, where I can I check that?
Also, I will run the DART and see what I get from it output.
Do you get redirected with the browser? I would confirm redirect to the client provisioning portal first before any further troubleshooting. This can happen in two ways if you are leveraging HP switch capability. Either you can send down URL-Redirect string via RADIUS (Most of Cisco devices supports this) or you have to statically define the URL string on the HP switch web auth portal settings (Most of 3rd party devices falls in to this category).
Your ACL is way to big unless you are planning to actually use the client provisioning portal to install the AnyConnect software (I wouldn't recommend it).
The only thing you need to redirect is port 80 to enroll.cisco.com (22.214.171.124) or port 80 to the default gateway. On Cisco devices I use the 10.0.0.1 0.255.255.0 masking to get the default gateway, but enroll.cisco.com works. As Howan suggested you can validate redirection is working by pulling up a web browser and going to http://enroll.cisco.com.
I have observed this behavior, when I type in any of the website or even IP address like 126.96.36.199
There is nothing on the browser, the browser will just sit there...
But, if enter the IP address or the URL to ISE server, I am presented with the redirection page!
Is this something with the switch? Is the switch not able to intercept any of the DNS requests that I am sending from the browser?
The reason ACL is so big, is because that is the we will be using in the production when we go live.
We are not planning on using the redirection for client provisioning, but would like to keep this function in those cases if an endpoint does not have a client or posture module, then should be able to download and connect to the corporate network.
I did some more testing with the user and his test endpoint and here are the observations:
Now user opens a browser and enters times.com. nothing happens, enters, 188.8.131.52 nothing happens
So, I manually copy and paste the above URL in the browser nothing happens
Now the question is that, is the switch not able to intercept the requests that are being sent from the browser to the outer world?
I am not sure if that is an issue over that site, since from my site I am able to resolve to that ISE address.
I will test it from his site, using another computer that is not connected to a dot1x port.
It seems that it was not a DNS issue after-all, and something different. Here are some of my observations regarding the issue:
White testing I observed something really peculiar, ISE we define the attribute to carry the redirection URL in the network device profile, here:
When I use attribute, H3C-Web-URL, I see that the URL does get pushed to the switch in the authorization URL part, but then endpoints is just not able to communicate with DNS at all.
But, if I enter the URL directly in the browser, its take me to login page from Cisco without any issues. The other side effect of this is the posture scan stops, working as AnyConnect client is unable to find ISE server.
But, I remove the attribute H3C-Web-URL and use, HPE-Captive-Portal-URL instead, there is no URL pushed for redirection. But, posture works just fine.
I am not sure about this behavior, if its from ISE, the NAD profile or if the switch stops processing any DNS requests when it sees the URL pushed.
While testing, we tweaked the posture redirect ACL:
rule 0 permit udp destination-port eq bootps
rule 5 permit udp destination-port eq bootpc
rule 10 permit udp destination-port eq dns
rule 15 permit ip destination 10.24.213.108 0
Post this change I was able to get to the redirection page fine.
But, then I hit another, the user goes through the detecting AnyConnect and then get to a page where it asks, to download the AnyConnect posture module.
Clicking the download, like I just get a blank page instead of downloading the agent.
I am starting a new thread to work on it.
Yes, I do agree with you! But, the client here is not ready for that approach, there is need to for the cases where, users do not have it installed or if the user is working from remote location where they are not able to contact any of our admins.
So, that is why we are trying to get this working on HP switch as well, as there are few of the sites where we have like hundreds of HP switches.