Captive Portal & Proxy on 2.7.0

MrIT

Hello everyone,

we are experiencing difficulties with the captive portal in conjunction with the proxy (Squid+SquidGuard). Of course, both run on a (virtualized) pfSense.

We have a network with an active captive portal as well with an transparent proxy set up. The proxy is also announced by the DHCP server using WPAD. That worked as charm until 2.6.0: first, the user must authenticate against the captive portal using a voucher and has filtered web access afterwards. It did not seem that clients were able to reach the proxy server without being intercepted by the captive portal first.

But on 2.7.0 clients are able to access the proxy without the interception by the captive portal. So they have filtered web access right away without entering any voucher (and without seeing the captive portal authentication page at all).

Is this the way the captive portal is supposed to work starting with 2.7.0? Or is this a bug which was introduced by the switch to the new implementation of the captive portal?

Regards
Marcel

Gertjan

@MrIT

pfSense 2.6.0 was using 'ipfw' as it's firewall
pfSense 2.7.0 uses the 'default' pfSense firewall, 'pf'. pf has been modified so it it MAC aware.

A captive portal, on the pfSense is (nothing more) as a set of firewall rules : it starts with a set of rules, the user allow rules, added for every authorized user, and then a redirect rule (port 80 and or 443) to the internal web server, and a final "block all" rule.
You can see the pf rules in /tmp/rules.debug

If your proxy also add pf rules .... above - or they mix with the portal rules, then yes, you can have "special (side) effects".

This :

@MrIT said in Captive Portal & Proxy on 2.7.0:

But on 2.7.0 clients are able to access the proxy without the interception by the captive portal.

means to me that client traffic is 'accepted' by a proxy firewall rule before the 'captive portal' rules can do their work.

I never used a proxy.
In the past, a captive portal + proxy == pure pain guaranteed (difficult to install - manual patching etc).

MrIT

You can see the pf rules in /tmp/rules.debug

Just took a look, but I do not "speak" pf rules But what I saw:

# Captive Portal
rdr on hn0.1066 inet proto tcp from any to ! <cpzoneid_4_cpips> port 80 tagged cpzoneid_4_rdr -> 10.66.0.1 port 8004

# NAT Inbound Redirects

# Setup Squid proxy redirect
no rdr on hn1 proto tcp from any to { 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 } port {80,443}
no rdr on hn0.1065 proto tcp from any to { 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 } port {80,443}
no rdr on hn0.1066 proto tcp from any to { 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 } port {80,443}
no rdr on hn0.1067 proto tcp from any to { 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 } port {80,443}
no rdr on hn0.1068 proto tcp from any to { 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 } port {80,443}
no rdr on hn0.1069 proto tcp from any to { 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 } port {80,443}
rdr pass on hn1 inet proto tcp from any to !(hn1) port 80 -> 127.0.0.1 port 3128
rdr pass on hn1 inet proto tcp from any to !(hn1) port 443 -> 127.0.0.1 port 3129
rdr pass on hn0.1065 inet proto tcp from any to !(hn0.1065) port 80 -> 127.0.0.1 port 3128
rdr pass on hn0.1065 inet proto tcp from any to !(hn0.1065) port 443 -> 127.0.0.1 port 3129
rdr pass on hn0.1066 inet proto tcp from any to !(hn0.1066) port 80 -> 127.0.0.1 port 3128
rdr pass on hn0.1066 inet proto tcp from any to !(hn0.1066) port 443 -> 127.0.0.1 port 3129
rdr pass on hn0.1067 inet proto tcp from any to !(hn0.1067) port 80 -> 127.0.0.1 port 3128
rdr pass on hn0.1067 inet proto tcp from any to !(hn0.1067) port 443 -> 127.0.0.1 port 3129
rdr pass on hn0.1068 inet proto tcp from any to !(hn0.1068) port 80 -> 127.0.0.1 port 3128
rdr pass on hn0.1068 inet proto tcp from any to !(hn0.1068) port 443 -> 127.0.0.1 port 3129
rdr pass on hn0.1069 inet proto tcp from any to !(hn0.1069) port 80 -> 127.0.0.1 port 3128
rdr pass on hn0.1069 inet proto tcp from any to !(hn0.1069) port 443 -> 127.0.0.1 port 3129

The redirect seems to be processed first, but there is no immediate block all. Instead the rules for the transparent proxy applies. I guess the block all stuff is done later:

# Captive Portal
pass in quick on hn0.1066 proto tcp from any to <cpzoneid_4_cpips> port 8004 ridentifier 13001 keep state(sloppy)
pass out quick on hn0.1066 proto tcp from 10.66.0.1 port 8004 to any flags any ridentifier 13002 keep state(sloppy)
block in quick on hn0.1066 from any to ! <cpzoneid_4_cpips> ! tagged cpzoneid_4_auth ridentifier 13003


# User-defined rules follow

anchor "userrules/*"
[...]

I might be able to disable "transparent proxy" and recreate the redirect rules manually. But as you stated, that's pure pain :(

In the past, a captive portal + proxy == pure pain guaranteed (difficult to install - manual patching etc).

Do I have any other choice (except for chaining two pfSenses, one with the proxy enabled and on only for the captive portal)? I want my students to have partially "free" internet and need a very easy way of providing this. Also I have to implement basic web filtering...

Regards

MrIT

Update: I downgraded to 2.6.0 which works perfectly for us. Maybe I find the option to create an issue somewhere so it gets fixed at some point in the future.

aissaopgi

j'ai le même problème avec la version 23.09.01 lors j'active le proxy les utilisateur passe directement au proxy sans passé par le portail captif et si j'active authentification proxy par le portail captif le squid proxy désactive automatiquement et des messages d'erreurs s'affiche.
PHP errors
PHP ERROR: Type: 1, File: /usr/local/bin/check_ip.php, Line: 28, Message: Uncaught Error: Undefined constant "STDIN" in /usr/local/bin/check_ip.php:28
Stack trace:
#0 {main}
thrown @ 2024-01-31 14:43:27
PHP ERROR: Type: 1, File: /usr/local/bin/check_ip.php, Line: 28, Message: Uncaught Error: Undefined constant "STDIN" in /usr/local/bin/check_ip.php:28
Stack trace:
#0 {main}
thrown @ 2024-01-31 14:43:28
PHP ERROR: Type: 1, File: /usr/local/bin/check_ip.php, Line: 28, Message: Uncaught Error: Undefined constant "STDIN" in /usr/local/bin/check_ip.php:28
Stack trace:
#0 {main}
thrown @ 2024-01-31 14:43:29

valdarnini

@aissaopgi

I'm facing the same problem in version 2.7.2, I've always used captive portal with transparent proxy and it's always worked perfectly.
If you find something that works, please post it to us.
Until version 2.6.0 I used it without problems.

valdarnini

@valdarnini
I resolved it as follows, I configured the captive portal with https, but with a valid certificate.
cannot be self-signed

Gertjan

@valdarnini said in Captive Portal & Proxy on 2.7.0:

cannot be self-signed

Well, it can, but you'll discover that no one will use your captive portal.
As soon as they connect, and get redirected to your captive login page will see a the scary browser certificate error will popup, the one that scares the h*ll out the less knowledgeable users.
The one that knows what the error actually means, will know what to do, and connects just fine. But that person will be a one out of a 100, the other 99 will not insist, and bail out.

For private or personal use, a self signed certificate is good enough.
For public usage, a signed 'by known authorities' certificate is not an option.

MrIT

I came to the conclusion that running a proxy filter is a pain in the a**. It did not work on Android, sometimes it did not work with iOS - at least Windows was the least pain as it seems to implement WPAD in an administrator-friendly way (we announced our proxy using DHCP).

My solution: no Squid at all. I am now running two machines with Pi-Hole. The to-be-released version 6 supports allowlists so we can configure a "you cannot do anything per default" and allowing certain websites using our pre-defined lists. The other DNS filter runs the current stable release with a bunch of blocklists.

You can also use pfBlocker-ng's DNSBL capabilities, but Pi-Holes web interface is so much faster and easier to work with (it get's even faster with v6). I am using pfBlocker-ng's IP blocking capatabilities :)

Regards