topic Re: Using an application object breaks the automatic redirection to the captive portal in Firewall and Security Management

Using an application object breaks the automatic redirection to the captive portal

osef — Wed, 26 May 2021 11:43:46 GMT

Hello,

I'm facing an issue with the firewall's captive portal

This is my rules

Everything works : unauthenticated users are automatically redirected to the captive portal when they try to surf on the Internet

But if I had a rule like this :

Webex / Teams / Zoom are working fine but the automatic redirection to the captive portal stop working and the user's packets are dropped by the rule 69.141...

The log of a dropped packet

Id: b161f674-b77b-d1ed-60ae-319e00000012
Marker: @A@@B@1622024052@C@1200369
Log Server Origin: 10.3.11.19
Time: 2021-05-26T11:31:43Z
Interface Direction: outbound
Interface Name: eth1-02.3
Connection Direction: Outgoing
Id Generated By Indexer: false
First: true
Sequencenum: 45
Service ID: https
Source: 10.30.3.200
Source Port: 50147
Destination: 172.217.168.228
Destination Port: 443
IP Protocol: 6
Xlate (NAT) Source IP: 212.166.62.52
Xlate (NAT) Source Port: 11288
Xlate (NAT) Destination Port:0
NAT Rule Number: 234
NAT Additional Rule Number: 0
Security Inzone: Trust
Security Outzone: Untrust
Context Num: 1
Action: Drop
Type: Connection
Policy Name: GHdC-Policy
Policy Management: SRVFWMGTND01
Db Tag: {B228AF78-7477-BD4F-9C40-CD6F2B61C40D}
Policy Date: 2021-05-26T09:51:51Z
Blade: Firewall
Origin: FW-EXT-B
Service: TCP/443
Product Family: Access
Logid: 0
Access Rule Name: Sub-Policy Trust-->Untrust Cleanup rule
Access Rule Number: 69.141
Policy Rule UID: 05a00e14-75ca-4b85-bb0a-6994640b919e
Layer Name: GHdC-Policy Trust_to_Untrust_sub_policy
Interface: eth1-02.3
Description: https Traffic Dropped from 10.30.3.200 to 172.217.168.228

Do you know why the redirection is not working anymore ?

Thanks !

Re: Using an application object breaks the automatic redirection to the captive portal

PhoneBoy — Fri, 28 May 2021 19:31:15 GMT

I suspect the work that is happening to detect the various applications in rule 69.138 is causing it to bypass the Captive Portal.
Your Captive Portal rules do not require App Control to be invoked.
I suggest putting 69.138 after your Captive Portal rules.

Re: Using an application object breaks the automatic redirection to the captive portal

osef — Mon, 31 May 2021 10:40:50 GMT

Unfortunatly, I need to allow every users to access a set of specifics URL without asking for authentication (it's a business requirement...)

Maybe I'm wrong but I don't think I can move this rule :s

Re: Using an application object breaks the automatic redirection to the captive portal

_Val_ — Mon, 31 May 2021 13:30:13 GMT

You are correct, you cannot move it up. However, You may want to add a rule for any to your FW above 69.139, to make sure the connectivity to captive portal works

Re: Using an application object breaks the automatic redirection to the captive portal

osef — Mon, 31 May 2021 13:30:25 GMT

I'm sorry, I don't understand your workaround. What can I add above 69.139 exactly ?

Re: Using an application object breaks the automatic redirection to the captive portal

_Val_ — Mon, 31 May 2021 13:30:00 GMT

You need to provide a way for users to open connection the the captive portal. As you are using an access role in 69.139, before the role itself is established, rule will not work. Either, use Any as a source (or internal networks, but not a user role), or add a rule allowing connectivity to the captive portal from any internal IP before that rule

Re: Using an application object breaks the automatic redirection to the captive portal

_Val_ — Mon, 31 May 2021 13:30:47 GMT

Also, show us how you define a user role for undefined users, please

Re: Using an application object breaks the automatic redirection to the captive portal

osef — Mon, 31 May 2021 14:04:12 GMT

I changed the rules like this :

But I've the following error when I try to push the rules :

here is the content of the undefined users objet (ckiand01 is my test device)

Re: Using an application object breaks the automatic redirection to the captive portal

_Val_ — Mon, 31 May 2021 14:30:24 GMT

Right, scratch "use any user" in the previous statement. You need to provide a rule that would allow connectivity from ckand01 to the portal, without auth. Put a rule allowing it access the portal on http and https, and try again

Re: Using an application object breaks the automatic redirection to the captive portal

osef — Mon, 31 May 2021 14:40:03 GMT

Like this ?

The automatic redirection is still not working 😞

Re: Using an application object breaks the automatic redirection to the captive portal

_Val_ — Mon, 31 May 2021 14:45:42 GMT

Are you trying HTTPS or plain HTTP site?

Re: Using an application object breaks the automatic redirection to the captive portal

osef — Mon, 31 May 2021 14:48:11 GMT

https, everything is https today and I can't do https inspection if the user is not authenticated

Re: Using an application object breaks the automatic redirection to the captive portal

_Val_ — Mon, 31 May 2021 14:48:48 GMT

OK, I see in the log above, you are using HTTPS. HTTPS Inspection should be enabled, if you need HTTPS connections to be redirected to the captive portal.

Also, there are some differences in behaviour, depending on the version you are using. You may want to look into sk121074 for more details.

Re: Using an application object breaks the automatic redirection to the captive portal

osef — Mon, 31 May 2021 14:53:55 GMT

- If I don't use any application objet, the automatic redirection works, even if https inspection is disabled

- If I start using application objet, I need https inspection for the automatic redirection to work ?

Re: Using an application object breaks the automatic redirection to the captive portal

_Val_ — Mon, 31 May 2021 15:03:35 GMT

No, https redirection should not work at all.

Which version of MGMT and GW are you using?

Re: Using an application object breaks the automatic redirection to the captive portal

osef — Mon, 31 May 2021 15:08:15 GMT

80.40 JH 102

I don't know why but it works if I use the first set of rules (the first picture in my first post)

Re: Using an application object breaks the automatic redirection to the captive portal

PhoneBoy — Mon, 31 May 2021 23:50:03 GMT

The following SK might explain why your original rules work: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk162856
It's also why I suggested moving the rule with other applications below it.

Re: Using an application object breaks the automatic redirection to the captive portal

osef — Tue, 01 Jun 2021 14:38:57 GMT

So it's a known limitation...

Sadly, what I want to do is not possible without https inspection... And I can't enable https inspection if I don't know the user...

Thanks for your time

Re: Using an application object breaks the automatic redirection to the captive portal

_Val_ — Tue, 01 Jun 2021 14:55:16 GMT

HTTPSi is not related to the user management

Re: Using an application object breaks the automatic redirection to the captive portal

osef — Tue, 01 Jun 2021 14:57:20 GMT

That's not what I mean.

I want to enable https inspection when the user is authenticated in the web portal or with the identity agent, not before