Project

General

Profile

Actions

Bug #2798

closed

Captive Portal does not capture anyone

Added by Robert Staph about 12 years ago. Updated over 11 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
02/06/2013
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
Affected Architecture:

Description

While testing the snapshot of Feb 5th, 2013, I noticed that the captive portal is not capturing anyone after removing the old CP config and creating a new one. I upgraded a backup machine that contained 2.0.2 and swapped boxes. Originally it worked, but the Zone and Description were blank (with no way to fix them in "edit settings"). I removed that one and created a new zone and now the CP doesn't work at all (all visible settings the same). There are no errors in the logs.


Files

Actions #1

Updated by Jim Pingle about 12 years ago

Can you attach a copy of your config.xml with the broken configuration?
You can remove passwords, keys, etc. Mostly we'd need to see the captiveportal section.

Actions #2

Updated by Robert Staph about 12 years ago

I also looked through the other CP bugs and fixes and noticed that I didn't have net.link.ether.ipfw and net.inet.ip.fw.one_pass set to 1. Did that and still no joy. In fact the system tunables list is about 1/4 the size it was under 2.0.2.

Actions #3

Updated by Robert Staph about 12 years ago

I just removed and readded my v6 gateway and LAN then did a reboot and its working.

Actions #4

Updated by Ermal Luçi about 12 years ago

IS this an issue or not?
If yes, provide input when you reproduce this with ipfw -x $zone show, ipfw -x $zone table all list,
kldstat, /tmp/ipfw_$zone* content.

Actions #5

Updated by Robert Staph about 12 years ago

ipfw -x client show

65291    0       0 allow pfsync from any to any
65292    0       0 allow carp from any to any
65301  540   21492 allow ip from any to any layer2 mac-type 0x0806,0x8035
65302    0       0 allow ip from any to any layer2 mac-type 0x888e,0x88c7
65303    0       0 allow ip from any to any layer2 mac-type 0x8863,0x8864
65307   34    1564 deny ip from any to any layer2 not mac-type 0x0800,0x86dd
65310  441   45752 allow ip from any to { 255.255.255.255 or 10.10.10.1 } in
65311  447  166470 allow ip from { 255.255.255.255 or 10.10.10.1 } to any out
65312    0       0 allow icmp from { 255.255.255.255 or 10.10.10.1 } to any out icmptypes 0
65313    0       0 allow icmp from any to { 255.255.255.255 or 10.10.10.1 } in icmptypes 8
65314    0       0 pipe tablearg ip from table(3) to any in
65315    0       0 pipe tablearg ip from any to table(4) out
65316 7445 4035515 pipe tablearg ip from table(1) to any in
65317 8322 9300343 pipe tablearg ip from any to table(2) out
65532  171   14136 fwd 127.0.0.1,8000 tcp from any to any dst-port 80 in
65533  140   20711 allow tcp from any to any out
65534 1060   86622 deny ip from any to any
65535    0       0 allow ip from any to any

ipfw -x client table all list

---table(1)---
10.10.10.130/32 2026 3123 1618066
10.10.10.131/32 2034 3691 567339
10.10.10.132/32 2030 126 13871
10.10.10.250/32 2028 522 69489
---table(2)---
10.10.10.130/32 2027 3672 4293285
10.10.10.131/32 2035 5262 6071583
10.10.10.132/32 2031 109 24078
10.10.10.250/32 2029 722 763142
---table(3)---
10.0.0.1/32 2036 0 0
---table(4)---
10.0.0.1/32 2037 0 0

kldstat

Id Refs Address    Size     Name
 1   10 0xc0400000 13aea74  kernel
 2    1 0xc3af5000 12000    ipfw.ko
 3    1 0xc3b95000 e000     dummynet.ko

contents of /tmp/ipfw_client.cp.rules

flush
add 65291 allow pfsync from any to any
add 65292 allow carp from any to any
# layer 2: pass ARP
add 65301 pass layer2 mac-type arp,rarp
# pfsense requires for WPA
add 65302 pass layer2 mac-type 0x888e,0x88c7
# PPP Over Ethernet Session Stage/Discovery Stage
add 65303 pass layer2 mac-type 0x8863,0x8864

# layer 2: block anything else non-IP(v4/v6)
add 65307 deny layer2 not mac-type ip,ipv6
add 65310 pass ip from any to { 255.255.255.255 or 10.10.10.1  } in
add 65311 pass ip from { 255.255.255.255 or 10.10.10.1  } to any out
add 65312 pass icmp from { 255.255.255.255 or 10.10.10.1  } to any out icmptype 0
add 65313 pass icmp from any to { 255.255.255.255 or 10.10.10.1  } in icmptype 8 
add 65314 pipe tablearg ip from table(3) to any in
add 65315 pipe tablearg ip from any to table(4) out
add 65316 pipe tablearg ip from table(1) to any in
add 65317 pipe tablearg ip from any to table(2) out

# redirect non-authenticated clients to captive portal
add 65532 fwd 127.0.0.1,8000 tcp from any to any dst-port 80 in 
# let the responses from the captive portal web server back out
add 65533 pass tcp from any to any out
# block everything else
add 65534 deny all from any to any

table 3 add 10.0.0.1/32 2036
table 4 add 10.0.0.1/32 2037

I seem to be able to reproduce it by enabling or disabling an alias for pfblocker and saving the rules page. Then the CP doesn't catch anyone till I reboot.

Actions #6

Updated by Robert Staph about 12 years ago

The clients listed in there were from before I saved the rules. Any new people connecting through the CP don't get the CP page and don't have the throttling applied to them, till I reboot of course.

Actions #7

Updated by Renato Botelho about 12 years ago

You mentioned it happens when you enable/disable alias for pfblocker. Have you tried to disable pfblocker and check if error happens?

Actions #8

Updated by Chris Buechler over 11 years ago

  • Status changed from New to Closed

there were CP issues in general at that point, since fixed.

Actions

Also available in: Atom PDF