Project

General

Profile

Actions

Regression #12345

open

Captive Portal users cannot get past portal even after successfully logging in

Added by Jim Pingle about 1 month ago. Updated about 1 month ago.

Status:
Feedback
Priority:
Urgent
Category:
Captive Portal
Target version:
Start date:
Due date:
% Done:

0%

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

Description

On current snapshots, a user can login to the Captive Portal but after login they are unable to proceed further. HTTP requests still get redirected to the portal page.

This happens both when using authentication and without.

Basic configuration with only captive portal active, no limiters/dummynet or other uses of ipfw.

: ipfw show
01000  3591  962561 skipto tablearg ip from any to any via table(cp_ifaces)
01100 14815 2927221 allow ip from any to any
02100     0       0 pipe tablearg MAC table(guest_pipe_mac)
02101     0       0 allow pfsync from any to any
02102     0       0 allow carp from any to any
02103     0       0 allow layer2 mac-type 0x0806,0x8035
02104     0       0 allow layer2 mac-type 0x888e,0x88c7
02105     0       0 allow layer2 mac-type 0x8863,0x8864
02106     0       0 deny layer2 not mac-type 0x0800,0x86dd
02107   132   12584 allow ip from any to table(guest_host_ips) in
02108   236  192774 allow ip from table(guest_host_ips) to any out
02109     0       0 allow ip from any to 255.255.255.255 in
02110     0       0 allow ip from 255.255.255.255 to any out
02111     0       0 pipe tablearg ip from table(guest_allowed_up) to any in
02112     0       0 pipe tablearg ip from any to table(guest_allowed_down) in
02113     0       0 pipe tablearg ip from table(guest_allowed_up) to any out
02114     0       0 pipe tablearg ip from any to table(guest_allowed_down) out
02115   425   39267 pipe tablearg ip from table(guest_auth_up) to any layer2 in
02116   306  111741 pipe tablearg ip from any to table(guest_auth_down) layer2 out
02117   285   32204 fwd 127.0.0.1,8002 tcp from any to any 80 in
02118   356  118391 allow tcp from any to any out
02119   207   12612 skipto 65534 ip from any to any
65534   320   21560 deny ip from any to any
65535   311   59369 allow ip from any to any
: ipfw table all list
--- table(cp_ifaces), set(0) ---
vtnet1 2100 2349 604099 1631038172
--- table(guest_auth_up), set(0) ---
192.168.1.100/32 46:ab:e3:1c:3e:16 2000 527 49133 1631038172
--- table(guest_host_ips), set(0) ---
192.168.1.1/32 0 392 208372 1631038169
--- table(guest_pipe_mac), set(0) ---
--- table(guest_auth_down), set(0) ---
192.168.1.100/32 2001 390 142415 1631038172
--- table(guest_allowed_up), set(0) ---
--- table(guest_allowed_down), set(0) ---

From the output above it looks like the client should be matching, the correct IP address and MAC address are in the table guest_auth_up and IP address is in guest_auth_down. I see counters increase on those rules. However, requests are actually denied. Attempting to connect out on port 80 hits the fwd rule.

Rules look the same here as they did on older releases, but I know there was some other recent ipfw work on pipes and so on, so perhaps the syntax needs an update.

Actions #1

Updated by Kristof Provost about 1 month ago

Merge request:
https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/382

As far as I can tell this ruleset should never have worked. Traffic passes through ipfw up to 4 times (inbound/outbound and layer 2 and layer 3). The way the current rules are set up we end up passing the traffic while doing L2 filtering thanks to the `02115 425 39267 pipe tablearg ip from table(guest_auth_up) to any layer2 in` rule (and indeed, the client is listed in the guest_auth_up table).
However, when we pass through the ruleset again, this time for layer 3, there's nothing to stop it from hitting the `02117 285 32204 fwd 127.0.0.1,8002 tcp from any to any 80 in` rule, and forwarding the traffic back to the captive portal.

A small change to the ruleset, to tag the traffic in the layer2 rule and to allow all tagged traffic through (i.e. during the layer 3 pass) fixes the issue, without modifying ipfw behaviour.

Actions #2

Updated by Jim Pingle about 1 month ago

  • Status changed from New to Feedback

MR merged, 9dac41af43a5b977a604098688776987c4f76722 -- Tested locally and it works here, but could use wider testing once it's in snapshots.

Actions

Also available in: Atom PDF