Bug #2798
closed
Captive Portal does not capture anyone
Added by Robert Staph about 12 years ago.
Updated over 11 years ago.
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
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.
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.
I just removed and readded my v6 gateway and LAN then did a reboot and its working.
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.
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.
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.
You mentioned it happens when you enable/disable alias for pfblocker. Have you tried to disable pfblocker and check if error happens?
- Status changed from New to Closed
there were CP issues in general at that point, since fixed.
Also available in: Atom
PDF