Hi.  So having issues.  Not as easy as I was hoping… Configured Virtual pfSense. Left WAN rules open for testing. Installed Radius On Virtual pfSense with Radius installed. Added Client: Client IP: (My WAN on Home_pfSense) Shortname: MHDHOME Shared password: abc123 Desc: Test 3. On pfSense Firewall at Datacenter Add port forwarding to port TCP 1812 to pfSense Virtual WAN port 10.20.30.210 from external IP Add port forwarding to port TCP 80 (HTTP) to pfSense Virtual WAN port 10.20.30.210 from external IP Successfully connected to port 80 via public IP confirming access. 4. On Home_pfSense. Assigned OPT1 10.20.10.1/24 Enabled DHCP and set dns to 10.20.10.1 Enabled Captive Portal on OPT1 Selected radius Primary RADIUS server: entered public IP assigned to virtual pfSense for ports 1812 and 80. Entered shared password: abc123 Created custom pages. When logging on I am redirected to portal page.  After entering username and password for user I get: http://10.20.10.1:8000/ 500 - Internal Server Error When I look at the logs for radius: Tue Jan  4 05:01:08 2011 : Info: Using deprecated naslist file.  Support for this will go away soon. Tue Jan  4 05:01:08 2011 : Info: Using deprecated naslist file.  Support for this will go away soon. Tue Jan  4 05:01:08 2011 : Error: There appears to be another RADIUS server running on the authentication port 1812 Tue Jan  4 05:01:08 2011 : Info: rlm_exec: Wait=yes but no output defined. Did you mean output=none? Tue Jan  4 04:57:23 2011 : Info: Ready to process requests. Tue Jan  4 07:48:29 2011 : Info: Using deprecated naslist file.  Support for this will go away soon. Tue Jan  4 07:48:29 2011 : Info: rlm_exec: Wait=yes but no output defined. Did you mean output=none? Tue Jan  4 07:48:29 2011 : Info: Ready to process requests. Tue Jan  4 07:49:32 2011 : Info: Using deprecated naslist file.  Support for this will go away soon. Tue Jan  4 07:49:32 2011 : Info: rlm_exec: Wait=yes but no output defined. Did you mean output=none? Tue Jan  4 07:49:32 2011 : Info: Ready to process requests. Tue Jan  4 07:58:16 2011 : Info: Using deprecated naslist file.  Support for this will go away soon. Tue Jan  4 07:58:16 2011 : Info: rlm_exec: Wait=yes but no output defined. Did you mean output=none? Tue Jan  4 07:58:16 2011 : Info: Ready to process requests.

Thanks.  I am going to try it…

I belive you are looking only at 1.2.3 code!

any idea please

Hi, Have you managed to fix the problem?

Found the following which appears to do exactly what I want but I am not sure how to implement it. http://freeradius.org/radiusd/man/rlm_counter.html

Have you tried just unchecked the enable box, and then checking it again? That should force the fields to be enabled, though I don't see how they would be locked in the disabled mode either. Like Ermal, I haven't been able to replicate that.

Hello Jim, I look forward to the updated book. I will touch base with Jos in a few days to get the new version. We are running a customized version of pfSense 1.2.3 so it will be a while before we can upgrade to 2.0.  So we will need to settle for the above for now.  The only draw back I see is that src LAN_NET gets replaced with any in all rules.  I still have not been able to unscramble exactly why this allows the captive portal LAN subnets to work. There is some interaction between pf and ipfw that I am not quite getting… However, the bottom line is that for whatever reason changing that one line in filters.inc causes subnets to work with captive portal. Thanks for help and advise here and in other postings. take care. --luis

Thanks for the prompt Replies guys.  I appreciate it!

What is that option for on the captive portal settings page if it wasn't intended to be used?

When you tested it, did you manually go directly to the captive portal page or did you get redirected there when trying to access something else?  When you go there manually, it redirects to itself when you log in.

Probably 3 possibilities here and I doubt if applying a firmware update does anything as it's almost guaranteed either your config has been changed, or it's completely unrelated to your firewall. You used a weak password, didn't restrict management access, and someone on that network cracked/guessed it and changed the redirect URL or something else in your config to do that someone on the network is doing bad things to MITM your users, ARP poisoning or similar. you're redirecting to a URL that's been defaced, that tag line is common on defaced websites. Attaching a copy of your config, and a packet capture of all traffic from an affected machine while it's accessing captive portal and getting redirected would tell more. You can email those two files to me off-forum if you don't want to make them public (cmb at pfsense dot org, include a link to this thread).

Can guide me to create RADIUS Server?

In our setup, we had to use the pfsense LAN IP as the gateway IP for the clients. Once i did that then things started working for us. We also put in the FW rules for any:any for all traffic. Its in a test lab so security of it isn't a problem for us right now. However, we seem to be having an issue where occasionally the captive login doesn't show up initially and once we stop and start the captive service that seems to 'fix' it. What is the manual URL you are using to force the page to appear?