@jetberrocal:

…..
Shell Output - ipfw -x 2 table all list
....
---table(100)---
192.168.56.1/32 0

Note: the pfsense IP is 192.168.56.1/24, don't know why table(100) has 192.168.56.1/32

Because this is THE DNS (and gateway) exposed to the visitors - it better should be open so info directed to it (TCP, UDP as DNS) passes to the portal.
Without it, all breaks down.

Your DNS is not pfSense but some domain controller. Ok - seems possible to me, and in that case it's IP (the DNS) should be on the "Ok -> pass list", tab 2 or 3 off the Captive portal settings page.
DNS resolution, when connected to the captive portal network, before authenticating, should work.
And : your clients should obtain this IP when doing a DHCP request.

edit :

–-table(3)---
192.168.56.0/24 2000
---table(4)---
192.168.56.0/24 2001

Styrange to see a network range here …. I always saw IP's a.b.c.d/32

Important : 2.4.2 uses a new ipfw : commands have been changed.
Instead of something like

ipfw -x zone1 table all list

you just use :

ipfw table all list

Like :

[2.4.2-RELEASE][admin@pfsense.brit-hotel-fumel.net]/root: ipfw table all list --- table(cp_ifaces), set(0) --- sis0 2100 37325185 24618774112 1512502144 --- table(cpzone1_auth_up), set(0) --- 192.168.2.59/32 10:08:b1:fc:1e:f3 2090 214274 14772741 1512502143 192.168.2.82/32 58:48:22:6d:42:5d 2086 2079 451586 1512501887 192.168.2.89/32 34:e2:fd:8e:fb:ab 2088 51716 2950375 1512502144 192.168.2.125/32 d0:a6:37:9c:a6:18 2094 3657 333132 1512500905 192.168.2.136/32 58:fb:84:7b:ce:97 2084 67268 26306433 1512502120 192.168.2.143/32 8c:f5:a3:82:82:8a 2092 21620 12444173 1512502139 --- table(cpzone1_host_ips), set(0) --- 192.168.2.1/32 0 6659422 231934073 1512502144 --- table(cpzone1_pipe_mac), set(0) --- 64:80:88:99:9f:6c any 2075 8173 5291629 1512044939 any 64:80:88:99:9f:6c 2074 7848 2035912 1512044939 --- table(cpzone1_auth_down), set(0) --- 192.168.2.59/32 10:08:b1:fc:1e:f3 2091 307250 344511258 1512502144 192.168.2.82/32 58:48:22:6d:42:5d 2087 2106 1383269 1512501887 192.168.2.89/32 34:e2:fd:8e:fb:ab 2089 96353 139312244 1512502139 192.168.2.125/32 d0:a6:37:9c:a6:18 2095 4692 5860415 1512501180 192.168.2.136/32 58:fb:84:7b:ce:97 2085 79171 38729751 1512502119 192.168.2.143/32 8c:f5:a3:82:82:8a 2093 22295 14812322 1512502116 --- table(cpzone1_allowed_up), set(0) --- 188.165.53.87/32 2084 5889 3757968 1512493220 192.168.2.2/32 2076 590 61194 1512501902 192.168.2.3/32 2078 462 43154 1512501390 192.168.2.4/32 2080 0 0 0 2001:41d0:2:927b::3/128 2084 0 0 0 --- table(cpzone1_allowed_down), set(0) --- 188.165.53.87/32 2085 8453 744349 1512493220 192.168.2.2/32 2077 146 11096 1512501436 192.168.2.3/32 2079 148 11248 1512501390 192.168.2.4/32 2081 0 0 0 2001:41d0:2:927b::3/128 2085 0 0 0

cpzone1_auth_up and cpzone1_auth_down contain the info from the devices used by clients:visitors actually logged in - 5 in this case.

cpzone1_allowed_up and cpzone1_allowed_down contains IP's of the addresses I entered my self on the related tabs on the captive portal setup page. These have access / are accessible without portal authentication.
Note : 192.168.2.2 - 192.168.2.3 -192.168.2.4 are my AP's

Table cpzone1_pipe_mac is contains the MAC of a guy I gave direct access without using any authentication.

Table cpzone1_host_ips should contain the DNS server for my clients/visitors.

Btw : names of tables also changed :

[2.4.2-RELEASE][admin@pfsense.brit-hotel-fumel.net]/root: ipfw list 01000 skipto tablearg ip from any to any via table(cp_ifaces) 01100 allow ip from any to any 02100 pipe tablearg ip from any to any MAC table(cpzone1_pipe_mac) 02101 allow pfsync from any to any 02102 allow carp from any to any 02103 allow ip from any to any layer2 mac-type 0x0806,0x8035 02104 allow ip from any to any layer2 mac-type 0x888e,0x88c7 02105 allow ip from any to any layer2 mac-type 0x8863,0x8864 02106 deny ip from any to any layer2 not mac-type 0x0800,0x86dd 02107 allow ip from any to table(cpzone1_host_ips) in 02108 allow ip from table(cpzone1_host_ips) to any out 02109 allow ip from any to 255.255.255.255 in 02110 allow ip from 255.255.255.255 to any out 02111 pipe tablearg ip from table(cpzone1_allowed_up) to any in 02112 pipe tablearg ip from any to table(cpzone1_allowed_down) in 02113 pipe tablearg ip from table(cpzone1_allowed_up) to any out 02114 pipe tablearg ip from any to table(cpzone1_allowed_down) out 02115 pipe tablearg ip from table(cpzone1_auth_up) to any layer2 in 02116 pipe tablearg ip from any to table(cpzone1_auth_down) layer2 out 02117 fwd 127.0.0.1,8002 tcp from any to any dst-port 80 in 02118 allow tcp from any to any out 02119 skipto 65534 ip from any to any 65534 deny ip from any to any 65535 allow ip from any to any

@blsevidal:

what could be the problem..

Can't tell.
Can not see your setup.
Have no idea how your network is interconnected.
Don't know what this has to doe with your captive portal.

@liver007:

Purpose: we wan't to create AP in our friendly company but have AUTH/ Captive Portal setup at our location. Possible ways to connect are VLAN/VPN. Is there an option to not pass all that traffic after auth thru our pfSense server?

Captive portal authorized traffic has to go through pfSense (a firewall), that's how the captive portal works.
A switch, even one with VLAN capabilities, can't handle that (it isn't a firewall)

@AYSMAN:

…..
I've noticed in pFsense version 2.4.2 the Portal URL is
https://guestportal.net:8003/?zone=guestportal on earlier pfsense version it was only like https://guestportal.net:8003

Yep, that's normal.
pfSense supports more then one captive portal, each being called a "zone".
This was implemented a couple of versions ago (2 years or so).

@AYSMAN:

The problem is when a client wants to log out and they typed into the browser address bar guestportal.net instead of being redirected to the log out page of the captive portal, the browser gets redirected instead to pfsense log in page on that interface.
Did I miss something in the set up?

Yep. People should not have type in the address. To complicated - they WILL make errors. They should "accept" a popup windows (they actually never allow pop up in there browsers …. as you already know). The logout popup is send to the client when connecting, and if they really have a good reason to disconnect "by hand" they shouldn't close this window (and logically, accepts popup from your portal interface : so what about telling them when they login ?  ;)) - and they could use it when needed.

One Captive portal per interface or VLAN.
These can't, of course, have no overlapping networks addresses.
Editing files like "nginx-zone103-CaptivePortal.conf" is useless, they are created on the fly when the service starts or restart. All info is stored and use from /conf/config.xml (which, also, should NOT be edited by hand, but by the GUI).

Well, you're operating a firewall, right ?!
What about disabling the default auto-lockout rule - and activate a hand made firewall rule on the LAN interface ?!

I never used a VLAN-aware switch, but I assume that if you setup your switch correctly, people can even use the LAN network, thus connecting to the GUI.
Others interfaces : a firewall rule.

Added to that, a captive portal should be run on its dedicated interface (VLAN, or more simpler : OPT1).
The hostname is communicated by the device when DHCP handshaking takes place, but know that a device doesn't have to communicate one.
Also note that IP's, MAC's and host names can be fakes because user (== read : visitor) editable.

The rules set for ipfw (ipfw is only use for the captive portal) is hard coded into the captive portal software.
These rules are non-user editable and normally you don't need to change them except if a total breakage is what is wanted.
YOUR rules should be put in with "pf" and this one can be edited with the GUI - just select the interface that the captive portal is using.
Best is that you use a dedicated interface (OPT1) for the captive portal - leaving the LAN for trusted devices only.
By very nature, a captive portal network IS for non-trusted devices (visitors).

Said that, know that when you add IP's and MAC's that should pass through without hitting the captive portal, their rules are added to ipfw.
Se the help page mentioned above, you can see all the ipfw rules and tables.

and also, kindly provide a sample schema where the vouchers will be uploaded.

Thanks in advance

Hi,

The 'captive portal login page', as the 'error page' and the 'logout page' are stored in this file : /conf/config.xml
All the other "user files" are also stored in /conf/config.xml

When the captive portal starts, a working copy is extracted here : /var/etc/
You will find files like
captiveportal_your-zone.html
captiveportal_your-zone-error.html
captiveportal_your-zone-logout.html

User files (working copies) are stored here : /var/db/cpelements/ and sym linked from the web root dir : /usr/local/captiveportal

@bulgurcu:

Yes.

radacct add columns

acctupdatetime datetime DEFAULT NULL,
  acctinterval varchar(255) DEFAULT NULL,

Hi. Thanks again. I got freeradius3 to send accouting data to MySQL. May I ask if you have any idea why my simultaneous use attribute is being ignored by freeradius3?

:o

Captive portal traffic flows through the firewall (pfSense) - an interface and then to the WAN, and back.

No way you can have what you ask (implies also the changing the gateway the visiting device that it became from pfSense, etc).

If you update the pfSense FreeRADIUS 3.x package now (To 0.15.3) it will calculate the bandwidth values the same as Captive Portal so it will not trigger the issue

Need a lot more detail here.

Is the RADIUS server on pfSense? Or somewhere else?

If it's on pfSense, did you complete the transition to FreeRADIUS 3.x? Is the RADIUS server process running? Any errors in the logs?

If it's on another system, how do you reach it? Locally or over a VPN? Is that connection still working?

Great. Thank you!

Yeah, while the Mac filtering worked fine, we ended up moving all the infrastructure items to a different, private subnet.  Not only was remote access made easier, bandwidth was improved.

@awahbi:

How can I get rid of the old versions?

How ?
An update overwrite all old files - removes stales (unused files).
It's like a Windows PC : when upgrading from Windos 7 to 10, nothings is left from "7".

@awahbi:

Shall I make a fresh installation of 2.4.1 then restore the configuration?

Think about this :
YOUR copy of pfSense - and mine, are THE SAME.
The only thing that is different is … the setup (and of course, packages that can break native behavior).
I'm using a plain vanilla setup, my MAC limiter for the captive portal works. I'm using the built in User Manger - no Radius, No squid - no nothing else.

You can try this :
Re install.
Make the captive portal work with built in login page and a User Manger user.
Set the MAC limiter on the captive portal setup page.
Test - login and see that it works.
Now, add you other settings one by one.
As soon as the MAC limiting doesn't work anymore you know where you can find the issue  - and report back.