Hi wallabybob, you are right. Changing the dns rule didn´t will fix the problem. Today, i have checked the problem with one of our device. If i didn´t enter a voucher ticket and try to catch mail or do other communication to the internet, so transfer will blocked. If i will go to a www url over port 80, the captive portal catch me and ask me for a voucher. Looks all ok. Only the firewall log makes me crazy.

You are not clear on your request! How can you resolve that? Give a description of the problem Give a description of your setup

Ermal…... I created a rule that prohibits all but the captive configured on the interface. It seems that when the captive-enabled interface, they do not respect the firewall rules, after the user authenticates to the captive rules are then followed. Something that I think should happen is just spotting nmap tcp port 8000 for authentication, nothing more. Thank you very much

UP

When I was running the July 4th (before the snapshot location changed) I had the problems outlined above.  As of yesterdays (2.0-RC3 (i386) built on Wed Jul 13 18:38:42 EDT 2011) build, the user is now showing up.

Presently not. It could be achievable through some tricks but i am not interested for the moment.

Thank you :)

I´m using a syslog server and…. I have all logs the voucher..... Could you try. Thanks

@Piplfox: I’ve managed pfSense with captive portal (voucher auth.) and on LAN I have WiFi AP. Clients that connect thru wiFi AP, I don’t want them to be able see or communicate to each other. Is there an options to so. To add to the previous post, this is sometimes called "wireless isolation" in your router's GUI. Regards, Stuart

@ermal: I just put a fix on this. Please test later snapshots. Thank you very much, I'll wait for next snapshots and test it again.  ^^

No worries, i worked it out.. Authentication is now working to my FreeRADIUS server through captive portal. On a side note, does anyone know of any good software that i can use for billing?

The email could be sent with a bit of custom PHP on the portal page. The user being able to receive that response is the problem, with so many various mail providers you'd have to let them out to the entire Internet to reliably receive that response.

rc.prunecaptiveportal is run every minute so i do not think there is an issue there.

NO, it will run until completion.

Well the problem is solved. The problem was with client that didnt resolve dns right. After flushing dns everything woreked fine. BTW thx for reply.

Hi everybody, It works! Finally i've modified /etc/inc.captiveportal.inc with the following values : function getNasIP() {     $nasIp = "194.78.xxx.xxx";     if(!$nasIp)         $nasIp = "0.0.0.0";     return $nasIp; } and rebooted my device… (this is what I did not do first time) After this, my radius messages were looking better NAS-IP-Address = 194.78.xxx.xxx         NAS-Identifier = "456.yyyyy.be"         User-Name = "testuser"         Acct-Status-Type = Start         Acct-Authentic = RADIUS         Service-Type = Login-User         NAS-Port-Type = Ethernet         NAS-Port = 7         Acct-Session-Id = "221de044d5aee762"         Framed-IP-Address = 10.1.0.10         Called-Station-Id = "5c:d9:98:aa:bb:cc"         Calling-Station-Id = "00:21:5d:aa:bb:cc" Mister developers, is it not a way to add a field on captive portal configuration page to permit to manually change the WAN IP address? I think it should be grandly appreciated... Thierry

Suggestion: add a firewall rule (as near the top of the list as appropriate) for interface vlan1 to block (or reject) all access from vlan1 net to 10.180.1.0/24. Then go to Diagnostics -> States, click on Reset states tab read the explanation and click on the Reset button.