After upgrade to 2.2 redirection broken to the captive portal.

fableman

Hi

Everything was working before the upgrade.
Now the authentication page will not showup up and no one can use the wifi net all.
When I check the page from the configuration page it looks fine (port 8002)

I have rules set for port 8000 for the wifi network as before.

Feels like the redirection towards to portal is not working after the upgrade.

Uers get IP and everything looks fine , just that redirection to auth-page don't work.

Please help..

Derelict

It's not 8000 any more. You have to change everything to 8002. No idea why they did that.

What rules are you talking about?

fableman

Thanks!!!

I changed my firewall rule to allow port 8002 instead of 8000 for the WIFI network and now I see users get into the portal again.

If they change port like that they should have a "head up" for it :)

Gertjan

@fableman:

If they change port like that they should have a "head up" for it :)

Please, can you publish an image with your interface-portal-firewall-rules set ?
It was never ever needed to use, indicate, include, mention, state these ports (I guess 8000, or 8001, etc).
I never used them in any firewall rules.

They are not needed to be known to the end-user (the pfSense admin like you and me).
These port numbers are just internal values.

So, no need to mention these code changes in the heads up ….

Derelict

@fableman:

Thanks!!!

I changed my firewall rule to allow port 8002 instead of 8000 for the WIFI network and now I see users get into the portal again.

If they change port like that they should have a "head up" for it :)

I agree. https://doc.pfsense.org/index.php/2.2_New_Features_and_Changes#Captive_Portal

guess they didn't see it was important enough for the upgrade guide, but it's in the release notes.

fableman

@Gertjan:

@fableman:

If they change port like that they should have a "head up" for it :)

Please, can you publish an image with your interface-portal-firewall-rules set ?
It was never ever needed to use, indicate, include, mention, state these ports (I guess 8000, or 8001, etc).
I never used them in any firewall rules.

They are not needed to be known to the end-user (the pfSense admin like you and me).
These port numbers are just internal values.

So, no need to mention these code changes in the heads up ….

I block all ports to my pfsense from the wifi network excluding 8000 (not 8002) and 53(dns)
If I don't enable 8000 / 8002 how would then the wifi clients get into the portal :)

fableman

@Derelict:

@fableman:

Thanks!!!

I changed my firewall rule to allow port 8002 instead of 8000 for the WIFI network and now I see users get into the portal again.

If they change port like that they should have a "head up" for it :)

I agree. https://doc.pfsense.org/index.php/2.2_New_Features_and_Changes#Captive_Portal

guess they didn't see it was important enough for the upgrade guide, but it's in the release notes.

Would be great to have a url to that info from inside the pfsense, I just hit the upgrade button :)
Guess the releses been that stable I just got lazy :)

Gertjan

@fableman:

I block all ports to my pfsense from the wifi network excluding 8000 (not 8002) and 53(dns)
If I don't enable 8000 / 8002 how would then the wifi clients get into the portal :)

Have a look at this video : https://www.youtube.com/watch?v=O9D2fM883Fc - its still valid today.
You saw the ONLY firewall rule that was created for the WIRELESS interface ?
Its something like "Source WIRELESS Net to any == Ok".
That's it.
No need to mention ports (8002,8003) or whatever, like DNS.
(This is a very basic firewall rule set, but it works).

Why ?
Understand that the firewall rules on the GUI Interfaces -> Wireless Interface page will be used only AFTER the user is logged in.
Before that, everything forbidden. The firewall rules on that page aren't even taken in account.

Because there is another firewall :)
Login to SSH, and type

ipfw zone list

This will give you typically two zone, your 'zone name' of your LAN and the name of the zone your portal interface - a number.
Mine is called '2'.
Now:
ipfw -x 2 show
The result is interesting:
These are out of subject (something like : only tcp4 / ipv6 packets and other special packets are allowed to come in):

65291       0          0 allow pfsync from any to any
65292       0          0 allow carp from any to any
65301    2214      92052 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      27       1242 deny ip from any to any layer2 not mac-type 0x0800,0x86dd

These are what it is all about:

65310    8447     690791 allow ip from any to { 255.255.255.255 or 192.168.2.1 } in
65311   10877    3504852 allow ip from { 255.255.255.255 or 192.168.2.1 } to any out

Allow all IPs (on our portal net) to communicate with our pfSense IP (portal interface, DNS, http, https, whatever, any port to "192.168.2.1 will be fine)
Mine is of course 192.168.2.1

The rest of the list:
These allow a client to ping the pfSEnse portal interface:

65312       0          0 allow icmp from { 255.255.255.255 or 192.168.2.1 } to any out icmptypes 0
65313       0          0 allow icmp from any to { 255.255.255.255 or 192.168.2.1 } in icmptypes 8

Humm, no one pinged my portal interface >:(
These rules aren't applied (used), their usage counter is zero, as you can see.

These:

65314       0          0 pipe tablearg ip from table(3) to any in
65315       0          0 pipe tablearg ip from any to table(4) in
65316       0          0 pipe tablearg ip from table(3) to any out
65317       0          0 pipe tablearg ip from any to table(4) out

are 2 tables (3 and 4) who contain all the MAC's and IP that pass through - as set on the Captive portal setup page (tabs)

This:

65318 1381421  372612476 pipe tablearg ip from table(1) to any in
65319 1320814 1332447136 pipe tablearg ip from any to table(2) out

is the list with tables that are authenticated captive portal users users (IP and MAC) - as soon as aa user is logged in, he will be put in table 1 & 2.
As you can see, these rules are applied massively on my pfSense box: normal, this shows the activity of my logged in portal clients.

This:
65318 1381421  372612476 pipe tablearg ip from table(1) to any in
65319 1320814 1332447136 pipe tablearg ip from any to table(2) out

is what the portal magic is all about.
Everything that reached this point isn't authenticated to the portal interface yet:
All requests to "port 443" are forwarded to "127.0.0.1,8003" and that is where our 'https' authentication is handled (on my pfSEnse, I use https authentication) - pfSense runs a web server on 127.0.0.1 port 443 to handle SSL (https) login.
The same thing goes for normal "port 80" requests".

This

65533    2494     535090 allow tcp from any to any out

allows our portal interface to talk to the clients (device) on portal interface, no mather what.

And finally: the mega block all:

65534    1412      89109 deny ip from any to any

Anything that comes up to this point is blocked.

All this doesn't explain why you should 'need' to open the ports 8002,8003 and 53 on the firewall GUI WIRELESS page, how you know that these rules are will NOT participating in the authentication phase.
~~Only 'ipfw' rules are used then.~~
You might as well empty all your portal interface GUI firewall rules (leaving in, of course, the default hidden "block all rule").
Authentication is then still working for me - but, of course, the client can't surf afterwards, when he is logged in.
[[color=red]edit : I'll test these two lines above tomorrow first … (I start to doubt ... ;))]

This is my Wireless Firewall rule set:

Bleu section: My AP's (4) on the WIRELESS network (192.168.2.0/24) can communicate with "Internet" - and syslog to a device an the LAN (192.168.1.0/24).
Red section: all kind of stuff that I do not want to get out of the WIRELESS network (192.168.2.0/24)
Green section: All Ok if destination IS NOT the LAN segment (192.168.1.0/24).
Red: Block …..

Question: see this movie again: https://www.youtube.com/watch?v=O9D2fM883Fc - start looking at 6 minutes and 35 seconded.
The guy connects by Wifi to its own portal interface (he shut down his LAN RJ45 interface - and activated the Wireless in his PC).
He uses the
ipconfig
command.
Even better wil be
ipenconfig /all
DO YOU SEE on your PC: A Gateway and DNS that have the IP of your pfSense box (given by the DHCP server on your pfSense portal interface !!)

Btw: This is a golden rule:
Any client that uses a STATIC IP on his device, and complains to you that YOUR portal isn't working, well:
KICK him OFF your network - send him away - just ignore him - stop explaining that "static IP's are OK when you're he's home - everywhere else on the world one should activate DHCP, or, well, I don't explain them any more." ;)

cmb

@Derelict:

@fableman:

Thanks!!!

I changed my firewall rule to allow port 8002 instead of 8000 for the WIFI network and now I see users get into the portal again.

If they change port like that they should have a "head up" for it :)

I agree. https://doc.pfsense.org/index.php/2.2_New_Features_and_Changes#Captive_Portal

guess they didn't see it was important enough for the upgrade guide, but it's in the release notes.

It does warrant more of a heads up, that was an oversight. Added a note to the upgrade guide as well.
https://doc.pfsense.org/index.php/Upgrade_Guide#Captive_Portal_Port_Change

Derelict

Thanks. That still doesn't make it entirely clear that your port 8000/8001 portal is going to be changed to 8002/8003, etc.