Also if you are using a custom portal page try using $my_redirurl instead of $redirurl for redirection.

You probably need to make VLAN 10 a LAN on pfSense and put all the clients behind it.  To activate the captive portal requests to port 80 need to be sent to the pfSense interface.  This usually means it needs to be the default gateway of the clients.

If you put the pfSense WAN on VLAN 1 and LAN on VLAN 10 and let pfSense handle all the DHCP for VLAN 10 it would get you there.  You should also be able to forward DHCP to another server if required.

You'll also probably want to disable NAT in pfSense (switch to manual outbound and delete all the NAT rules.)

is there is any answer

@Gertjan:

And, here it where it all starts:
Look in this directory : /usr/local/captiveportal

Even more important:
Get yourself a decent editor like Notepad++ or even better: UltraEdit.
A FTP client that supports SFTP. Activate SSH access to your pfsense box (if not already done).
Most if not all files are pretty self documenting.

pfsense itself (the GUI): /usr/local/www

thanks!
I'll be using vim-lite though.

@Derelict:

Yes.  Users that don't need the captive portal on one interface, users that need to go through the portal on another interface with the portal enabled.

Or you could put them all on one interface with passthrough MAC address entries for the NICs that don't need to go through the portal.  Two networks with different access policies is how I would go.

Ok thank you very much for your sugesstion. I will try with with MAC address passthrough first, because it sound more fit-able to my network condition. If not work, i will try with the other solution 2 NIC.

What was the configuration issue?  Can you post the resolution?  I am also having a problem with 2.1.5

@Derelict:

Static DNS on the clients perhaps?

YES!!! That was the problem!!!

Static DNS entries in client machines! After I removed them, CP starts working! Great!

THANK YOU!!

@kapara:

….
iphone will not redirect at all!

Strange.
iDevices are always the fastest devices that show up the portal authentication page (I use a local user setup). Using 2.0, 2.1.1 up until 2.1.5
Never ever had any problems with those, because they will, as soon as the Wifi connection is up, throw out an Apple test URL that provokes the auth page being showed.
The "help - I can not connect" question is very rare at our local reception desk (Hotel).
People just connect.
Then, often, they can't login because it asks for a 3 digit "room number" (remember, this concerns a hotel - with doors and key the mention this number) like "202". They phone the redeption ….
The password is being indicated on the login screen ( !! ) they should retype or copy it. It's 'climat' btw.
They can't find it ......
(I guess intelligence dropped heavily last years in France ... I think .... I still don't get it ;) )

On the other hand, I know some setup have difficulties to show the portal page, which is normal as client lauch their conection with an initial https://….  request. This is normal.

any idea please ? :'(

The pfSense captive portal is pretty much time-based, not usage-based.  I think making it do that would be a great deal of work.

As said, this isn't a pfsense issues, but an error in the design of the network hooked up to the portal interface.
When using more then ONE AP - and these AP's works like switches, this kind of trouble pops up.

We are in 2014 now, so some OS's that clients use have this famous question:
Is this a private or Company network ? Or a public network ?
(I guess we all know now which OS this is  :) )
If the clients choses "public", then their PC can communicate ONLY with the gateway, and block ALL other incoming/outgoing connections.
Problems solved, the pfsense portal network engineer can go the bed again.

But, of course, there are clients that consider the portal Wifi network as their home network - and they share all their holiday photos on the network ("because then it works at home"). They just hit 'Home network' when their OS says "This is a new network, please chose …".
The same clients (our Wifi portal network clients) start to yell when they discover that pure strangers are 'surfing' their PC ... ad all their holiday photos are indexed by Google Images a couple of days later on.
(You better get a lawyer when you get home, your wife isn't gona like this one)

Anyway: I present https://forum.pfsense.org/index.php?topic=66368.msg365658#msg365658
It started here https://forum.pfsense.org/index.php?topic=1268.msg7542#msg7542 (even Sullrich was surprised  ;))

It all boils down to: activate AP isolation - and route all trafic from clients to gateway - and back. NO CLIENT TO CLIENT communication.
The rule to be enforced is "You, as an pfSense operator, do NOT OFFER A LAN PARTY, but Internet Access only".

@xamber:

…..
Well i get the following error "Fatal error: Call to undefined function mysqli_connect()"
....

Troubleshooting wouldn't take long if you called this function: phpinfo();
You will discover that PHP as it executes on pfSEnse, has NOT, by default, MySQL (client) support activated.

I don't recall how, but there is a trick to activate it.
(it's on this forum).

Awesome, used lower case "portal" and only that one turned on in the test system :D  I'm learning slowly ::)

Edit: My meeting got canceled so no live run, but it is working great on my virtual machines.

@xzmz:

2. Radius

Miss-communication with a Radius server returns a message:
"System reached maximum login capacity"

Btw:
Client get disconnected ?
Means: look at your portal log
Are clients disconnected ?
Because, if they don't the all goes well: the system will blow up (== "System reached maximum login capacity" because clients connect - and have to disconnect (are disconnected) to make pleace for new connections)

@xzmz:

4. hard time out is present
5. IDLE timeout 10080 min; Hard timeout 40320 min; DHCP lease time 604870 sek

Hummm.
This DHCP time-out is fine for a wired LAN setup using fixed clients.

Portal software runs fine with:
Idle time out : 3 -6 hours max
Hardware time out + xx %
DHCP time out hard time out + xx %

Wifi clients, per definition, are network-guest-users.
If your clients are semi residential, (staying there for days or weeks) or if they need a connection that is active for hundreds of hours, you should use something different as what pfSense offers.

Btw: the program logic can handle the clients, although I really would like to see what happens when the portal software keeps hitting hard this one:
/etc/inc/captiveportal.inc : line 1366 + 1377 (and 1389 + 1409).

Y'know, looking at the paragraph again, I think I misunderstood it. Thanks for that pointer.

Which is why you need to look at history (graphs) because if you have a flat line at 12Mbps, then that's all you have, not 18.  Don't guess.  Measure, log, and evaluate.

WAN gateway quality graph will likely show you exactly why it's slow.