Captive Portal and HTTPS

[Pedro_Roure]

Hi,

I created a rule to redirect the traffic destined to http e https ports from a specific network segment to the captive portal (identity awareness blade). The rule was created using an Acess Role as source (the access role was configured only with the specific network segment).

The redirect to the captive portal works perfectly when the user access a HTTP (clear-text) site, but when the users access an HTTPS (encrypted) site, the redirect does not work (browser tries to connect until timeout). Is there any way to the redirect to the captive portal works with HTTPS sites? 

PS: The HTTPS Inspection is enabled for all traffic originated from the specific network segment mentioned above.

[PhoneBoy]

This may be because the browser is ignoring the redirect we send it.
See: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

[mmolnar]

As per the guide it says:

Note - You can only redirect HTTP traffic to the Captive Portal.

https://sc1.checkpoint.com/documents/R80.20_GA/WebAdminGuides/EN/CP_R80.20_IdentityAwareness_AdminGu...

While other CP sources seem to imply otherwise, like rule #4 of the sample Identity Awareness Rules at:

https://sc1.checkpoint.com/documents/R80.30/WebAdminGuides/EN/CP_R80.30_NextGenSecurityGateway_Guide...

Are we able to redirect or not?

[PhoneBoy]

It is impossible to issue a redirect for HTTPS traffic unless HTTPS Inspection is enabled.
Assuming the traffic is subject to HTTPS Inspection then you can issue a redirect.

[mmolnar]

HTTPS inspection is enabled, but the traffic is not matching the rule. Regular HTTP will get redirected.

Is it something in the HTTPS settings? I have tried using network object and access role based on network.

[PhoneBoy]

The traffic in question must match an HTTPS Inspection rule.
Does it?

[mmolnar]

Looks like its due to sk162856.

The traffic can be matched to the redirtection rule on first packet only if all of the rules above the redirection rules could be matched from the packet source and destiation IPs and ports and protocols.

Ideally we want the redirect rule to be at the bottom of the rulebase as it would be a fallback method to gain the user's identity, so this may not even work for us.

What sort of rule would we need to create that matches a packet and the firewall continues to evaluate to the next rule?

[PhoneBoy]

Once a packet matches a specific rule in a layer, no further evaluation is done on rules in that layer.
If you want additional rules to be evaluated, they would need to be in another ordered layer after the existing one.

[mmolnar]

I tested via both ordered and inline layer. Traffic is matching the very top rule and is sent to the ordered layer. The very first rule in the ordered layer is the redirect rule.

I believe this fulfills the requirement of SK162856 but the redirection still not happening with HTTPS.

Logs just show traffic matching the accept rule that sends it to the orderred layer but does not show it matching any rule in that ordered layer. The normal webpage opens but not the redirect. Capture shows that this traffic is permitted through to the client without any attempt to redirect.


Looking back at the guide the rules uses HTTPS_PROXY and testing with that traffic it hits the redirect rule. Outside of the SK I am not finding any reference to making HTTPS redirection work.

So, the question still stands...

[PhoneBoy · Accepted solution]

Now that I've read sk162856, I think I understand what the issue is.

Some rules can be matched on the first packet.
When a layer only has Firewall blade active in it, every HTTP/HTTPS rule matches on first packet.
According to sk162856, a redirect will not work in this case.

Rules that involve App Control applications require more than one packet to fully match (e.g. to differentiate accessing Google from Dropbox).
If there is some other rule that can potentially apply to the connection in earlier rules from your redirect rule, then that will allow a redirect to work as well.
This obviously requires Application Control to be enabled in the relevant layer.

Without knowing precisely how your layers/rules are constructed, I can't tell you precisely how to fix this in your case.
But, if you're taking an ordered layer approach, then the redirect rule should appear in one of the last layers where, in a previous layer, the packet was matched by an App Control rule.
Hope that makes sense.

[mmolnar]

Thank you! App control was the key.

Works like a champ.

[jederson]

Hello, could you explain how the rules went? I couldn't get it to work.

[DongYuan_Wu1]

share the rule with you