@Drudge : reinstall from scratch (boot from a recent version like 2.2.6 - not a dead one 2.0.2 or even 2.1). Redo your settings. When activating the portal, do NOT use your own 'html' code, use the default. Activate first the local user Manager (build in pfSEnse) and add one or two users. Test that. Then hook up Radius, and test again. Then , and only then : use your own html login page (If you have one). I guess something goes wrong with the redirecting … Some left-overs in the ancient config settings (maybe) ?

You are right , sorry for that , just wanted to discuss it with captive portal experts as well :)

@cs1: I've seen that the topic of MAC or IP spoofing has been addressed plenty of times with respect to the captive portal and most of the time, the result was: "you can't do anything against MAC/IP spoofing". However, there seems to be an elegant solution included in Zerotruth (CP on top of Zeroshell) that significantly reduces the risk of MAC or IP spoofing by using a technique that the Zerotruth guys call "Authenticator packet". You can't do anything (good at least) at the firewall level. That Zerotruth hack is ugly and only prevents hijacking sessions that aren't currently connected, which isn't all that useful. You're not going to stop someone good enough to hijack sessions (unless it gets down to 0 active sessions), and there's a good chance you'll introduce problems for legit users. Your APs and switches are where you can prevent that type of thing in a useful way (where the equipment has such functionality).

I saw that and not sue what it is from.  I do have a redirect URL entered but not sure if that's what was causing this issue.  The same redirect URL is there in my now working config.  I have not had any issues so far sine I killed the process and restarted the captive portal.

We have some plans here already: https://redmine.pfsense.org/issues/3882

;D All this, and more, is actually easy to find if your 'read' /etc/inc/captiveportal.php You will even find this: https://github.com/pfsense/pfsense/blob/RELENG_2_2/etc/inc/captiveportal.inc#L187 (this is the 2.2.7 dev version - and the same as 2.2.6) : Read it like this: If Captive portal enbaled If Booting   then delete the database file ..... Also : a nasty bug was found when opening and managing the "sqlite3" database - this was one of the reasons why "2.2.5-Release" is ancient now, and that 2.2.6 came out ;) Reading /etc/inc/captiveportal.php will show you that other files exist (in the same /var/db dir) : captiveportaldn.rules and captiveportal_<name_of_cp>.rules These two files ARE deleted when the captive portal starts up. These two files are NOT used to (re) preset the firewall after booting.</name_of_cp>

In any case make a backup of your config NOW and store it in a safe place. After that reboot your machine and if it comes back alive perform the update through the GUI.

Have you tried to change in CP the MAC-Adress-sending format ( i.e. "Default" or "ietf" ) to the one your radius server expects. https://doc.pfsense.org/index.php/Using_Captive_Portal_with_FreeRADIUS "Captive Portal configuration Enable RADIUS MAC authentication Enter any shared secret desired. This field must not be empty! but it is not important what is entered. This is not the shared secret which is used for communication between NAS(CP) and the FreeRADIUS server. I used blaaa MAC address format. In general this may be left at default or any other option because FreeRADIUS is converting the MAC address (Calling-Station-ID) into the correct format. To be 100% correct choose here ietf "

@biomecanoid: one more thing that doesnt work is redirection, meaning that when user type a URL like www.google.com they must be forwarded to the login page which now doesn't happen Can voucher work with 'size' instead of 'time' ? The reply is : No. Redirection : Do you mean : http://www.google.com or https://www.google.com ? When I'm opening a browser which has a default home **http://**www.google.com then I will be redirected to the login page. If this doesn't happen on your setup, then something is wrong. DNS probably …. Detail your setup.

@shockwavecs: …. TLDR; how do I remove MAC additions from the CP via a remote call (POST) or a simple command line call? Command line using a script ?! Check out /etc/inc/captiveportail.inc and files like /usr/local/www/services_captiveportal_mac.php Everything is there so you can write a small php file that iterates over all auto-added registered MAC.

No, I'm not. Just web configurator and captive portals. But I agree with you, it is to messy. I'll just reinstall and reconfigure pfSense when the time is right.  Thank you for your time.

I solved something. I enabled authentication with a local user and Enable Pass-through MAC automatic additions

Hi guys, I have the same problem but I could't solve. CP with local user authentication and "Enable Pass-through MAC automatic additions", squid3 not work (trasparent e non trasparent mode) All requests are managed nly by CP , but i want: clients–-->CP----->Squid3&SquidGuard(Trasparent Mode)----WAN anyone can help me?

Please follow this post, it is what you want. https://forum.pfsense.org/index.php?topic=89869.msg497777#msg497777

Hi Gertjan & CMB Thanks for your valuable inputs. As suggested I have made a clean install of 2.2.6 and no more database locked errors are found. Then I changed 2.2.6 captiveportal.inc & index.php for manual logout page as mentioned in https://forum.pfsense.org/index.php?topic=77143.0 Everything is working fine now with manual logout page. Earlier when i upgraded to 2.2.6, I used to copy modified captiveportal.inc & index.php from version 2.2.4 to get manual logout page. I didnt modify 2.2.6 version captiveportal.inc & index.php for manual logout page. So that's why I was getting database error after upgrading to 2.2.6. Sorry, it was my fault, I should have made changes to 2.2.6 version captiveportal.inc & index.php files to get logout page. Thanks & regards

apparently now is working fine. after of 14 days any restart of database. thanks

You should know all about the Google Authentication API. The PHP language shouldn't have any secrets to you. You need to be an pfSense user AND know how pfSEnse is written and works … Then you could consider implementing your needs. I think your next best solution will be : post a message here Post a bounty but read the how-to-post first.

I change some of my passwords weekly, but this could just as easily be done every day if need be. I keep a list of passwords in a text file, with one password on each line. I use a short script (rotatefile.sh) on the RADIUS server to pick up the password from the top of the file and put it at the bottom: #!/bin/sh Take first line of wordfile pw=head -n 1 /root/wordfile.txt echo "$pw" Delete first line in wordfile sed -i 1d /root/wordfile.txt Append wordfile with word taken from top echo $pw >> /root/wordfile.txt I then call this script from within another script which picks up the password from the file and uses it to update the entry for that login on the RADIUS server. Whether you use a flat-file or a SQL backend, either way it works: t4=/root/rotatefile.sh The t4 environment parameter can then be used to perform a 'sed' change on your users file or be parsed into your SQL database. As Derelict has suggested, you can post the username on the form itself if you need to.

I've modified the setup so we now use 2 VM's; 1 for the setup of VPN, and 1 with a LAN interface to run CaptivePortal on: [image: gre_captiveportal2.png] Will this setup still work? It seems the MAC addresses from the client devices (10.30.0.0/16) are dropped for the traffic that flows through the VPN tunnel. The DHCP requests however are still done with correct source MAC. A followup question; the traffic flows through both VM's, ping works correctly: [2.2.6-RELEASE][admin@HopprVPN.trin-it.nl]/root: tcpdump -netti le1 host tweakers.net tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on le1, link-type EN10MB (Ethernet), capture size 65535 bytes capability mode sandbox enabled 1451471556.841142 00:50:56:01:26:5e > 00:50:56:01:27:ca, ethertype IPv4 (0x0800), length 74: 10.30.0.10 > 213.239.154.20: ICMP echo request, id 1, seq 1127, length 40 1451471556.842799 00:50:56:01:27:ca > 00:50:56:01:26:5e, ethertype IPv4 (0x0800), length 74: 213.239.154.20 > 10.30.0.10: ICMP echo reply, id 1, seq 1127, length 40 1451471557.850062 00:50:56:01:26:5e > 00:50:56:01:27:ca, ethertype IPv4 (0x0800), length 74: 10.30.0.10 > 213.239.154.20: ICMP echo request, id 1, seq 1128, length 40 1451471557.851729 00:50:56:01:27:ca > 00:50:56:01:26:5e, ethertype IPv4 (0x0800), length 74: 213.239.154.20 > 10.30.0.10: ICMP echo reply, id 1, seq 1128, length 40 1451471559.059122 00:50:56:01:26:5e > 00:50:56:01:27:ca, ethertype IPv4 (0x0800), length 74: 10.30.0.10 > 213.239.154.20: ICMP echo request, id 1, seq 1129, length 40 1451471559.060913 00:50:56:01:27:ca > 00:50:56:01:26:5e, ethertype IPv4 (0x0800), length 74: 213.239.154.20 > 10.30.0.10: ICMP echo reply, id 1, seq 1129, length 40 1451471559.999093 00:50:56:01:26:5e > 00:50:56:01:27:ca, ethertype IPv4 (0x0800), length 74: 10.30.0.10 > 213.239.154.20: ICMP echo request, id 1, seq 1130, length 40 1451471560.000694 00:50:56:01:27:ca > 00:50:56:01:26:5e, ethertype IPv4 (0x0800), length 74: 213.239.154.20 > 10.30.0.10: ICMP echo reply, id 1, seq 1130, length 40 But on return for TCP traffic the LAN interface on the first VM returns 'host unreachable' for the client device (and TCP traffic is never returned to the client device): 1451471585.431692 00:50:56:01:26:5e > 00:50:56:01:27:ca, ethertype IPv4 (0x0800), length 66: 10.30.0.10.61580 > 213.239.154.20.80: Flags [s], seq 4232436194, win 8192, options [mss 1160,nop,wscale 8,nop,nop,sackOK], length 0 1451471585.433843 00:50:56:01:27:ca > 00:50:56:01:26:5e, ethertype IPv4 (0x0800), length 66: 213.239.154.20.80 > 10.30.0.10.61580: Flags [S.], seq 2346278513, ack 4232436195, win 28960, options [mss 1160,nop,wscale 0,nop,nop,sackOK], length 0 1451471585.433878 00:50:56:01:26:5e > 00:50:56:01:27:ca, ethertype IPv4 (0x0800), length 94: 10.20.0.48 > 213.239.154.20: ICMP host 10.30.0.10 unreachable, length 60 1451471588.467043 00:50:56:01:26:5e > 00:50:56:01:27:ca, ethertype IPv4 (0x0800), length 66: 10.30.0.10.61580 > 213.239.154.20.80: Flags [s], seq 4232436194, win 8192, options [mss 1160,nop,wscale 8,nop,nop,sackOK], length 0 1451471588.468891 00:50:56:01:27:ca > 00:50:56:01:26:5e, ethertype IPv4 (0x0800), length 66: 213.239.154.20.80 > 10.30.0.10.61580: Flags [S.], seq 2346278513, ack 4232436195, win 28960, options [mss 1160,nop,wscale 0,nop,nop,sackOK], length 0 1451471588.468918 00:50:56:01:26:5e > 00:50:56:01:27:ca, ethertype IPv4 (0x0800), length 94: 10.20.0.48 > 213.239.154.20: ICMP host 10.30.0.10 unreachable, length 60 I think this is because the LAN interface has no knowledge of the traffic that's being returned, so it blocks the Syn/Ack packets. See also firewall logs: [img]http://www2.trin-it.nl/download/tweakers_syn_ack.png[/img] How can I solve this? Thanks for any help.[/s][/s]