The pfSense captive portal is exactly the same as the m0n0wall captive portal.

Just a side thought here.

This 'problem' could be solved more radical - and more logical.

If we presume that hotspot IP's, like the disconnect window, are always local LAN IP's, it would be nice to say to your browser "do not accept popups from the Internet…..' but popus coming from the LAN range should be accepted (always ?).

Popups from a local source can’t be really annoying, because YOU, or the one that gave you YOUR connection, controls them.

So: browsers should accept, or handle at a second level, popus coming from local IP’s (gateway in this case).
On the Firefox feature request list this item exists.
IE: keep on dreaming….

When the gateway isn’t local, the problem is solved otherwise: users are asked to keep the main login windows open, so they can disconnect (they have to open a second browser window!).  This is important because many are actually billing for their ‘wifi/network’ usage. Loosing the disconnect windows/button introduces the opportunity for the operator to take another hour, or more, before disconnection for ‘non-usage’.

That should work just fine. The clients don't need a portforward to be reachable by the radius server as the clients establish the connection to the radius server and not vice versa.

@hoba:

Are you sure that your client isn't causing any backgroundtraffic?

Thank you for this advice.
Wireshark shows some traffic, may be becuase of the external syslog-server or firefox-update, …
It works fine without the patchcord.
Never mind, i have to look for another solution but the idle-timer in windows is just for windows-pcs and an more general solution would be fine.

What you are asking for would require a bridge.

If what you are trying to accomplish is to use PFSense captive portal. And your clients are behind the Meraki. Then the Meraki would need to use a bridge mode in order for it to pass devices behind it and their MAC addresses in a way that PFSense can see. I'm not familar with Meraki so I'm not sure if it has a bridge mode but that is what you would need to do in order for it to work.

easiest way is by MAC-authorization.

pfsense is multi-wan aware but with issues! With real loads it goes nutz and packet storms develop and down she goes! To do all in one machine just will not work… with a real load! Home Use or Base Setup this system rocks I love it! But a commercial deployment with hundreds of machines and multi-wan and captive portal systems just will not work with out lots of machines doing specific jobs! The all in one whammy gizmo's approach will fail in a load situation and by current design! :-(

Buy some more machines assign specific jobs and your life will become much better!

Now this is a good Idea that I would be interested in placing some cash to motivate this idea through the pipes! Post here who all is interested and I will post the bounty and pony up the cash!

http://forum.pfsense.org/index.php/topic,5669.0.html

Use the link on that page as a template, redesign your portal page and save as html file then upload using pfsense web interface.

Or just create a page from scratch and add the following basics.

Regards

The only way I can see this working for you is to add the ip address of the AD to the "allowed IP addresses" tab under captive portal, but this will allow even unauthenticated users access to the AD.

You will have to play around with the "from" and "to" option to see which one works as I've forgotten which way worked best.

Regards

Maybe you should at least note that it is a turkish web site…

is this what you are looking for:  /var/log/portalauth.log ?

no my cp is not using ssl and i have static ip adress

I believe you can http://to_the_portal:8001 to get the login page again. relogin to get the pop up again.

Thanks :).  Sorry that I didn't read the docs, I just haven't downloaded it yet to even play with it.  I just found this project around 1:30AM.  I'm at work right now planning stuff out for it.

In Italy we must keep logs (squid + captive portal auth) for 5 years.

In little networks I can't istall a second hw to keep logs (I should make redoundant each hardware, it's too expensive)
I think it's better to keep all locally (in raid1+spare system) and burn data regularly

ciao

Giaco

there is a full ACL system in HEAD, so i guess 1.3 release will have this..