That is better handled inside your Access Point. Your Access Point may have a way to do authentication via RADIUS or similar (802.1x, WPA2 Enterprise) that would require a password from the AP to associate and get an IP address. Otherwise there is no way to get someone a portal login without an IP address (which you already asked in another thread) and at that point they're already on the local network, but AP isolation can prevent them from reaching other wireless clients.

@nguy5417: However, anyone that connects to my AP can connect to my network resources. Can that be blocked until the user authenticates? You would have to block "local" access in the AP or put the AP on a separate pfSense interface so pfSense can control the traffic from the AP to "local" network.

So I ended up using pfSense 1.2.3… user self registration via the php script above works beautifully. Too bad I couldn't get this working on 2.0. Since deployment I have run into some other issues in pfSense 1.2.3 that 2.0 would fix.

VAP == multiple SSIDs bridged over to multiple VLANs on your APs. Minus that, you have a flat network with all the APs that's behind the pfSense box, either way it will do DHCP, and be the gateway for the wireless network if you need to use CP.

this is what it says in the "After Authentication Redirection URL" option "If you provide a URL here, clients will be redirected to that URL instead of the one they initially tried to access after they've authenticated." So if you try to authenticate using a blank URL, it won't do anything. Just put in a redirect url. Rob

Try to play with "acct_unique" on freeradius2 settings if you use freeradius2 package. Try to use interim-updates

im newbie ..if u have a solution for pfsense 2.0 ..pls let me know. i need it. thanks a lot

Try this: http://jpardobl.wordpress.com/2012/11/28/pfsense-voucher-rest-api/

I will open 1 ticket, thanks Nachtfalke.

Hi, already I think the action for the form is not correct. It should be : action="$PORTAL_ACTION$"

That's an interesting feature request, but it's definitely not as simple as a s/8000/80/ search-and-replace. It has been over a year since I last looked carefully into the CP code, but here is the gist: When used with SSL, pfSense's CP uses two ports: 8000 (http to facilitate the 302 redirect from http -> https) and 8001 (https for the authentication form where the user inputs his username/password or his voucher code). So if you're going to try to accommodate guests whose system's firewall has a very restrictive egress filtering policy, you'll probably have to use 80 and 443 respectively. IMHO pfSense's CP needs some developer time to get up to speed with other CP implementations, and to deal with the quirks of modern platforms (e.g. Mac OSX 10.7.x clients will try to contact OCSP URLs of your captive portal's SSL cert).

OK, thanks. I'll be able to check that.

You can authenticate the CP users agains a RADIUS server. You can use freeradius to connect it to your AD or you chose Windows RADIUS server. And - if I remember correct - you can authenticate the CP against the pfsense "local user database" which can be connected to your AD. But I am not 100% sure if this is correct. When you use pfsense you can go to SYSTEM –> User manager --> Server and check the opions there. I know there are some threads covering this topic. probably best would be to search for "captiveportal" and "active directory".

Thank you Nachtfalke. I check my Nas/Clients and now it works. Actually my mistake was hoped that the interface connection. =)

I think this is not possible. If pfsense is not the gateway for your clients your clients will not send any traffic to pfsense but just bypass pfsense and send it to fortigate. Not sure if it is working with on NIC on pfsense but if pfsense is your DHCP then the clients should use pfsense as the gateway. Allow all ports in the firewall for the clients and then the clients do hagve full access through pfsense but need to authenticate on CP. After that pfsense will route all traffic to the fortigate firewall/router. You can disable NAT on pfsense so that there is just routing. Another possibility could be that you try to run pfsense in bridge mode. So no routing and no NAT on pfsense. pfsense is just another "client" on the LAN. But the gateway still needs to be pfsense and pfsense will redirect it to fortigate.

Yeah just had a very quick play. What a shame it can't have user groups.. :( TT

I thing have the same problem, try this: @alltime: One thing I might also add, we simply added our DNS server addresses to the Allowed IP list and that resolved our problem. We were experiencing exactly what you are.