Hi, yes, gateway, and dns are pointing to the firewall.

The captive portal is still one of the most actively developed parts of m0n0wall. Maybe you should suggest such a change at the m0n0list as we due to that are syncing pfSense's cp against the m0n0 code frequently without changing too much.

Sorry for my mistake, when squid is configured in transparent mode captive portal work very well but proxy server is running as “if();” . It’s any chance to run squid in transparent mode with captive portal ?

it's me again :-) things go better, i can now authenticate my users with NAS-Port-Type and NAS-Identifier attributes. but there is one more problem : it seems that called-station-id and calling-station-id are not sent by pfsense, users are always refused if i try to authenticate with called-station-id="pfsense wan IP" and calling-station-id is empty in the radacct table. what gives ?

Thanks, we are aware of the bug.  No need to confirm further.  What we need is for people to test a recent shapshost from pfsense.com/~sullrich

Maybe I didn't explain correctly the problem. I have enabled every minute reauthentication in the captive portal page. It happens that when I shutdown the radius server (simulating a failure of the server) people who are logged on can continue surfing the web while people that are not logged cannot logon. The problem is that people should be logged off automatically when the radius server isn't available preventing them from surfing the web without their activity beeing accounted. Maybe it could be solved if, when enabling "reauthenticate every minute" captive portal disconnects clients not only when it receives an ACCES-REJECT from the radius but also when the radius doesn't answer the ACCES-REQUEST by the router. Thanks

@namezero: Looks like m0n0wall's beta 1.23b1 has improvement on that issue: hanges in captive portal (jdegraeve) * fixed a bug in the way we handle authentication mechanisms (potentially allowing double logins and faulty locking)     * add support for different MAC address formatting styles     * add support for per-user bandwidth limitation (using well-known WISPr RADIUS attributes) http://m0n0.ch/wall/beta.php So if you're really stuck, you might want to take a look at m0n0wall for the mean time. We have already backported this code to HEAD but it will not appear in 1.0.  I agree with namezero, if this is such a big issue then please run m0n0wall.

You have to use the dns-forwarder of the pfsense for the wireless clients. Otherwise it can't redirect to the captive portal page. Set up your LAN DNS server at system>general and assign the wireless clients the pfsense wlan IP (done by default). Also uncheck "block private IP ranges" at interfaces>wan.

Got it.  I've sent it to the m0n0wall Captive portal author.

Thanks!  It can definately be taxing at times.  And the amount of grey hairs on my head seem to be multiplying *4 very rapidly :P

You have the portal set to be enabled on the opt1 interface?    Did you add a rule to allow that subnet out of the firewall?  By default it won't allow traffic on that interface to pass.  You need to add an allow rule under Firewall -> Rules -> opt1 Have you tried removing the 2wire device and testing with just a wired connection either directly into the pfsense box or through just a hub or switch?  I had nothing but bad luck with those 2wire devices 3-4 years ago when I tested them as DSL CPE. Something else to try, can you go to http://192.168.1.1:8000 ? (assuming that the opt1 address is 192.168.1.1) I just set this up to test and it works fine for me (minus the 2wire device).  I'll wager you just need a pass rule for that subnet on that interface.

Thats great to hear!!

Okay I tested this again and found some minor errors… png wasn't working. Anything upper or mixed case wouldnt have worked: ie: Jpg If you are running a full installation do a cvs_sync.sh releng_1 && shutdown -r now If not, Diagnostics, Edit file and overwrite the code with this: http://cvs.pfsense.com/cgi-bin/cvsweb.cgi/pfSense/etc/inc/system.inc?rev=1.79.2.38;content-type=text%2Fplain;only_with_tag=RELENG_1

@clamothe: It seems like that would be true, since I doubt the computers will be talking through the router to get to another computer on the LAN. True. @clamothe: Another thing that I'd like to do is open up ports UDP 27000 to 27015 and TCP 27020 to 27050 for Steam.  Open them up so that all internal users (including non-authenticated) can access WAN servers via those ports.  Is there some way I can bypass the portal for this? You can't open up single ports but you can specify passthrough IPs as destination that are always allowed. So add the Steam IPs there and you are fine. For everything else the clients have to authenticate then.

No.

Send it over to the m0ther too  ;D