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.

As jimp already explained (implicit), you should intercept all DNS requests, and match them with the with listed domain names. If you have a match, the resulting IP should be fed into the allowed IP list of the portal page. You probably have to issue en redirect to your client. Some caching will needed, otherwise portal access will slow down as easy DNS request has to be filtered. This is what I should call a "bounty project".

Gertjan: I've got a baby on the way and have been pretty busy as of late, so it could take me a while to get back to testing this and provide the results of your posted commands. I've also got a buddy down the street from me who will assist in setting up a remote iodine server so we can test the tunneling techniques against pfSense. cmb: You're correct about the packet capture not showing any dns tunneling results. I must have attached the wrong capture that day. I was running late for meeting at work and had about 10 tabs open with various packet captures. I did have one that showed more details about the initial connection, but I apparently attached the wrong capture. I'm not the only one that has had this issue though –> https://forum.pfsense.org/index.php?topic=65739.0 Digging more into the location requests, I believe this could be hardware fallback technique done by dish network for subscribers to properly pay for their pay-per-view purchases. Search results over the net show all kinds of results with people noticing that certain Dish devices are establishing a lot of DNS connections back to homebase. I'll post back on this thread later after my buddy gets his side of the iodine setup and I have some more detailed packet captures to provide. For right now, packetfence is fitting the bill and I don't show any established connections to 67.148.153.116 in the table states anymore. And he's still hanging off my guest vlan.

@hardy_rafael17: So newbie question is…  Is there any way.. to direct or redirect trafic to port 80 from unauthenticated IPs to the captive portal... That's precisely how captive portal works. The problem is those apps aren't web browsers so when you intercept their traffic and serve them a portal page, the app just flakes out. Have to open a browser. People should be used to that. Gertjan's explanation provides more detail.

I AM a newb.  I had never actually entered invalid credentials.  I would click the 'View current page" and when it worked for the portal page contents and not for the authentication error page contents, I assumed it wasn't working.  When I actually try to log in and deliberately enter bad credentials, it notifies me… with the logo and all.  Thanks everyone for the help.

Thanks for the info Gertjan!  I will give it a go. Pulling the plug would be the ultimate solution; unfortunatly they are home while I am at work.  This should be good incentive to get them to help out around the house a bit. The plan is: Give each of them a chore or two to do each day Once they have completed said chore, the can text me with photo evidence I will then text them the appropriate voucher number to allow them access to the internet Is there any way to schedule the portal to be active only during specific hours of the day?  All other hours are free for all use?

Ditch Radius. Get Vouchers. Done  ;) (Or: try to put vouchers into Radius) (Or: Radius hasn't the possibility to give a account xx seconds 'usage' ?)

@ptt: You can start with this guide https://doc.pfsense.org/index.php/FreeRADIUS_2.x_package https://doc.pfsense.org/index.php/FreeRADIUS_2.x_package#HOW-TO_-_Multimedia_Tutorials thanks with this, but my main prob is may radius cant start eventhought i delete and reinstall it it wont run what is the fixed?

Well, If the popup doesn't show up, don't worry. As soon as the user becomes idle (and set an idle timeout on the captive portal interface to make this happen) because he's out of the network, shuts down its PC, or whatever, the connection is disconnected. Stuff get serious if you "sell" Wifi portal time. That why some of us invented this, a rock solid "check-out" disconnect procedure.