Thanks , I'll give it a go.

@dhatz: How would the DHCP lease time need to be configured when using vouchers? (e.g. would a 2 day voucher require a 2+ day DHCP lease?) AFAIK, if a client's MAC address is recorded in the …/var/db/dhcpd.leases file, this client should get the same IP address next time. That's not specific to using vouchers, or RADIUS, or no authentication, just make sure your DHCP lease lifetime is equal to or greater than your CP hard timeout in all cases. Clients will be re-assigned the same IP in most cases, but commonly not in environments like larger hotels where lots of devices come and go and you have a relatively small DHCP pool for the number of devices, so it has to reassign IPs whose leases have recently expired.

Thanks for the reply! I managed to get around this by doing some fancy php code What I did was create a simple redirect page for the captive portal to redirect to an external auth server, which will then ask the user to login and record the information that way. The only reason I'm using an external server is that pfsense doesnt support the mysql extension for php which is what I'm using to record some of the information. So i managed to work around it but if any body has any idea how to enable mysql support for php in pfsense that would be great! (i did do some reading and posted in the documentation section of this forums but so far now luck) Anyway for now I'm happy with the redirect its doing everything i need at the moment :) cheers! @Gertjan: Hi ! "usernames" are captive portal login names ? or The names of the PC's connected ? (have a look at the DHCP lease table from the server that runs on the captive portal interface). or The "Full name" you entered in the User manager of pfSense ?

You might want to check the discussion in the captiveportal max users thread. If it's going to be a public hotspot, one should also think about ways to mitigate possible abuse (either unintentional due to malware-infected PCs, or even intentional e.g. roaming spammers), how to deal with possible dhcp DoS attacks, rogue APs for mitm attacks, DoS attacks against the CP itself etc. The underlying tools in pfsense (pf+ipfw) offer some relevant features, but afaik those aren't yet available from the webGUI. A city-wide public Wifi for 30.000 active devices is a very big project that will require a great deal of work in design. You might want to read the material at http://www.muniwireless.com/category/city-county-wifi-networks/

Sorry, just dropped in here, and saw the question. I have myself several AP's using DD-WRT on a OPT1 interface, captive portal enabled on OPT1. Of course, I wouldn't like it that my 'clients' could hammer on my AP's. Can I presume that the IP of your AP = 192.168.1.2 ? Open the web interface of your DD-WRT Goto Administartion => Shell Paste this code into the "fire wall" block. Save. #!/bin/sh /usr/sbin/iptables -N logdrop /usr/sbin/iptables -F logdrop /usr/sbin/iptables -A logdrop -j LOG /usr/sbin/iptables -A logdrop -j DROP /usr/sbin/iptables -I INPUT -i br0 -s 192.168.1.0/24 -p tcp --dport 80 -j logdrop /usr/sbin/iptables -I INPUT -i br0 -s 192.168.1.0/24 -p tcp --dport 22 -j logdrop /usr/sbin/iptables -I INPUT -i br0 -s 192.168.1.0/24 -p tcp --dport 23 -j logdrop ## end With this code, YOU can administer your AP from the LAN interface (192.168.0.0/24) - [DO NOT forget to ADD to Services => Captive Portal => Allowed IP addresses => Direction = Both IP = 192.168.1.2 and hit Save. - This way the AP itself can now communicate with the net to play games, update the time, have a chat, and answer to YOU when you want to login from anywhere except 192.168.1.0/24 ] No one, coming form the subnet 192.168.1.0/24 can access the DD-WRT interfaces.

@slth: This might be a stupid question, but as the bug if ipfw related ("ipfw entrystats is returning wrong values, leading RADIUS accounting to have values considerably higher than reality."), does this mean every bandwidth monitoring package mentioned at http://doc.pfsense.org/index.php/How_can_I_monitor_bandwidth_usage%3F has the same problem? No, none of those use ipfw entrystats. ipfw isn't even loaded unless you're running CP.

@slth: ISC dhcpd only checks via ping to ensure that an IP is not actively in use when making assignments. Making a static mapping does not "reserve" that IP out of the pool. The static mapping in this case merely represents a preference for an IP, and others are not prevented from taking the IP if it is not in use. So suppose I'd have a DHCP pool 192.168.0.10-192.168.0.50 with static IP mappings for ip 192.168.0.20 and 192.168.0.30, associated to the respective mac addresses. The text you quoted is meant to say that DHCP static IP mappings must be outside the range reserved for dynamic IP addresses. So if you have a DHCP pool of 192.168.0.10 to 192.168.0.50 you can have (for example) static DHCP mappings for 192.168.0.60 and 192.168.0.70.

Ok, narrowed this down to a specific setting. When I uncheck the "Enable per-user bandwidth restriction" traffic passes as expected. When I check the box and my default download is set to 4120 and default upload is 1024 traffic does not pass.  my radius server is set to return wispr-bandwith settings that where working with 1.2.3. these settings are wrong for 2.0.  They need to be multiplied by 1000. looks like you can't use the same radius server for 1.2.3 and 2.0 if you use wispr to set bandwith. read http://forum.pfsense.org/index.php/topic,41372.0.html

The way that the web request is forwarded, it must land on an IP address. You could setup a DNS forwarder entry for the hostname you want, in the captive portal html (it will take php) code up a redirect such that if the URL is the IP, redirect to the hostname, then the user would only see the IP address if they caught it quickly before the second redirect kicked in.

Talking to myself. Hopefully it may help someone else in the same situation. I edit the following files: /etc/inc/captiveportal.inc /usr/local/captiveportal/index.php References to port 8000 was changed to 8080. Enabled Captive Portal and viola! I'm now redirected to "pfsense-ip":8080 and ends up in the Portal login page. /var/etc/lighty-CaptivePortal.conf was automatically update by the changes made to the above files. This was done one my own (home/work environment) installation of pfSense. Next test will be to move my own pfGUI to another port than 80 and then change the Portal port to 80. I'll be back on this one. If anyone here with deeper knowledge can fill in on the subject I'll be very glad. For example will my changes survive a reboot? Is there another way of doing this? Using a proxy in someway? PAUSE I'm back. Changing the port to 80 was no success. Resulted in a redirect loop. Don't have the time right now to continue my experiment. But if somebody has more knowledge and wants to fill in, please do! /iorx