ProxySG Transparent - Google Chrome

[Jose Castro]

Over the past year, we have several users get errors from Google Chrome Browser when trying to access certain sites. The name of the Virtual URL is 'chi-bcoat' in transparent mode which Reverse Proxies to https://chi-bcoat:4443. A certificate is installed for the Reverse Proxy Service. Not everyone has this issue, as a matter of fact, there is only a handful out of about 3000 clients.



If the user is bypassed from Proxy, everything works. So this is not Firewall. This doesn't not happen in IE either. 

Doing a trace log now but initially was not able to find any clues... Looking or chatter on Forums and found a couple of things:

Possible bug in Chrome's HSTS - help me confirm?

Google		remove preview
Possible bug in Chrome's HSTS - help me confirm? Our proxy doesn't issue Strict-transport-security headers, so I don't understand how it could have found its way into chrome's HSTS cache. I'm unable to replicate the problem, so I don't know under what conditions Chrome will add that host to HSTS. View this on Google >

I hope to have logs sometime in the next day or two after testing specifics sites that break when trying to connect.

[Slava]

Hello Jose, 

It sounds like these are isolated cases , and if you can reproduce this issue on demand that is perfect as if you really want to get to the bottom of this , here is what i would recommend.

1. Gather proxy packet capture and policy traces while accessing the same web site from a user that does not have any issue.
2. Gather proxy packet capture and policy traces while accessing the same web site from a user that has the issue.

You can also try disabling first the Proxy Authentication for that source client IP , then SSL Decryption and see what of solved the issue, and that should at list give you a hint on where the issue issue.
The packet capture filter should include the source client IP and the destination web site FQDN and the internal .
The Policy trace can be configured based on the source IP of the client.

Comparing the gathered date should assist you in solving this mystery.

Slava

[Jose Castro]

Slaava - 

I worked w/ the end user on Friday and prepped the Packet Capture and Trace Logs. Prior to testing, I also renamed his Google Chrome default Profile Folder to start net new AppData\Local\Google\Chrome\User Data\Default as I needed to get his machine working and wanted to try to isolate application (chrome) in this case. Turns out when doing this, all the sites worked on the new profile (new Default folder is created on launch) so the issue appeared related to this. So we know this much. I did check the Internet Connection Settings everything looked normal. I was between a rock and a hard place as the end user has been inoperable all week and patience was going thin. I also have a copy of the 'Default' Chrome profile that was causing issue so am going to try to reproduce.

[Slava]

Hello Jose, 

Thank you for the update and for sharing your findings, it ha been a while since i did hear of a possible rogue browser profile, but it looks like that is what it is in this case.
Good luck with attempting to reproduce it, if not to much to ask share you final findings.

Thank you in advance.
Slava

[Henkle Rios]

Thanks for the update and quick reply. I'll be sure to keep an eye on this thread. Looking for the same issue. Bumped into your thread. Thanks for creating it. Looking forward for solution.