Hi,

Added to this : https://forum.pfsense.org/index.php?topic=84800.msg465167#msg465167 : use a dedicated (third)  interface for the Portal interface and hookup all the wifi access to it.

Hi,

What are your portal setting ?
I'm nothing using vouchers myself, just toying with them ones in a while.

When vouchers are used - and accepted, the MAC address of the authenticated device is put in a table in the firewall that runs on the captive portal.
From then, for the time the voucher is valid, that device/visitor will pass through. This rule will be removed when the time is up (duration of the voucher).

The visitor could take a world trip, but when he comes back, and there is still time left, his MAC will be there in the firewall table, and he can access the net using your portal just fine.
No need to re-authenticate.

Note : the voucher-timer will not stop while the visitor is on his world trip !

Check :
When a visitor uses a voucher (authenticate), can you see the MAC in the log and status in pfSense ?
When he comes back, the MAC is still there ? His MAC is still the same ?

Yep, I installed pfSense 2.3.5 and set everything up, runs flawlessly, thanks for the help everyone, hope my bug is just random and will be automagically fixed in the next update :D

There is another thread going on about filterdns.

I have mine running on Chelsio 10GBASE-CX4 S320E-CXA 10GbE adapter and everything is working well for me. I am using :

2.4.3-DEVELOPMENT (amd64)
built on Tue Dec 19 18:22:48 CST 2017
FreeBSD 11.1-RELEASE-p6

Which seems to be working well. Don't know if your environment will allow you to run a development branch but it is running very stable and I have not had any issues other than Captive Portal authenticating against LDAP but looks like that will be fixed soon. See https://github.com/pfsense/pfsense/pull/3640

Good !

This is probably a small bug then - consider it squashed.

edit : notified : https://redmine.pfsense.org/issues/8238

What about this one :
@Gertjan:

…...
IF MAC & IP are the same they can not hit the portal login page, because ipfw firewall rules are letting through the connection.
So, next question :
Use this https://doc.pfsense.org/index.php/Captive_Portal_Troubleshooting and check the tables to see if MAC and IP are there - they should be there, except if hard or soft time out event removes them.

?

@asy67:

….
however, when user try to browse 192.168.10.1 during its session, the admin page(pfsense) is appeared. how am i going to avoid the view the admin page while they on their session?

Any device hooked up on the LAN can access the GUI - that is normal and by design, all "truisted devcies" should live on LAN, non-trusted devices should use other interface OPT1, OPT
, etc.
Typically, a captive portal is sued by non-trusted devices, you found out the exact reason why, normally, captive portakl should be set up on a OPTx interface.

Visit System => Advanced => Admin Access anc check the "Anti-lockout" checkbox. If it isn't checked, some hidden rules even permits all the time this access from any devices on the LAN.

When this is unchecked, access to the webConfigurator on the LAN interface is always permitted, regardless of the user-defined firewall rule set. Check this box to disable this automatically added rule, so access to the webConfigurator is controlled by the user-defined firewall rules (ensure a firewall rule is in place that allows access, to avoid being locked out!) Hint: the "Set interface(s) IP address" option in the console menu resets this setting as well.

However, what you really need, is a firewall. And, good news, pfSense is a firewall. So, it's becomes a matter of setup up some rules and your done.

I advise you to :
Add a static DHCOP lease for YOUR PC, the device you trust, the device you use to admin pfSense. This way, your device will always receive the SAME IP.
Then, add a rule on the LAN interface that accepts connections coming from your device (== source == IP from your device) to pfSense (destination == "This firewall"), destination port 80 or 443 (in case of https GUI access).
Right after this rule, put in place a block rule, source = Any, destination "This Firewall, destination port 80 and/or 443.
Third rule : put in place an "any to any rule" (for testing purposes only).

After this third rule are your other LAN captive-portal-related rules.

Validate your rules

Then, visit System => Advanced => Admin Access and remove the check for "Anti-lockout" !

Test now, and see that these rules work - use YOUR PC, check that the IP is ok (release and renew your IP to get the right one, the one you are using in your rules !) and that you can login from your PC.
Use ANOTHER "untrusted" PC, login to the portal, and check that you can NOT login - BUT that you are using the third (pass-all) rule.
The counters in front of the rules shown in the GUI-Firewall-LAN will show the rules are used.

If all si ok, remove this third rule - your are using a captive portal, your other firwall rules follow

See image. The "192.1638.1.6" is my trusted IPv4 (2001:470:1f13:5c0:2::c6 also) and as you can see the counters in front of the rule IPv6 work, because I' using IPv6. This is why I have 2 rules. I could also use an Alias for those 2 IP's and combine IPv4+Ipv6 as a rule. Note that I'm using only https access, so only port 443.

FWR2.PNG_thumb
FWR2.PNG

Hi,

Auto MAC adding exists - see captive portal setup page (and doc). So when you choose a existing authentication system, you are fine.
LADP isn't mentionned on that page, so … well .. no.

But, you should follow - well, better : help with this : https://github.com/pfsense/pfsense/pull/3640 which is probably what you are asking for.

When I used them I used a 31-bit RSA key for shorter codes and never saw a problem. I was not issuing "lots" of vouchers though. Rolls of 100 usually.

thanks again
thats what the webinterface showed for updating.
tomorrow i will go further up until latest stable… users dont like internet downtime ;)

--
no, entrusted devices use peap without captive portal. The new captive Portal site is for private devices. its a "present" from the Management

Hello krashneo

I can't find the file /usr/local/etc/raddb/ldap.attrmap
Can you help me?

@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.