AnyConnect and no policy server detected

[dgaikwad]

Hi Experts,

Test environment:

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

[howon]

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.

[dgaikwad]

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.

[howon]

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).

[paul]

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 (72.163.1.80) 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.

[dgaikwad]

I have observed this behavior, when I type in any of the website or even IP address like 1.1.1.1

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.

[paul]

You are going to have a host of problems if you try to use that ACL in production:



-Windows 10 and other OSs try to do portal detection when connecting . They may pop-up the client provisioning page before the client postures causing all sorts of confusion for the end user. Users will start clicking and trying to reinstall Any Connect or call the help desk asking what the client provisioning page is.



-Outlook will try to connect as soon as they connect and the user will get a cert warning in Outlook because of the redirection. All sort of fun will happen with that one.



As I have stated before on the forums the redirect ACL should only be used for posture module discovery and the only thing you need to redirect is port 80 enroll.cisco.com and/or port 80 to the default gateway. If you want to restrict traffic pre-posture you can use a DACL (not sure if the HP switches support that).

[dgaikwad]

I did some more testing with the user and his test endpoint and here are the observations:

1. When the user connects, the ACL and redirection URL are pushed to switch from ISE

2.  Now user opens a browser and enters times.com. nothing happens, enters, 1.1.1.1 nothing happens

3. So, I manually copy and paste the above URL in the browser nothing happens

4. I replace the DNS name of the ISE server with IP address, voila! I am presented with the redirection page!

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?

[Jason Kunst]

Sounds like possibly you have a DNS issue not able to resolve the ISE PSN information. Can you resolve the ISE node from the client network?

[dgaikwad]

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.

[dgaikwad]

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.

[sajid231088]

Hi,

Please try to change Anyconnect angent/ compliance module.

Hope it would work.

Regards
Sajid Baig

[dgaikwad]

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.

[paul]

You really don't want users installing AnyConnect from the client provisioning portal. It is fine during testing, but you should be pushing it out with SCCM or some other software distribution tool. If you allow the provisioning portal to come up, users that already have AnyConnect and Posture Module installed may try to install it again. The OS portal detection may automatically kick up the client provisioning portal. You should only try to redirect the calls necessary for posture discovery.

[dgaikwad]

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.