Regression #12345
closedCaptive Portal users cannot get past portal even after successfully logging in
0%
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.
Updated by Kristof Provost over 3 years 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.
Updated by Jim Pingle over 3 years 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.
Updated by Jim Pingle about 3 years ago
- Plus Target Version changed from 21.09 to 22.01
Updated by Max Leighton about 3 years ago
I tested Captive Portal in
22.01-DEVELOPMENT (amd64)
built on Fri Nov 05 05:21:41 UTC 2021
FreeBSD 12.3-PRERELEASE
I was able to authenticate and proceed through the portal page without issues.
Updated by Jim Pingle about 3 years ago
- Status changed from Feedback to Resolved