@themistocle221 said in Captive Portail on cloud:

Si oui quel technologie utiliser pour faire la liaison entre le serveur pfsense distant et les utilisateur local.

Hummm.
You should 'bridge' (L2 only) the link between the local users and the RFC 1918 style IP uses by pfSense 'in the cloud'.
That is : no router(s) between your users and pfSense. This excludes, among others, a VPN uplink.

The real answer is probably : the question is to difficult, the answer will be worse.
A portal should be handled and setup locally.

Btw : you are aware of the fact that you're posting in the English section of the forum ?

5e246443-9a8a-4f82-a61c-d94a44adc53e-image.png

In that forum the most incredible questions are asked, only being surpassed by the answers, if possible.

When "sql" is used, the test.log should confirm this :

@anand_phulwani said in Captive portal + FreeRadius: How to use same user login on limited number of devices concurrently.:

radiusd -X >> test.log

You'll be seeing lines being loaded at startup like :

including configuration file /usr/local/etc/raddb/mods-enabled/sql including configuration file /usr/local/etc/raddb/mods-config/sql/main/mysql/queries.conf including configuration file /usr/local/etc/raddb/mods-enabled/sqlcounter including configuration file /usr/local/etc/raddb/mods-config/sql/counter/mysql/dailycounter.conf including configuration file /usr/local/etc/raddb/mods-config/sql/counter/mysql/monthlycounter.conf including configuration file /usr/local/etc/raddb/mods-config/sql/counter/mysql/noresetcounter.conf including configuration file /usr/local/etc/raddb/mods-config/sql/counter/mysql/expire_on_login.conf .......... .......... simul_count_query = "SELECT COUNT(*) FROM radacct WHERE username = '%{SQL-User-Name}' AND acctstoptime IS NULL" simul_verify_query = "SELECT radacctid, acctsessionid, username, nasipaddress, nasportid, framedipaddress, callingstationid, framedprotocol FROM radacct WHERE username = '%{SQL-User-Name}' AND acctstoptime IS NULL"

which are used for connection counting.

These

(0) files: users: Matched entry DEFAULT at line 1 (0) files: users: Matched entry DEFAULT at line 387 (0) files: users: Matched entry x at line 390

Line 1 :

DEFAULT WISPr-Redirection-URL := "https://www.google.com/" Fall-Through = Yes

and line 387 :

DEFAULT Simultaneous-Use := 2 Fall-Through = Yes

Line 390 : my user :

"x" Cleartext-Password := "x"

When the user logins in, using this option in the portal settings :

5a1fc198-7d94-487d-85e5-883f4442403f-image.png

the number of connected users is counted :

(10) sql1: Executing select query: SELECT COUNT(*) FROM radacct WHERE username = 'x' AND acctstoptime IS NULL

and it's the result of this query that is used against "Simultaneous-Use".

( I guess )

By the time a user reaches Captive Portal they already have an IP address. You can't reassign them address after Captive Portal login. It's too late.

To assign IP addresses to a user via RADIUS on a local network you need L2 access control like 802.1x -- in your switches/APs, not the firewall.

Hi,

This works for me :

In the captive portal settings :

339a85b0-51c4-4f4d-93d7-efa65d66d29f-image.png

and

357d3ba8-d917-4464-9392-b397718182a6-image.png

This is a user setting a FreeRadius :

13a4f8a3-0e75-4dcb-a21c-5c78273f8a09-image.png

a speed test confirms the half mega bit speed.

Hi,

You want to 'reset' the TTL info in the coming-back traffic, initiated by the portal visitors, to 1, so it should be discarded by the next hop, or, the device acts as a router / shares the connection.
All returning packets have to be somehow mangled.
That would actually work I guess.

But first you have to write that stateful firewall, or modify an exiting one, that actually permits you to do so.

Look here, from 2005 : https://lists.freebsd.org/pipermail/freebsd-net/2005-April/007098.html

edit : pfSense, the captive portal, uses ipfw. All you need is that user-land program.

Already done by default :
log.JPG

@colleytech said in captive portal requires login again from ptp end:

when you look at the active voucher list, your device mac will not be registered, instead, the mac of the M5 will be registered.

Your "point to point" connection to the other side of the road introduced a router in the circuit.
In that case, the portal only sees the IP and MAC of that router, not the IP and MAC of the connected client device.

You're probable using some AP on the other side that is a client to your local Wifi acces point, and behaves as a router.

I advise you to use AP's that use a Wifi distribuiton called "WDS".

@eroji said in Captive Portal shows 404 post login after upgrade to 2.4.5:

It appears to be configuration problem, possible as a result of the upgrade

The upgrade didn't change the configuration settings.
What did change is the way how redirecting was applied. This is the way thing were done before ( 2.4.4-p3 and before) :

First, if "After authentication Redirection URL" (= $cpcfg['redirurl']) is set, the redirect URL is set to that.
If not, if the initial request ( == $orig_request) exists, the browser will get redirected to that site/page.
If not, if a browser REQUEST URL contains "redirurl" as a parameter,, then that gets used.

Test 1 forces the visitor to be redirected to the "After authentication Redirection URL" URL.

With 2.4.5 that changed :

First, if the initial request ( == $orig_request) exists, the browser will get redirected to that site/page.
If not, if a browser REQUEST URL contains "redirurl" as a parameter,, then that gets used.
If not, if ""After authentication Redirection URL" (= $cpcfg['redirurl']) is set, the redirect URL is set to that.

So, "After authentication Redirection URL" only gets used if the first 2 test are false.

Note : test 1 seems a bit awkward. $orig_request == $_REQUEST['redirurl'] is tested (grep) for the string "redirurl=(.*)", or it should contain an URL, not something like "redirurl= http://captive.apple.com/hotspot-detect.html" - I guess this test always fails ....
Test 2 is (nearly) always going to be true because the visitors browser will use an initial test "http" URL - iPhone = http://captive.apple.com/hotspot-detect.html so, after ID ok, it should be directed to this URL ...

Btw : this new behaviour, IMHO, is not what the description tells us :

Set a forced redirection URL. Clients will be redirected to this URL instead of the one they initially tried to access after they've authenticated.

test 3 will use the "After authentication Redirection URL" URL. I guess this will happen if the user is visiting the captive portal the explicit way, using an URL like

http://1.2.3.4:8002/index.php?zone=cpzone

where 1.2.2.4:8002 is your pfSense portal interface and port
cpzone = the captive portal zone name.

Note : the nginx redirection logic :

if ($http_host ~* 1.2.4.4) { set $cp_redirect no; } if ($http_host ~* yourportal.pfsense.tld) { set $cp_redirect no; } if ($cp_redirect = '') { rewrite ^ /index.php?zone=cpzone1&redirurl=$request_uri break; }

side note :

if ($cp_redirect = '') {

is bad and makes nginx throwing out a warning : a variable is used with initing it first.
Somewhere higher up in the config this should be there :

set $cp_redirect '';

end side note.

For myself, I didn't notice this behaviour, because I'm using FreeRadius as an identification source, and in that case, the Redirection URL is taken from FreeRadius and handled the 'correct' way.

@Aubin any solve?

@Gertjan Thanks Mate!!

after trying a lot of things, I removed the allowed IP address in the captive portal and it worked...

Anyways, thanks for the help!

Your soonest HELP is highly appreciated

How is this captive portal related ?
The captive portal is not a package, it's build in natively.

@Gertjan said in Hard timeout doesn't work:

pfSense Ultimate Manual

thanks for that (https://docs.netgate.com/manuals/pfsense/en/latest/the-pfsense-book.pdf)

it shows a little more detail on the hard timeout. And mentions radius. It looks like it actually should work regardless of authentication method...

I found under the CP authentication section there is a Session timeout check box for "Use RADIUS Session-Timeout attributes"

If I disable this the hard timeout works with freeradius! cheers

@guntery said in Captive portal manual logout page address:

uh? It logs out the user who goes to that page not all users.

I stand corrected.
Had to review the script and true, the caller gets logged out.
Sorry for the noise ^^

Thanks for the reply Gertjan, I appreciate the help. I ended up just looking through the PFSense source and using their passthrumac functions. I saved the following in /etc/phpshellsessions/myscript and call it with pfSsh.php remotely. It's working for me so far, at some point I'll need to write a second script for removing macs as well.

# Playback script to add a passthrumac # Usage: playback [this_script_name] [mac_address] [description] # Note: description can't have spaces in it. # Setup require("captiveportal.inc"); global $cpzone, $argv; $cpzone = 'guest'; $mac = array(); $mac['action'] = 'pass'; $mac['mac'] = $argv[3]; $mac['descr'] = $argv[4]; # Add MAC to config file $config['captiveportal'][$cpzone]['passthrumac'][] = $mac; # Unlock for editing unlock($cpdblck); # Generate firewall rules, write firewall rules from lines in temp file $macrules = captiveportal_passthrumac_configure_entry($mac); file_put_contents("{$g['tmp_path']}/macentry_{$cpzone}.rules.tmp", $macrules); mwexec("/sbin/ipfw -q {$g['tmp_path']}/macentry_{$cpzone}.rules.tmp"); # Update config file $writecfg = true; write_config(gettext("Captive Portal passthrumac configuration changed"));

I found some help in this thread. If I was writing this script from scratch I'd probably make some changes but I left it as close to the original PFSense source as possible.

@Gertjan when I select an interface, and try to save, I get an error: "you need to select at least one authentication server"

Edit: I had to click on "Local Database"to select, and then was able to save. I will try if the Captive portal is working now

@guntery said in Captive portal redirect pointless on Android system browser:

Does Apple do the same?

Now way. 'They' have the portal thing working well for many years now.
As does Microsoft with it's "Windows" OS's.

When you set up this :

da9a2fcd-f01a-4eab-b902-b6dd6ff772e9-image.png

then after a successfully identification the visitor is ones more redirect to that URL.
Or, by default, to the URL which the browser initially wanted to load.

@jaspras
Can you help me with the settings for accounting with MySQL database?

Oops sorry about the false alarm - it turned out being a browser cache issue .. amateur hour :)