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

What reports cannot access no dns? I can think of many more interesting things to do than meddle with pfSense pages trying to make one report cannot access no dns Sorry, I don't understand the following and have no idea what "it" refers to. @dy6amj: what i want to do is there should be a captive portal so that it cannot get access thru the wan Firewall rules would normally be used to prevent access to the WAN. Maybe another reader can figure this out.

I don't think captive portal is quite the right tool to do this. How about using outbound NAT on the wireless client interface to redirect any outgoing port 80 connect to the IP address of the wireless client interface? I don't know enough about outbound NAT to know if its possible to redirect to the "local interface IP address" but if it isn't, it should be possible to redirect to one of the allowed external servers (which presumably are under control of the same organisation) which then issues a http redirect back to the local server. I have not ever configured squid but I see it is described as having the capability of rewriting URLs. Perhaps it could be configured to not cache and to rewrite URLs to the local server if they don't reference the local server or one of the allowed external servers. There is a pfSense vHosts package which extends the inbuilt web server. The fairly limited RAM on an Alix might make it unsuitable to be running packages like squid and vHosts. (My home pfSense runs fine with 256MB but I run a small number of small packages, certainly nothing large enough to force my system to swap.)

I have used them as both routers and AP's. I used them for radius auth for AP's. Mikrotik is a very stable product and has been used to provide wireless to entire cities.  A lot of wisp use mikrotik. Mikrotik has many features and in some ways I prefer over pfSense especially as an AP or WDS/mesh.  It can do both gui and command line like cisco which some like as all configuration can be done via ssh. I went back to pfsense for 2 reasons.  1.  Captive portal/radius improved in 2.0 2. I am very familiar with configuring pfsense and mikrotik required too much time for me to learn.  Also no paid support for mikrotik though many 3rd party engineers can support for $65/hr. If I were to deploy a very large infrastructure ..ie 25 to 50 AP's or larger I would go with mikrotik…  Cost wise it is also less expensive as it is primarily used by WISP's..... I would definitely recommend buying a level 4 mikrotik router and playing with it.  The experience was worth it as I now have a better solution for wireless which feature wise is on par with cisco for the price of a linksys/netgear device from a retail store!