I played a little bit with " configuring-a-pre-authentication-redirect-for-captive-portal-users ".

Using Pre-authentication redirect URL and doing what is stated here still redirect the user to another web server. - not the captive portal.

This should be edited :

<?php require("globals.inc"); $request_uri = urldecode(str_replace("/index.php?redirurl=", "", $_SERVER["REQUEST_URI"])); $portal_redirurl = urldecode("$PORTAL_REDIRURL$"); if(!stristr(urldecode("$PORTAL_REDIRURL$"), $request_uri)) { Header("Location: $PORTAL_REDIRURL$"); exit; } ?> [Rest of CP login page]

The line

require("globals.inc");

should be removed now, it's already included.

The line (URL) on the pre authed web server that takes the user back :

http://x.x.x.x:8000/index.php

should at least include ?zone=your_zone like :

https://your_portal_server.your_pfsense.tld:8003/index.php?zone=your_zone&......

https://your_portal_server.your_pfsense.tld:8003 for me because "8003" is the URL and port on which my https enabled portal server is listening.
?zone=your_zone because otherwise the portal web server will not know which zone the user is using.

and that where it ended for me right now.
I'm have this subject on my to-test list, but somewhat blocked by the fact that portal debugging means : I'm throwing out the user every time I try something.

I guess the original functionality of Pre-authentication redirect URL is still possible, but the doc should be updated a little bit.

Check also https://forum.netgate.com/topic/138019/allowed-hostnames-not-being-converted-to-ips

@julio-freire said in Issues with HTTPS in Captive Portal:

Has anyone faced this issue?

Yep. Probably. Don't recall very well. There was a path for it.
But, you already know what the real solution is.
As soon as you decide not to upgrade for what ever reason that is yours you also accept that you and only you are the one that makes thing work. Even if this implies rubbing out bugs.
The thinks is : who remembers 2.2.6 issues ? And why should we ?

Btw : start with this one : very old SSL code can't handle the recent certificates.
When you use the portal with https mode, you should use a certified certificate that a browser trusts out of the box. Which means your certificate is recent.

Thanks for your answer.

I've tested with a 2 NICs computer and ping can passthrough pfsense.

@free4 said in Upgrade from 2.3.x to 2.4.4, captive portal not working:

is your computer configured to retrieve DNS servers from DHCP? or did you force your computer to use 8.8.8.8 / 1.1.1.1 like many computer-fanboys?

the computer usually uses the pfsense as the dns server (dns resolver). Because of the restriction, not to fall back from https to http of visited sites a redirect was not possible. After someone connects to the network a notification is shown in the browser, to log somebody in. If someone closes this, he wouldn't notice that there is a portal to log in....

Ok great I'll have a look at that one.

Follow up: Does anyone still have the file Voucher-Template-Printer-2.4.0.zip to reupload here?

Thank you!

@free4 said in Blocked MAC Address redirect URL not working:

@h2professor Would it be possible for you to test the patch on your side and give feedback on the redmine issue? I'd like to to confirm that the bug is fixed

I can confirm that the code change solves this problem.
Thank you

I think I got it going. After upgrading to v.2.4.4 I downloaded the built-in portal.html and adapted it to work for me. the ones in the book didn't work.
thx for your patience with me.

@vukomir said in Captive portal:

and to answer one of your previous question why I specify Gateway for internet access, because if want that role to apply only to internet traffic and not allow access to other VLAN's/Networks

I understand.
My ... dono what, says that an alias to all other neworks, and negate that alias in the destination, is 'better".

@awaz said in Captive Portal Wifi Router Authentication:

I read many posts about it but didnt see anyone giving solution of it.

Between the device and pfSense-Captive portal there can't be any router **.
That why there is no solution. Because it isn't a problem ;)

In detail : if you use a router with Wifi facilities, like one of it's LAN NIC's is equipped with Wifi radio device, and you connect the upstream NIC (typically labeled as WAN or upstream on this router) then the captive portal would only see the IP of this routers NIC. NOT the IP of the client - neither the MAC.
So, everybody that connects to your router's Wifi, will be identified by pfSense with the same IP and the same MAC, the one on the router's WAN port.

And that is bad .....

You'll be seeing the typical "one user logs in, and after that it's a free ride for everybody else (many posts exists about this subject)"

So, use a simple AP, if it has DHCP : shut that down.
A router equipped with Wifi could be used, but, as said above, shut down NAT, DHCP server, etc. Make it look like a dumb AP and you'll be fine.

** well, you could do it. But it will break captive portal's basic operating rules.

@madcatza said in CaptivePortal - Random Time Outs:

however if I need to do that it would mean this is a bug, yes?

No way.
I tend to use the code as the manual for pfSense. When I understand the code, I know what the GUI settings do - and why things happens, under the exact condition.
I'm using the portal for many, many years now. People are disconnected when their device isn't communicating any more after 4 hours (my idle time setting). Or after 12 hours what ever happens - the hard time out.
Of course, you and me are not the only one using the captive portal. Thousands of others use it also.
If connected clients would be thrown out after one minute sharp, this forum would explode with messages from unhappy users.
The good new : this issue only happens to you.
Bad news : this issue only happens to you.

Global news : as you and we use the same software, only setup and settings are different.

Thus : what is your setup ? settings ? Explain us, and we'll explain how to correct it.

radius_authentication.inc and radius_accounting.inc have been removed. they have been replaced by two functions ( radius_backed() inside /etc/auth.inc for authentication, captiveportal_send_server_accounting() inside /etc/captiveportal.inc for accounting)

as long as you don't use RADIUS anywhere else, you could maybe update these functions.

However be careful : radius_backed() could be used by few other parts of pfSsense : openVPN module and IPsec Xauth module are using it for instance.

as long as you don't use RADIUS anywhere else, you could maybe update these functions.

See my topic:
https://forum.netgate.com/topic/137756/lost-captive-portal-files-on-v-2-4-4

See my topic:
https://forum.netgate.com/topic/137756/lost-captive-portal-files-on-v-2-4-4

Hi,

Your FreeRadius package needs a more recent pfSense version.
Upgrade pfSense to the latest version, 2.4.4.

I'm using several IP's on the Allowed IP Addresses tab :

0_1542001139172_a3916230-7078-4d26-9fff-bad151b2b41a-image.png

As you might guess, these are my 3 AP's - my Portal network is 192.168.2./24, pfSense using 192.168.2.1.
AP's needs access to the net for services like ntp etc.

My 3 Ap's can communicate with the net.

Btw : Captive portal ipfw firewall rules are :

[2.4.4-RELEASE][admin@pfsense.brit-hotel-fumel.net]/root: ipfw table all list --- table(cp_ifaces), set(0) --- sis0 2100 41929406 24022213886 1542001320 --- table(cpzone1_auth_up), set(0) --- --- table(cpzone1_host_ips), set(0) --- 192.168.2.1/32 0 10842951 645919014 1542001320 --- table(cpzone1_pipe_mac), set(0) --- 88:1f:a1:54:ff:c9 any 2081 0 0 0 any 88:1f:a1:54:ff:c9 2080 0 0 0 48:88:ca:41:ff:55 any 2075 0 0 0 any 48:88:ca:41:ff:55 2074 0 0 0 4c:8d:79:91:ff:52 any 2077 0 0 0 any 4c:8d:79:91:ff:52 2076 0 0 0 64:80:99:9a:ff:a0 any 2079 0 0 0 any 64:80:99:9a:ff:a0 2078 0 0 0 --- table(cpzone1_auth_down), set(0) --- --- table(cpzone1_allowed_up), set(0) --- 192.168.2.2/32 2082 785 77243 1542001221 192.168.2.3/32 2084 655 58796 1541999147 192.168.2.4/32 2086 635 78822 1541991852 --- table(cpzone1_allowed_down), set(0) --- 192.168.2.2/32 2083 234 17784 1542001221 192.168.2.3/32 2085 235 17860 1541999147 192.168.2.4/32 2087 233 17882 1541991000

(I have 5 MAC's on the MAC's list)

This works fin for the last decade or so.

You can, by disabling MAC address filtering, but it's not as secure since you don't have a direct L2 connection.

Someone would only need to hop to a new IP address to potentially gain access, whereas with MAC filtering they would need to correctly guess a valid MAC+IP address combination.