Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Pedro_Roure
Explorer
Jump to solution

Captive Portal and HTTPS

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.

 

0 Kudos
1 Solution

Accepted Solutions
PhoneBoy
Admin
Admin
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.

View solution in original post

0 Kudos
12 Replies
PhoneBoy
Admin
Admin
This may be because the browser is ignoring the redirect we send it.
See: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...
0 Kudos
mmolnar
Participant

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?

0 Kudos
PhoneBoy
Admin
Admin
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.
0 Kudos
mmolnar
Participant
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.
0 Kudos
PhoneBoy
Admin
Admin
The traffic in question must match an HTTPS Inspection rule.
Does it?
0 Kudos
mmolnar
Participant
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?
0 Kudos
PhoneBoy
Admin
Admin
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.
0 Kudos
mmolnar
Participant
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...
0 Kudos
PhoneBoy
Admin
Admin
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.
0 Kudos
mmolnar
Participant
Thank you! App control was the key.

Works like a champ.
jederson
Explorer
Hello, could you explain how the rules went? I couldn't get it to work.
0 Kudos
DongYuan_Wu1
Employee
Employee

share the rule with you

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events