Hi, @eyp: I'm testing Captive Portal function but I dont understand how the user autenticated can navigate through the firewall. I think a better answer is possible  ;) If your captive portal is being called "zone1" (visible on the Status => Captive Portal page) then this command: ipfw -x zone1 table all list will list the tables with all permitted users. Table 1 and 2 contain the IP and MAC of every authenticated captive portal user .

Hello, @ChristianViana: I´d like to use the DHCP list to create a pass-through list on Captive Portal. I understand. The information put into the DHCP leases table can also be set on the pass-through-MAC tab on the Captive Portal settings page. @ChristianViana: Can I do this? I don't know  ;) You tried it ?

Hi, I use "Enable per-user bandwidth restriction" (checked) - using these settings: 2500 (Kbits upload) and 700 (Kbits download). It works pretty well for me, when I test speed limits with my iDevice. Slow portal behavior seems more a DNS issue to me. I remember seeing that when add MAC on the "pass-through-MAC" page, the speed settings over there aren't taken in account (bug ?!).

Hi, I am experiencing the same issue right now on my captive portal radius authentication setup. I am getting an error every time I try to re-login for the second time, first time produces an error. This is the error: Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 4294967295 bytes) in /etc/inc/radius.inc on line 446 I've tried to follow you "too long" secret key suggestion but it did not work for me. Anyway, maybe you have some other idea about what might be causing that error.

thank you Gertjan for your reply, user is connected to the internet after i tested your advice but a error page is appears after logging in :( anyway i tried another method by created a new page only contain a green right mark logo with done below then uploaded as (Logout page contents) and activated (Enable logout popup window) feature, it is working properly as i want . thank you again

@Gertjan: @gregoryzero: DHCP-server log shows this: dhcpd: send_packet: Permission denied Failed to send 300 byte long packet over bce1_vlan30 interface Well, that's clear enough. I guess: undo all the vlan-stuff and all starts working. Start digging in that direction. It seems, that everything will be easier… I applied the 2.1.4 update and it seems, that this issue has been resolved. Thanks everyone for help.

I can't think of how you would accomplish this without either… 1.) turning on DHCP at the access point 2.) adding another interface to pfSense to connect the AP to 3.) adding a managed switch and creating a VLAN (not sure steps, but think you could do it.) attaching the AP to the appropriate port.

Hi there. Your post is missing some info. What does this command show you: ipfw -x zone1 show and this one: ipfw -x zone1 table all list Note 'zone1' should be the name of your zone - as shown on the Service :: Captive portal or Status :: Captive portal Tell us a little bit more about your setup. While you're at it, 2.1.3 is old (login to pfSEnse and it will tell you so) => upgrade.

Hi, "offline generating" of vouchers as such is not possible, pfSense needs to now somehow which vouchers are valid and which are not… Maybe setting up a VPN to the pfSense-Box could help? Someone created a REST API for pfSense Vouchers (http://blog.digitalhigh.es/pfsense-voucher-rest-api/), you could build something on top of that, but you still need access to pfsense though… Best regards (or "Viele Grüße"  ;)), Eagle2

Hi. Yep, I think I know what you mean. When shifting to 2.1.3: 2.1.3-RELEASE (amd64) built on Thu May 01 15:52:13 EDT 2014 FreeBSD 8.3-RELEASE-p16 Update available. Click Here to view update . [oops: a n update just came out several minutes ago  :) :)) I also saw strange stats. Some how, the upgrading of the portal RRD stats (adding the concept of different "zones" etc messed up the RRD data. I managed to keep thing going by removing deactivating the portal interface in the old pfSEnse version. Remove ALL Captive portal settings from the config file - this and everything between it:         <captiveportal></captiveportal> Upgrade - RDD will be handled fine. Activating the captive portal again. I guess I saw how new stats where generated. I wiped these Captive Portal stats files. Renamed my old RDD stats file to the new one. Done. I know, this is what is being called 'some jacking' but it worked for me. I finally used other methods to stat: this is from my server on the net: http://www.test-domaine.fr/munin/dyndns.org/brithotelfumel.dyndns.org/index.html#portalusers

I guess i'm not that clear about the network i'm running. My network has about 10 public access points all ubiquity, spans about 10 hectare or 25 acres. I physically devided the network in segments, all connect to the pfsense server to its own network card. All networks have its own dhcp server with different ranges, 10.20.1.1/24, 10.20.2.1/24, etc. but all connect to the same captive portal, opt1. All this was done for containing problems to a smaller sector, if problems araise (which did, multiple times) it doesn't bring the whole network down. So this is why when people wander from one side of the site to the other they have to login again each time.

@abinjacob: … because at the moment i'm manually deleting all expired IPs. Expired "record" (== IP's) are just kept for reference. and for this reason: If the same device (== the same MAC) comes back and the DHCP server finds the MAC in an expired record AND the IP is available, it will give the same IP to that device. Otherwise, another IP will be given. I do not understand why you should clean out the expired leases. @abinjacob: kernel: arp: 192.168.0.30 moved from 90:27:e4:f6:af:ec to 9c:20:7b:c4:27:ac on vr0 Me neither: but … the first message on this search list shows what the problem might be ; https://www.google.fr/search?q=kernel%3A+arp%3A+192.168.0.30+moved+from+90%3A27%3Ae4%3Af6%3Aaf%3Aec+to+9c%3A20%3A7b%3Ac4%3A27%3Aac+on+vr0&ie=utf-8&oe=utf-8&aq=t&rls=org.mozillaofficial&client=firefox-a&channel=sb&gfe_rd=cr&ei=YJupU4bwFOuXigbArIDQBw#channel=sb&q=kernel:+arp:++moved+from++to++on+vr0&rls=org.mozillaofficial @abinjacob: dnsmasq[31537]: read /etc/hosts - 144 addresses Don't worry, this is insignificant is log-dust. dnsmasq like to say this often, its ok. We all have these line several times. @abinjacob: one more system log which i'm not aware what this is dhcpd: uid lease 192.168.0.222 for client 38:aa:3c:c6:9c:ce is duplicate on 192.168.0.0/24 https://www.google.fr/?gws_rd=ssl#q=dhcpd:+uid+lease++for+client++is+duplicate+on+ In 'my' words: the IP's / MAC's you put in a "Static mapping" have no 2 IP's for an identical MAC. My advise: make your IP pool big enough, and restart the DHCP server. This list: "Status -> DHCP Leases" should be empty to start with, and you will be fine.

https://github.com/pfsense/pfsense/pull/1241 Merged ….  :)

I guess so. Add a pass-firewall rule that only triggers with the first SYN packet between IP-client and IP-destination (no need to handle the rest). You should latter on add the relationship between IP and login in USER, this is impossible to 'lookup' at execution time of the firewall - and IP-destination and its reverse. But: this is pure theory. I leave it up to our government to track what users visit ;) With already a couple of portal clients connected your pfSense box will bog down quickly. The syslog will probably not follow neither. If you need to track users this way, you need some (very !) serious hardware - maybe some (pfsense) packages will fit your need.

thank you! I only have a Wan and LAN interface. Why would I need a third interface? It's good to keep fine tuning! I set my dhcp scope from 192.168.0.60 through 192.168.1.250 I set my idle timeout to 2 hours and hard timeout 4 hours my dhcp lease time is to 4 hours and max 8 hours.

@monsurvey1: 2. Any one know how to prevent the mac address spoofing, whether using the cisco switch or the pfsense box? 'Spoofing' can be done by any user. Its a matter of of changing the MAC address. You can't do anything to stop that. The user does it on HIS device. Point 1: what about the most important device in a 'serious network setup' : a UPS ?

Hi, Thanks, I did for the one week vouchers, the strange thing that the other time frame vouchers like one month does not effected and works fine. but maybe it will expired less than expected in the upfront days. Any way the one week vouchers seems works great after creating new roll.