Project

General

Profile

Actions
Copy link

Regression #13212

closed

Captive Portal redirect not working if HTTPS login is enabled

Added by Jim Pingle almost 2 years ago. Updated almost 2 years ago.

Status:
Resolved
Priority:
High
Assignee:
Reid Linnemann
Category:
Captive Portal
Target version:
2.7.0
Start date:
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
22.05
Release Notes:
Force Exclusion
Affected Version:
2.7.0
Affected Architecture:

Description

With "Enable HTTPS login" checked and a proper (trusted, via LE/ACME) cert in place, captive portal clients do not detect the portal or redirect to the portal login page.

As soon as "Enable HTTPS login" is unchecked the clients are able to detect the portal, login, and work as they should.

With HTTPS login enabled:

rdr on em1 inet proto tcp from any to ! <cpzoneid_2_cpips> port 443  tagged cpzoneid_2_rdr -> 10.7.0.1 port 8003
pass in quick on em1 proto tcp from any to <cpzoneid_2_cpips> port 8003 ridentifier 13001 keep state(sloppy)
pass out quick on em1 proto tcp from 10.7.0.1 port 8003 to any flags any ridentifier 13002 keep state(sloppy)

With HTTPS login disabled:

rdr on em1 inet proto tcp from any to ! <cpzoneid_2_cpips> port 80  tagged cpzoneid_2_rdr -> 10.7.0.1 port 8002
pass in quick on em1 proto tcp from any to <cpzoneid_2_cpips> port 8002 ridentifier 13001 keep state(sloppy)
pass out quick on em1 proto tcp from 10.7.0.1 port 8002 to any flags any ridentifier 13002 keep state(sloppy)

On past versions with ipfw when HTTPS logins were enabled there were fwd rules in place for both 80 and 443 and not just 443:

02117        0         0 fwd 127.0.0.1,8003 tcp from any to any 443 in
02118        0         0 fwd 127.0.0.1,8002 tcp from any to any 80 in

If I manually edit rules.debug and add in the rules for 80 -> 8002 (both rdr and the pass rules) then the clients can detect the portal and login properly.

Actions
Copy link
 #1

Updated by Reid Linnemann almost 2 years ago

  • Assignee changed from Viktor Gurov to Reid Linnemann
Actions
Copy link
 #2

Updated by Reid Linnemann almost 2 years ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100
Actions
Copy link
 #3

Updated by Danilo Zrenjanin almost 2 years ago

Tested the patch on the:

2.7.0-DEVELOPMENT (amd64)
built on Wed May 25 06:21:23 UTC 2022
FreeBSD 12.3-STABLE


rdr on vtnet1.20 inet proto tcp from any to ! <cpzoneid_2_cpips> port 443  tagged cpzoneid_2_rdr -> 192.168.20.1 port 8003
rdr on vtnet1.20 inet proto tcp from any to ! <cpzoneid_2_cpips> port 80  tagged cpzoneid_2_rdr -> 192.168.20.1 port 8002

pass in quick on vtnet1.20 proto tcp from any to <cpzoneid_2_cpips> port 8003 ridentifier 13008 keep state(sloppy)
pass out quick on vtnet1.20 proto tcp from 192.168.20.1 port 8003 to any flags any ridentifier 13009 keep state(sloppy)
pass in quick from any to any tagged cpzoneid_2_passthru ridentifier 13010 keep state
pass in quick on vtnet1.20 proto tcp from any to <cpzoneid_2_cpips> port 8002 ridentifier 13011 keep state(sloppy)
pass out quick on vtnet1.20 proto tcp from 192.168.20.1 port 8002 to any flags any ridentifier 13012 keep state(sloppy)
pass in quick from any to any tagged cpzoneid_2_passthru ridentifier 13013 keep state
block in quick on vtnet1.20 from any to ! <cpzoneid_2_cpips> ! tagged cpzoneid_2_auth ridentifier 13014

It works fine. My browser detected the portal and redirected me to the portal login page.

Actions
Copy link
 #4

Updated by Jim Pingle almost 2 years ago

  • Status changed from Feedback to Resolved

This is working for me as well on the latest snapshot. User gets appropriately redirected to the portal page using the correct protocol (https) and the configured hostname.

Actions
Copy link
 #5

Updated by Jim Pingle almost 2 years ago

  • Tracker changed from Bug to Regression
  • Release Notes changed from Default to Force Exclusion
  • Affected Version set to 2.7.0

Not a problem in a release, excluding from release notes.

Actions
Copy link

Also available in: Atom PDF