Default CP not working if enable

[sujyo1]

Dashboard & FW Rules


[sujyo1]

Here is CP Settings…


[sujyo1]

CP Page html (just cut to show here)…both pages are working fine as of now in other 21 older pf v 2.1.5, 2.2.1,4,5 with same FW rules & other settings, also there are no dns ips added in CP bypass ip or in FW rules.


[sujyo1]

DNS Forwarder


[Gertjan]

I saw this image :
Dashboard.JPG

1. The captive portal isn't listed as a running service - so its normal that it doesn't work.
2. No IPv4 on your internal interfaces - and know that the portal is IPv4 only …....

Btw read  https://doc.pfsense.org/index.php/Captive_Portal_Troubleshooting again.
No need to copy the explaination of ipfw - we all have this when ipfw doesn't understand its parameters.

I have this :

[2.3.2-RELEASE][admin@pfsense.brit-hotel-fumel.net]/root: ipfw zone list
Currently defined contexts and their members:
2: sis0,

So, my zoner 'number' is "2" - my captive portal is running on interface "sis0" - which is correct for me, of course, because I have the captive portal running on the interface called "sis0".

Now, it gets interresting :

[2.3.2-RELEASE][admin@pfsense.brit-hotel-fumel.net]/root: ipfw -x 2 show
00002     13294      3314314 pipe 7406 ip from any to any MAC any 64:80:99:9a:47:4b
00003     14586      9765900 pipe 7407 ip from any to any MAC 64:80:99:9a:47:4b any
65291         0            0 allow pfsync from any to any
65292         0            0 allow carp from any to any
65301   1006283     39413138 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     57897      2663300 deny ip from any to any layer2 not mac-type 0x0800,0x86dd
65310  19592183    837720144 allow ip from any to table(100) in
65311  19625424   1358243240 allow ip from table(100) to any out
65312     28184      7166550 allow ip from any to 255.255.255.255 in
65313         0            0 allow ip from 255.255.255.255 to any out
65314      1689       139547 pipe tablearg ip from table(3) to any in
65315      6892       618631 pipe tablearg ip from any to table(4) in
65316      8749     11036712 pipe tablearg ip from table(3) to any out
65317       811        61692 pipe tablearg ip from any to table(4) out
65318 144231430  32986871939 pipe tablearg ip from table(1) to any in
65319 214155810 264765937187 pipe tablearg ip from any to table(2) out
65531   3393392    462811178 fwd 127.0.0.1,8003 tcp from any to any dst-port 443 in
65532    699424    107327290 fwd 127.0.0.1,8002 tcp from any to any dst-port 80 in
65533   3900137   1155321789 allow tcp from any to any out
65534    416251     68860126 deny ip from any to any
65535        13          404 allow ip from any to any

I could explain all these rules, but first : but first WHAT do YOU have ?

Btw : These 'ipfw' rules have nothing to do with the Captive Portal Firewall rules in the GUI.

[sujyo1]

Thanks for reply…

1. The captive portal isn't listed as a running service - so its normal that it doesn't work.
   *  CP was turn off.

2. No IPv4 on your internal interfaces - and know that the portal is IPv4 only .......
   * 
   I have to turn on CP and here what I get...

$ ipfw zone list
Currently defined contexts and their members:
2: igb2,

$  ipfw -x 2 show
00002  6  396 pipe 2792 ip from any to any MAC any 88:dc:96:39:f5:b8
00003  3  132 pipe 2793 ip from any to any MAC 88:dc:96:39:f5:b8 any
00004  2  122 pipe 2794 ip from any to any MAC any 88:dc:96:3c:da:d5
00005  1  28 pipe 2795 ip from any to any MAC 88:dc:96:3c:da:d5 any
00006  0    0 pipe 2796 ip from any to any MAC any 88:dc:96:3c:dc:4c
00007  0    0 pipe 2797 ip from any to any MAC 88:dc:96:3c:dc:4c any
00008  2  122 pipe 2798 ip from any to any MAC any 88:dc:96:3c:dc:4f
00009  1  28 pipe 2799 ip from any to any MAC 88:dc:96:3c:dc:4f any
00010  2  122 pipe 2800 ip from any to any MAC any 88:dc:96:3c:dc:52
00011  1  28 pipe 2801 ip from any to any MAC 88:dc:96:3c:dc:52 any
00012  2  122 pipe 2802 ip from any to any MAC any 88:dc:96:3c:dc:55
00013  1  28 pipe 2803 ip from any to any MAC 88:dc:96:3c:dc:55 any
00014  2  122 pipe 2804 ip from any to any MAC any 88:dc:96:3c:dc:58
00015  1  28 pipe 2805 ip from any to any MAC 88:dc:96:3c:dc:58 any
00016  2  122 pipe 2806 ip from any to any MAC any 88:dc:96:3c:dc:5b
00017  1  28 pipe 2807 ip from any to any MAC 88:dc:96:3c:dc:5b any
65291  0    0 allow pfsync from any to any
65292  0    0 allow carp from any to any
65301 24  888 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  0    0 deny ip from any to any layer2 not mac-type 0x0800,0x86dd
65310  0    0 allow ip from any to table(100) in
65311  0    0 allow ip from table(100) to any out
65312  0    0 allow ip from any to 255.255.255.255 in
65313  0    0 allow ip from 255.255.255.255 to any out
65314  3  267 pipe tablearg ip from table(3) to any in
65315 11  721 pipe tablearg ip from any to table(4) in
65316 11 1053 pipe tablearg ip from table(3) to any out
65317  3  411 pipe tablearg ip from any to table(4) out
65318  0    0 pipe tablearg ip from table(1) to any in
65319  0    0 pipe tablearg ip from any to table(2) out
65532  0    0 fwd 127.0.0.1,8002 tcp from any to any dst-port 80 in
65533  1  83 allow tcp from any to any out
65534 40 2820 deny ip from any to any
65535  5  194 allow ip from any to any

$ ipfw_context -1
ipfw_context: not found




[Gertjan]

Your ipfw rules are look fine to me.

Can you list what's in the "table(100)" ?
(normally, its the IP of your HOSPOT interface.)

Use:

ipfw -x 2 table all list

You have a switch with an IPv4 ??

Can you confirm that connected devices became an IP from pfSEnse (DHCP server running on interface HOSPOT) ? And the gateway (== IP interface HOSPOT), -  DNS ?

Can your devices resolve domaine names ? (aka : DNS works) this even when you are NOT authenticated to the portal.

Normal that your LAN is down ?

[sujyo1]

Thanks for reply…

Here what I did today... Make sure all interface's IPV6 set to none then remove IPV6 & keep IPV4 in all HOTSPOT firewall rules. then turn on CP & run this commend It show...its looks like few clients went through CP :)!! can see some are still struggling including switch(10.10.10.2) eventhough its mac is in cp pass list!

$ ipfw -x 2 table all list
$ ipfw -x 2 table all list
---table(1)---
10.10.10.178/32 mac x0:xx:65:x7:1f:56 2942
10.10.10.204/32 mac x4:xx:9f:xe:5x:5c 2944
---table(2)---
10.10.10.178/32 mac 0x:88:x5:3x:1x:56 2943
10.10.10.204/32 mac x4:5x:9x:cx:5x:5c 2945
---table(3)---
8.8.4.4/32 2930
8.8.8.8/32 2932
10.10.10.1/32 2908
10.10.10.12/32 2910
10.10.10.13/32 2912
10.10.10.14/32 2914
10.10.10.15/32 2916
10.10.10.16/32 2918
10.10.10.17/32 2920
10.10.10.18/32 2922
10.10.10.19/32 2924
10.10.10.20/32 2926
xx.xx.xxx.13/32 2934
xx.xx.xxx.162/32 2936
xx.xx.xxx.164/32 2938
xx.xx.xxx.35/32 2940
xxxx:fdc8::/32 2928
---table(4)---
8.8.4.4/32 2931
8.8.8.8/32 2933
10.10.10.1/32 2909
10.10.10.12/32 2911
10.10.10.13/32 2913
10.10.10.14/32 2915
10.10.10.15/32 2917
10.10.10.16/32 2919
10.10.10.17/32 2921
10.10.10.18/32 2923
10.10.10.19/32 2925
10.10.10.20/32 2927
xx.xx.xxx.13/32 2935
xx.xx.xxx.162/32 2937
xx.xx.xxx.164/32 2939
xx.xx.xxx.35/32 2941
xxxx:xxxx::/32 2929
---table(100)---
10.10.10.1/32 0

You have a switch with an IPv4 ??
*Switch is Engenius EWS5912FP (managed L2 with wireless controller) set  to static IPv4 10.10.10.2 then 7 APs- 10.10.10.3 to 10.10.10.9
  All APs set to static (IPV4 as above) GW 10.10.10.1, DNS 10.10.10.1

Can you confirm that connected devices became an IP from pfSEnse (DHCP server running on interface HOSPOT) ? And the gateway (== IP interface HOSPOT), -  DNS ?

• Yes device receive IP 10.10.10.0/24 GW 10.10.10.1, and 4 dns servers....

Can your devices resolve domaine names ? (aka : DNS works) this even when you are NOT authenticated to the portal.

• Yes all clients can go online if CP is OFF, As soon as I turn on CP all are droping...then I manually xcle their DHCP leases and force them to get    dhcp again so CP can show up...

[Gertjan]

@sujyo1:

Here what I did today… Make sure all interface's IPV6 set to none then remove IPV6 & keep IPV4 in all HOTSPOT firewall rules. then turn on CP & run this commend It show...its looks like few clients went through CP :)!! can see some are still struggling including switch(10.10.10.2) eventhough its mac is in cp pass list!

Do you need THIS switch ? Why is it managed ?
If you change it for the time being for a dumb 10 $ switch.
A switch with an IP (MAC ??) (just trying to eliminate things that are off-standard)

@sujyo1:

$ ipfw -x 2 table all list
$ ipfw -x 2 table all list
–-table(1)---
10.10.10.178/32 mac x0:xx:65:x7:1f:56 2942
10.10.10.204/32 mac x4:xx:9f:xe:5x:5c 2944
---table(2)---
10.10.10.178/32 mac 0x:88:x5:3x:1x:56 2943
10.10.10.204/32 mac x4:5x:9x:cx:5x:5c 2945
---table(3)---
8.8.4.4/32 2930
8.8.8.8/32 2932
10.10.10.1/32 2908
10.10.10.12/32 2910
10.10.10.13/32 2912
10.10.10.14/32 2914
10.10.10.15/32 2916
10.10.10.16/32 2918
10.10.10.17/32 2920
10.10.10.18/32 2922
10.10.10.19/32 2924
10.10.10.20/32 2926
xx.xx.xxx.13/32 2934
xx.xx.xxx.162/32 2936
xx.xx.xxx.164/32 2938
xx.xx.xxx.35/32 2940
xxxx:fdc8::/32 2928
---table(4)---
8.8.4.4/32 2931
8.8.8.8/32 2933
10.10.10.1/32 2909
10.10.10.12/32 2911
10.10.10.13/32 2913
10.10.10.14/32 2915
10.10.10.15/32 2917
10.10.10.16/32 2919
10.10.10.17/32 2921
10.10.10.18/32 2923
10.10.10.19/32 2925
10.10.10.20/32 2927
xx.xx.xxx.13/32 2935
xx.xx.xxx.162/32 2937
xx.xx.xxx.164/32 2939
xx.xx.xxx.35/32 2941
xxxx:xxxx::/32 2929
---table(100)---
10.10.10.1/32 0

You have a switch with an IPv4 ??
*Switch is Engenius EWS5912FP (managed L2 with wireless controller) set  to static IPv4 10.10.10.2 then 7 APs- 10.10.10.3 to 10.10.10.9
  All APs set to static (IPV4 as above) GW 10.10.10.1, DNS 10.10.10.1

Can you confirm that connected devices became an IP from pfSEnse (DHCP server running on interface HOSPOT) ? And the gateway (== IP interface HOSPOT), -  DNS ?

• Yes device receive IP 10.10.10.0/24 GW 10.10.10.1, and 4 dns servers....

Ok for all this.
Look fine and normal.
Remember : https://doc.pfsense.org/index.php/Captive_Portal_Troubleshooting

Section : Captive portal not redirecting
If clients are not being redirected to the portal page when attempting to browse on an interface with captive portal enabled, it's most always one of the following causes.

DNS resolution not functioning - the clients on the captive portal interface must either be using the DNS forwarder on pfSense, on the IP of the interface where the client resides (which is the default configuration), or if using some other IP for DNS, it must be an allowed IP entry. If DNS fails, the browser never issues the HTTP request, hence it cannot be intercepted and redirected.
    Firewall rules on the captive portal interface do not allow the initial HTTP request - if the user is trying to browse to google.com, but HTTP connections are not allowed to google.com, the HTTP request will be blocked and hence cannot be redirected. Under Firewall > Rules, on the interface where captive portal is enabled, the traffic to be redirected must be allowed to pass. This is most commonly HTTP to any destination.
    The client has an HTTPS home page - The request must be to an HTTP site in order for the portal to redirect the client.

@sujyo1:

Can your devices resolve domaine names ? (aka : DNS works) this even when you are NOT authenticated to the portal.

• Yes all clients can go online if CP is OFF, As soon as I turn on CP all are droping…then I manually xcle their DHCP leases and force them to get    dhcp again so CP can show up...

Note : An ISP normally hands over some of its own DNS. I never ever added extra ones like the "8.8.8.8" (why should I give Google the sites that I'm using ?). Why adding them ?
I use the default "DNS resolver" - not the "forwarder" (although it should work).

When the CP is being shut down (and GUI Firewall rules permit communication) all devices should have a 'internet connection'.
As soon as you put on the CP - and you connect a device to your Wifi - or you cable it up, you can not communicate anymore (normal, you should use a browser, visit a http://… site) and then authenticate.
BUT :
Running a
ping www.google.com
should always resolve "www.google.com" to an IP …. (this proves that DNS resolution IS working). See point 3 listed under "Section : Captive portal not redirecting".
Don't use always www.google.com to test - use an URL that IS NOT in your local (devices) DNS cache !!! (or flush your cache -> PC => ipconfig /flushdns !!!)

So, if a device is not getting redirected :
Check 1) what URL are you suing to start ? https ? then no go.
Check 2 : ping to www.whatever.tld resolve the URL to an IP ? (no ICMP replies, that is normal) If no then DNS troubles.

If DNS is working, a browser on a connected device obtains an IPv4 - et troughs out a "http GET" and that one request will be captured by this rule :
65532  0    0 fwd 127.0.0.1,8002 tcp from any to any dst-port 80 in
=> read : any communication coming in on port 80 (so : https => YOU LOOSE) will be redicted to 127.0.0.1 port 8002.
and that"s where the Captive Portal web server will reply with the captive portal login page …...
WHEN authentication succeeds, the client's device IP and MAC will be added to table 3 and 4.

As you already saw when listing your ipfw rules, two devices were listed in these tables, so they managed to login.

Of courses, after login, the "Captive Portal" firewall rules (ipfw !) become transparent - now are used  the other, GUI firewall rules - they still / will apply.

My ISP hasn't ANY IPv6 capabilities.
But, I'm using https://ipv6.he.net/ - I have a free account there, and pfSense WAN and my entire LAN is using IPv6 (DHCP6) - all my devices on LAN are IPv4 and IPv6 connected.
But, the pfSense Captive Portal isn't IPv6 ready at all.
…. but look again at the ipfw firwall rules ( using https://en.wikipedia.org/wiki/EtherType )
65301 24  888 allow ip from any to any layer2 mac-type 0x0806,0x8035
=> ARP et RASP passes through.

65302  0    0 allow ip from any to any layer2 mac-type 0x888e,0x88c7
=> EAP ET PBB passes through

65303  0    0 allow ip from any to any layer2 mac-type 0x8863,0x8864
=> PPPoE passes through

65307  0    0 deny ip from any to any layer2 not mac-type 0x0800,0x86dd
=> IPv4 and IPv6 passes through ( !)

[sujyo1]

What a detail explanation abt CP!! Gertjan your are genious!! A BIG THANK YOU !!
I keep CP open for 5 hrs yesterday. only few guest able to log in others keep trying. I think there are DNS problem exist some where. or client's devices already running other apps, browsers etc in back ground preventing cp to open & redirect on their devices as you explain above
Q: Is http become auto https hotel's redirected website can causing this problem? As CP basic rule the redirect page must be a http site. So in CP page I put http://www.website.com not https. bcs when I go to hotel's http site its change to https automatic on my computer browser.

Do you need THIS switch ? Why is it managed?
If you change it for the time being for a dumb 10 $ switch.
A switch with an IP (MAC ??) (just trying to eliminate things that are off-standard)
*I keep this switch for remote tech support access so they don't have to mess with pf.

[Gertjan]

Read this https://forum.pfsense.org/index.php?topic=116386.msg645311#msg645311 to understand why nearly all devices today do present a login page to the visitor.
If they don't, they are NOT "portal aware" ….. (and should be updated or recycled ;) )

Btw : No, intercepting a direct, initial "https" GET and hoping that the portal login shows up is like hoping 'a man in the middle' interacts with your connection when you visit your bank account on the net. Don't ask for it - you won't want this .... ;)

[Blackhat]

Try to make a new user with full access to this page like SuperUser grant all access to this user.
then enable your captive portal.
open web browser and go to address bar and type the pfsense ip with 8000 port. e.g. http://192.168.1.1:8000
login page will popup then use the new username & password that you created lately like the superuser.
then done.
Internet can pass tru your PC now.