Controllerless Networks

Hi, 

we are using IAP enviroment for guest access with auth string andaccept term condition. We would like to force  client to use HTTPs for communication between client and IAP. Unfortunatelly when I will setup external CP profile with port 443 and also HTTPs, we are not able after pressing accept term and conditions to move from preauth role to auth role. We are always being redirected to CP page after clicking Accept buttom. 

According to documentation, HTTPs is available for radius user authentication. Does it mean that if we are using just auth-string, we are not able to use HTTPs?

THX

Follow the steps on this video, they are very helpfull.

https://www.youtube.com/watch?v=LvK68t4dTGs

I like this question. I never realized before, but in order for the auth string to work, the IAP has to 'see' the auth string in the traffic coming back from the web server. If that is HTTPS, the string is hidden in the encryption and it is impossible to read it.

So, you are correct: auth string only works on HTTP pages.

Edit: if you configure Authentication Text in the WebUI, the SSL knob disappears which once more confirms this.

You can configure RADIUS authentication to the internal user database for a similar 'click to accept' experience. This does require a public trusted certificate on your IAPs to prevent the warning pages. Given the point that browsers are more and more displaying ununcrypted HTTP pages as insecure, it may be best to move to RADIUS anyway.

Hi Robers,

yes, right, as soon as you are using HTTPs IAP is not reading "Auth String". But I can't say, that IAP is not able to read it, because all http/https traffic is proxied by IAP itself, so there is no direct packet flow between client and external cp webserver. Client subnet is not even routable on the network where is located external webserver.  So that's mean that all traffic needs to be proxied by IAP itself and that's mean that IAP should be able to see all kind of traffic, HTTP or HTTPS.

Correct me if I am wrong.

THX

When proxying HTTPS encrypted traffic, the proxy cannot look inside the encryption. It forwards the traffic as is' including the encryption. So, yes it can see the encrypted traffic but not what is inside the encryption which makes the auth string does not work.

Some firewalls and web security proxies have a feature to break the SSL session open (ssl inspection) to inspect what is inside the encryption, which is a non-trivial process that requires installation of a new certificate authority in your clients and is (far) out of scope for an Instant AP.