Avoid posture portal

[Antonio Macia]

Hi,

After a BYOD device has correctly enrolled and installed AnyConnect successfully, every time the device connects back to the wireless SSID, a new browser opens and he gets redirected to the BYOD portal until AnyConnect finishes the system scan. I understand that during the initial connection, ISE has no posture information but, is there any way to avoid this browser to pop-up while AnyConnect is analyzing the system?

Regards.

[hslai · Accepted solution]

We may adjust the ACL or DACL to avoid such.

• Close mode: Need to permit traffic to avoid Network Location Awareness (NLA) detection.
• Open mode: Only permit URL redirect on a small set of IP ranges -- default gateway, discovery host, enroll.cisco.com, etc.

[Antonio Macia]

Hello hslai,

Sorry, but I don't understand how this can help. Per my understanding, the portal is triggered because there is a short time slot were ISE doesn't have any posture information about the endpoint (unknown) until AnyConnect finishes the system analysis, don't see how limiting the range of IPs can avoid this. Can you elaborate more? Thanks.

Regards

[Antonio Macia]

Hello hslai,

Sorry, but I don't understand how this can help. Per my understanding, the portal is triggered because there is a short time slot were ISE doesn't have any posture information about the endpoint (unknown) until AnyConnect finishes the system analysis, don't see how limiting the range of IPs can avoid this. Can you elaborate more? Thanks.

Regards

[paul]

Let me elaborate on what Hsing is saying.  I have posted on this several time.  If you aren't using the client provisioning portal to install AnyConnect and the posture module for you corporate devices (in my opinion you shouldn't use it), then you don't need to redirect anything to the portal.  The only reason for the URL redirect in this case is to assist the posture module in the discovery process to discover the correct PSN to report posture to.  This is our standard redirect ACL on the switch:

ip access-list extended POSTURE-REDIRECT
permit tcp any 10.0.0.1 0.255.255.0 eq 80
permit tcp any host 72.163.1.80 eq 80
deny ip any any

The first line intercept the default gateway call the posture module does (assuming you are on a 10.x.x.x network and DG is .1).  The second line is enroll.cisco.com.

If you need to restrict access in the preposture state use a DACL. 

[Antonio Macia]

Thank you Paul,

In our case, since it is a fully BYOD scenario, we use the CPP for NSP and AC installation, that's why ISE redirects to the portal when posture unknown is received. How this affects on your proposal?

Regards.

[paul · Accepted solution]

If the user is correctly provisioned for BYOD and doing correct wireless authentication using the data provisioned during BYOD then you shouldn't need to redirect them to the CPP portal.  They are already registered.  Just put an ACL for posture discovery only.

[Antonio Macia]

Thank you Paul,

The ACL worked and there are no more browser pop-ups. 

However, now during the initial BYOD process, the browser does not automatically pop up for AnyConnect installation.

I know you mentioned to distinguish between devices that already went through the BYOD process and on-boarding devices, however, can't find a condition that could help differentiating between both since both authenticate in the same way and the only difference is the posture status?

I can only come up with telling on-boarding user to manually open a browser type enroll.cisco.com to trigger the CPP during the on-boarding.

Any other ideas?

[paul]

It doesn't sound like you are doing a true BYOD flow. If you were doing a true BYOD flow through the BYOD portal process you would key in on the Identity Group you have set in the BYOD portal (RegisteredDevices is the default) or you would be changing the authentication scheme post registration (i.e. going from PEAP to EAP-TLS). Sounds like you are just doing client provisioning to install AC and Posture Module. Is that true?

[Antonio Macia]

Let me summarize my authorization rules:

* First rule for on-boarding (bottom one).  Catches PEAP authenticated users in the on-boarding SSID and applies the authorization profile that redirects them to the BYOD portal where the users register their devices and the corporate SSID that uses EAP-TLS gets automatically configured by the NSP.

* Second rule for compliance unknown (upper): At this stage the user is connected to the corp SSID, the device belongs to the RegisteredDevices group but, because it does not have AnyConnect installed compliance is unknown --> the provisioning portal kicks-in for AC installation.

* Third rule for non-compliant: Same than above but the posture status equals to "NonCompliant"

* Fourth rule for compliant (top): Posture equals to "Compliant"

Cannot distinguish between rule two and three because in both cases the devices already belong to the RegisteredDevices group. I'm I missing anything?

Thanks.

[paul]

It has been a while since I did BYOD flow but can't you install NSP and AnyConnect Posture in the same steup?

[Antonio Macia]

Hello,

I will finally use the restricted ACL and instruct the user to manually open a browser for downloading the AC client. With this approach we avoid later browser pop-ups which are annoying.

Thanks for your time.