Thanks! haha
I'll look in that direction!

You probably need an external RADIUS server for this. The way we solve the problem here is that internal users are going directly through pfSense with its own page, guests use a DD-WRT enabled WiFI router with chillispot. Both pfSense and Chilli authenticate against a Freeradius server (that runs the portal pages for Chilli as well). Radius is managed through the free Daloradius web interface.

While looking at the code I see that PF uses the PEAR radius library to respond to talk to the radius server. While some attributes have been ported to this library, we need to port ChilliSpot-Max-Total-Octets, can this be configured or does the captive portal module would need major modifications?

Thanks

OK
Deactivated CP, restarted the box, activated again on both interfaces….same result.

LAN address pfsense is 172.16.100.4  (static users on cable)
LAN2 address pfsense is 172.16.101.1 (dhcp enabled users on wifi)

I have also noticed the url on ethernet
http://172.16.100.4:8000/index.php?redirurl=http%3A%2F%2F_172.16.101.1_%3A8000http%3A%2F%2Fwww.google.com%2F
when accessed by LAN.

Please suggest what to do.

Regards

I'm using a StartSSL free SSL certificate on my home PFsense portal. I noticed it doesn't play nice with Firefox, but IE authenticates to it fine.

I would highly suggest a paid SSL certificate for a business environment.

http://www.cheapssls.com/

Comodo is $8 a year and RapidSSL is $9. I'd go with RapidSSL, Comodo's CEO is an idiot.

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.