In that case you suggest cp or firewall rules?

Looks that way, perhaps even if just its root directory was named captiveportal-something (then it would be in every URL regardless of the end name)

@dhatz:

AFAIK on a CP-enabled interface all external traffic is refused by default (before successful login), except those IPs and hostnames which are explicitly allowed (aka "walled garden").

Taking a quick look at the source code, it seems to me that in the hypothetical scenario you describe, access to both sites would be allowed.

of course.
hostname  resolve to ip and add to access

I figured out why it isn't working - iOS doesn't look for captive portals when you connect to a secure network.

As soon as I made a virtual WAP with no encryption needed, the login page popped right up.

I'm not sure whether I want to think of this as a "feature" or not since I'd like to see our iOS devices be able to use "auto-login".

Looks like this is definitely more of an apple issue.

If your DHCP configuration doesn't set your pfsense box as a DNS server then captive portal won't work.

thanks @cmb

Thank You.. I feel like a total idiot.
I thought all along I had the DNS forwarder on but I had disabled it earlier as it wasn't needed before bringing up the CP.
I also forgot that it is needed for the CP for obvious reasons URGH!

Works great..

This thing (PFSense) is awesome we are starting to get some paid jobs because of how well done this is and how reliable it is and how impressive the user interface is.
It's seriously the ONLY web interface I have ever used that I'd say was done right.
I plan to be rolling in a year of PAID support with our next big job even if I could get away without it.

You can't make it resolve differently, it should work if you just add one of the internal interface IPs of the firewall as an allowed IP entry in CP and leave the DNS pointed to that.

I don't usually post but I know this forum can occasionally be idle when you have an urgent need.

How are you authenticating users?  Our users were skipping the authentication page until we found that PFSense was not authenticating with our RADIUS server.

We are a Medical University using PFSense (2 NICS) with multiple AD servers configured to work with RADIUS.  We do not have any VLANS set for the traffic since our wired traffic is on a different network.  PFSense is also acting as the DHCP server.

I've specified the remote Nework 192.168.1.0/24 in the "Allowed IP Address" tab in the Captive Portal.

Thank you so much.

Luca

You can make a user in the User Manager, and if they only have the permission to "WebCfg - System: User Password Manager Page" then when they login to the GUI they only see a page to change their own password.

You could make a group, add that permission to the group, and then for users you want to be able to change their own password, add them to that group.

For now there is no other way supported.
There were some fixes related to this in latest 2.0 branch of pfSense.

@cmb:

You can use any DHCP server with captive portal. You do need to make sure you don't block your DNS server with captive portal, using the firewall's DNS forwarder will automatically work, but you'll need an IP passthrough in CP for the Windows server if you're using it for DNS and not having it forward its requests to the DNS forwarder.

Many thanks for your suggestions ; I will try.
What about the possibility of PFSense DHCP server to Update MS DNS Sever Records ? What do You think about it?

you have to allow Internet traffic below blocking everything to the interface IP.

Please post the output of pfSense shell command top -S -H so we can see which processes are the major CPU users.

Ok, I made some changes over the configuration and until this moment is working:

For now, the DHCP server assigns new ips always, and still don´t assign a lease with a previous session opened in Captive Portal, then, all the sessions of old users are open yet. I´m waiting that when DHCP assign an ip previously used, and the users try to login in the CP, system automatically close the old session and open a new one. Are this a correct assumption?

Thanks for your help.

@krot:

I can't find how to get this to work:

In my system users should be able to choose either to enter a voucher or to enter their username/password.
Cause i have two kind of users:

Residents with an own username/login

Guests however should be able to use the vouchers-system.

If i enable vouchers in my CP users cant login with their usernames any more.

Is there a possibility to have both at the same time?

Yes, put the code of the voucher page and the username/password page together.

You additionally have to put your wpad.dat on your Captive Portal Login Page as the first code. If someone opens a browser it asks for the wpad.dat file, witch can not be accessed because of the CP-Page. But if the wpad code is on yout CP-Login page it will be recognized as your wad.dat code.

Thanks again for sharing your ideas.

Yes, there are lot of alternatives.

Considering WPA2-PSK, it seems that long and random enaugh PSK is practically impossible to break. So, the simplest solution will be to have two SSIDs, connected to two VLANs - first for guests, opened at AP (no keys), and controlled by pfSense CP (vouchers), another one for employees with WPA2-PSK. Only problem is possibility that one employee gives key to others, but I think we can live with that.

Another approach will be to have all traffic going via CP. On that way, only one SSID/VLAN would be sufficient. I don't know exactly how CP is working, but probably it stores IP/MAC of user which successfully authenticated by vouchers or user/pwd. If this is correct, then it seems to me that it will be easier to sniff IP/MAC combination, and possibly misuse it, then to break WPA2-PSK. But I'm just guessing, I'm really not security expert. Also, if using plain http for CP where users enter their username/passwords, I think that credentials can be sniffed quite easy if using http. If, on the other side, I force https at CP, then I will probably have some issues about deploying root certificate, especially on some smartphones, etc. I know that same applies to vouchers for guests, but vouchers validity is measured in hours, so if attacker even succeed to grab the voucher code, he can use it same day only. Credentials for employees should be valid for much longer time.

So, these were just my ideas about various alternatives. At the moment, consdering all above, it seems to me that first alternative might be easier to configure and maintain, and "good enaugh" in my current scenario.