Captive portal - strange behavior in Chrome

[Ilya_Avetisyan]

Hello All,

Problems with redirection to Captive Portal (R80.20) when I'm trying to open some website. In IE everything works fine. In Chrome there is no automatic redirection if I use website address. But If I enter website's IP then captive portal opens immidiately. I tried to disable 'Use a web service to help resolve navigation errors' option in Chrome but no luck. In logs I see tons of dropped connections to Google networks according to Cleanup rule. For me it looks like Chrome tries to check website address somewhere (may be using some online service) before opening it but due to Internet access absence it cannot do that. I also tried to turn off other options in Chrome like prediction service, etc., but no luck.

The Captive Portal itself is accessible by its name and if I open it directly I able to get Internet access of course.

[PhoneBoy]

Just to clarify, it’s when Chrome tries to access the Captive Portal using FQDN versus IP?

[Ilya_Avetisyan]

Not exactly. For example, I'm trying to open https://ixbt.com website. The Captive Portal should appear in Chrome but it doesn't and only an indicator is rotating at browser's tab. But if I enter website's IP (91.208.42.67) the Captive Portal appears immidiately and I able to enter my credentials to get access to the Internet.

As I wrote the Captive Portal itself is accessible if I enter its address (https://fw-cluster.my_organization_domain_blah_blah/connect). The problem is that there is no automatic redirection. And again, IE doesn't have such problems and everything is working there.

[PhoneBoy]

It's not possible to inject a redirect on an HTTPS site without enabling HTTPS Inspection.
In which case, what you're seeing is expected behavior.

[Ilya_Avetisyan]

I was thinking about HTTPS inspection because it's not activated currently but what I don't understand is that it's working in IE...

[Timothy_Hall]

It is possible that Chrome is trying to protect you from yourself, and probably knows who the proper CA is for popular sites like ixbt.com, and it ain't whatever CA the firewall is trying to use to shovel the UserCheck.  So Chrome is essentially detecting a man-in-the-middle attack and not letting you proceed to ixbt.com.  When you do it by IP address, Chrome has no idea what the site name is, therefore no idea who the proper CA is, and lets you proceed.  I think the term for this is HTTPS Pinning?

Internet Explorer is far too arrogant to concern itself with trivial matters such as the security of your communications and just lets you proceed.

[Ilya_Avetisyan]

Hello Guys,

I installed test CheckPoint environment. The Captive Portal appears without problems when HTTPS inspection is on. That was so simply... Will try same on Monday on production system and inform about results.

[Ilya_Avetisyan]

Hello again,

After enabling HTTPS inspection on prod. system everything started to work. Moreover, it's working now even when HTTPS inspection is off (which is totally confusing me)

Anyway thanks to all for info and recommendations.