You are right...So Chrome takes directly to the https, where in other browsers are not. I was about to wireshark, but then I figured out from the URL seen on the CP..
So that means if the user tries an HTTPS Site the very first time and if I dont have SSL Decrypt enabled, CP is of no use? Getting internal CA wont be an easy way for now. So Isn't there a way work around to serve the purpose with out SSL Decrypt pls?
Unfortunatly no : to be able to send broswer to a portal page,the firewall must rewrite HTTP answer ; it's obviously not possible when stream is encrypted with SSL, unless you enable SSL Decryption which allows PA to see real clear text traffic.
Also, SSL Decryption has many fallbacks and problems so I currently disabled it on Google services because of incompatibilities ; but it's achievable with with a lot of work.
I suggest you start playing with User Agent (reads Windows logon events in DomainController) or GlobalProtect Portal .
Hmm.. I get that now. Thanks.
Could be silly, but I am wondering if I could prompt the 'unknown' user with a URL Category blocked page (for any site he visits as long as he is unknown), I could atleast customize the blocked page to ask the to click on an http link there where he is then taken to CP, where he athenticates and then things work they way we wanted...I am yet to go through the various rule bases processing flow...But does this make any sense to you?
When visiting SSL (HTTPS) you can only 'cut' connection if you don't decrypt it, you cannot provide nice warning/error message.
If you are using Windows accounts for login and don't have many remote offices, UserAgent is very quick to setup and you can forget CP forever.
Yeah, I see that too. I kept a security policy on the top saying ALLOW every thing from any to any from 'unknown' user but with a URL Profile to Block ALL Categories. Now it seems that if I open chrome and access https://gmail, I cant access it, but NOR there is CP popping up. I was thinking since the traffic is HTTPS, captive portal is skipped and hence URL blocked might get imposed (even if its HTTPS, I believe it should still categorise it as 'Unknown' URL Category from the name found on the certificate name) with the blocked page notification. How ever session doesn't progress and I don't seem to get a URL Category blocked page either...so..!!!!
I am on mac environment majorly and hence userid stuffs isn't doing so great for me. Another purpose is to make sure 'bad' external consultants do not misuse wired ethernet ports too.
URL category won't be unknown : it reads URL hostname (not real url which is encrypted) from certificate itself that passes trough, so it will see *.google.com.
If you are using Macs, then consider GlobalProtect Portal with agents installed on corporate computers.
Looking at the URL Logs, things are working the way expected. But I think, as you said, since https response cant be rewritten (unless ssl decrypt) we cant force a block page..right?
I thought about GP earlier, but deploying on corporate and not deploying on consultants will make it hard to manage in over all...So I think will have to live with it for now, by announcing to login to our company http website (which then takes to CP :smileyhappy:) who ever have internet issues , probably ...!!
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the Live Community as a whole!
The Live Community thanks you for your participation!