cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3399
Views
5
Helpful
9
Replies

ISE posture redirect to being attempted

joeharb
Level 5
Level 5

We are deploying 802.1X but are having issues with pasture url redirect. The client (windows) never attempts the redirect. Session for client on switch has correct dacl and url address. We are able to browse to the url from client and get page. Switch has no layer 3 (all clans trunked to core switches), we are using out of band mgmt and this works fine for 802.1X.

 

i have enabled ip http server for both 80 and 443 on the switch 

 

Every things appears to be configured appropriately 

 

Any suggestions?

 

Joe

1 Accepted Solution

Accepted Solutions

Yep that is correct. You need to add 80 and maybe 443. Depending on the browser the client is using and if it supports HSTS the call to http://cpp.cisweb.com/ may get automatically changed to https://cpp.cisweb.com/. Then you may get an SSL warning because the cert on your Admin side doesn't contain cpp.cisweb.com. Basically what I am saying is "good luck" :)



Are these users corporate users? If so why aren't you using a tool like SCCM to push out the posture module and the posture module config? I try to avoid using the client provisioning portal if at all possible.


View solution in original post

9 Replies 9

hslai
Cisco Employee
Cisco Employee

Please review ISE Posture Style Comparison for Pre and Post 2.2 - Cisco; especially its mention:

  • In the cases when NAD does not have a local IP address in client subnet SYN-ACK is sent with NAD routing table (Over management interface usually). In this scenario packet is routed over L3 infrastructure and should be routed back towards the client by a L3 upstream device. If L3 device is a stateful firewall, additional exception needs to be given for such asymetric routing.

I would suggest you to try the ISE 2.2. new feature to perform ISE posture without relying on NAD to trigger redirects.

I am attempting the method without any redirection.  I have updated the Posture portal with a FQDN of cpp.csiweb.com.  On the test device I have a host entry for that FQDN pointing to ISE PSN.  The portal is set for port 8443, I have allowed that in the DACL and removed the Redirect ACL and Portal Site Reference.  This is where I am confused...should the Authorization policy reference the Portal and Posture URL without the redirect?  As it is now on the test device I can not browse to https://cpp.csiweb.com:8443, a ping results in the correct address resolution.

Please advise,

 

Thanks

 

Joe

 

The results should just be an Accept with any relevant DACL you want for the posture unknown state.  You should by calling up http://cpp.csiweb.com in your browser not https://cpp.csiweb.com:8443/.

 

Refer to this link:

 

https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine-22/210523-ISE-posture-style-comparison-for-pre-and.html#anc9

 

It explains the process in great detail.

That is document I am following, the DACL they utilize for no Redirect doesn't allow port 80 traffic, only port 8443.  Please see attachment.  Our Client port is setup on port 8443.  I would expect that with the DACL in the example you would be blocked going to http://cpp.csiweb.com?

 

Our ISE nodes are behind a firewall, we currently allow 8443 traffic to them for this purpose, if it need to be 80 we can adjust, but I am confused with the DACL used.

 

Thanks,

 

Joe

You can't call to 8443 directly because you are not correctly specifying the portal ID. The portal short cuts can only be used when you connect to port 80/443 of the ISE PSN. So you have two choices:

1) Click on the portal test URL for the CPP portal and substitute in the cpp.csiweb.com as the FQDN but keep the 8443 and the full path to the portal.

2) Allow 80/443 to the PSNs and have the clients just refer to cpp.cisweb.com in their browser and let ISE redirect the client to the correct full string.

So your choices bowl down to looking something like this:

https://cpp.cisweb.com:8443/portal/PortalSetup.action?portal=62d48732-e1d1-11e8-bb0f-4eb52ded6bc5

or:

http://cpp.cisweb.com/

Substitute the correct portal ID if you use the full URL.





Thanks for the clarification, I assume that the DACL will have to be modified to allow for port 80 traffic as well as the 8443 traffic?

 

Thanks,

 

Joe

Yep that is correct. You need to add 80 and maybe 443. Depending on the browser the client is using and if it supports HSTS the call to http://cpp.cisweb.com/ may get automatically changed to https://cpp.cisweb.com/. Then you may get an SSL warning because the cert on your Admin side doesn't contain cpp.cisweb.com. Basically what I am saying is "good luck" :)



Are these users corporate users? If so why aren't you using a tool like SCCM to push out the posture module and the posture module config? I try to avoid using the client provisioning portal if at all possible.


@paul you mentioned the following two options for accessing the CPP portal directly via fqdn: full url path or let ISE redirect to full path, however I am a bit confused.

 

for example I have mydevices portal configured with a FQDN and my clients can access this portal directly from their browser by going to mydevices.company.com, there is no need to enter full path to portal or have ISE redirect. So why are clients unable to access the CPP with the FQDN?

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: