@Nachtfalke: Or adjust the DHCP lease times. But the lease time should not be lower than the hard timeout set on CP. Ok I will try this. My hard time is 30 minutes. I gave lease time 2000 seconds.

I'm not sure what the relation is between both code dumps? Can you give us some more information? Can you see that the actual post request is done``` ($.post('captiveportal-x.php', $("#testform").serialize());) To see this you need to change the return of function 'mycall' instead of 'false'

ok, ipfw is used to manipulate the stateful firewall, found that.  so when I executed the ipfw command to delete two rules concerning a test mac, the firewall did indeed deny outbound and inbound access to the machine without logging into the captive portal. Now, one would think that the passthrough mac address page would, when refreshed, show that this mac has been deleted, but no.  so obviously the information is being cached somewhere.  Even though it showed as a pass through mac, ipfw had successfully (of course) deleted the rule.  When I edited the mac entry, and saved it, it went back into the ruleset for ipfw. Question remains:  where is this information cached?  is it encrypted?  Standing by…...  :)

I just tested voucher codes from roll0 and roll1 which I generated nearly two years ago.  None of the voucher codes were reported invalid. I wonder what is different about your test.

NO. That you can enforce with proxy servers like squid etc…. You can install the squid proxy and have that done but ssl traffic still cannot be modified like that.

Reverse portal functionality is not implemented. Also the sms workflow needs development to be integrated in pfSense since there is no tool today to send sms from CP itself.

I found the problem, I was using the default login page for the pfsense. The problem is that if you use the default login page, the method and post attributes of login form are marked as comment in html e.g . I removed the comment from the tag, now it is working fine.

I do actually store a couple cookies on the users device when they come through the portal.  As my portal asks for their name, postcode and email as they passthrough, I store these in a cookie so when they return another day, the form is already populated with their details and a message "are these details correct" is shown.  I could use these cookies to see if the user had been logged though already based on the cookies timestamp. Still not had chance to have a play yet.

the AP are connected in layer2 to its controller in network 192.168.1.x Only the controller (appliance) have an ip address 192.168.1.10, all the AP haven't ip because they operate in layer2 with the controller. My pfsense server have the wan on 192.168.2.x, both the Vlan (192.168.2.x and 192.168.1.x) are routing and managed by a layer3 switch. My pfsense server have the lan on 192.168.100.x and it is the DHCP for that lan. When I connect smartphone/laptop to the wifi-guest vlan(192.168.2.x) the device obtain the correct configuration by the dhcp server of pfsense (192.168.100.x) but when i try to navigate the browser report "timeout". When I connect laptop to the wifi-guest vlan with the cable the device obtain the correct configuration by the dhcp server of pfsense (192.168.100.x) and when I try to navigate the browser go to the captive portal page, I insert the voucher and the session start correctly So, the problem is certainly due to the controller but I do not understand what's wrong, on the controller I activated a external captive portal and I insert 192.168.100.1 and 192.168.2.1 (the lan and wan ip of pfsense) but still not work. ok guys, I resolved myself the problem. In controller setup I change the network class and now works!!!!!!!! :) I still have another little problem, when open the browser you are redirect on captive portal login page, but if your default browser's page is httpS:\xxx the browser don't redirect automatically, but if you enter an http://xxx web site the redirect works again. anyone has any suggestions?

Check this blogpost out. The blog got other nice pfsense posts about captiveportal and openvpn as well. http://blog.stefcho.eu/?p=754

Well, managed to upgrade the master node to 2.1 too. So both nodes are running on 2.1. Voucher synchronization still not working - after I fill Voucher database IP, sync port, username, password and click Save, no error is shown, no synchronization is done and the "Voucher database synchronization" fileds are empty. Also I see Zones in Captiveportal, but haven't seen where I can fill the zone name?

Thanks… I somehow didn't see it. I set that portal up a year ago and never change anything there. Did the change remotely, so I didn't see the result, but it's probably fine. I already had the /22 network as trusted as a workaround, but reverted that setting.

@nothing: Just add your DNS servers to "allowed ip addresses" in captive settings. I can confirm that this is probably the problem. /erik

No worries, sorry my explanations might not have been the clearest. Glad you got it working. Send me a pm if you have any problems, just starting to learn server 2012 myself for work.

Maybe you are using external DNS, which you should add to "Allowed IP addresses" in Captive settings? Try browsing any IP address instead of hostname - 1.1.1.1 for example.

You have to change the ipfw fwd line as it was back in 2.0 or 1.2.x days to redirect everything.

H'm, still having troubles understanding the problem. Let me get this straight: You connect yourself with a PC to repeater1 - you use the voucher and it works. Now, you move on to the next repeater, call it repeater2, and you have to re-authenticate again, with a new voucher. Is that right ? Can you tell me what your IP was when you connected yourself to the portal when you were using repeater1 ? What is your IP when you use repeater2 ? Btw: normally, to make things simple to work with, you have some work to do. Behind the Portal-interface-NIC, you hook up a switch. On this switch, you hook up - by cable - all your wifi access points, and theses boxes should work in AP (Access Point) mode. These AP's should have their DHCP server function shut down. Never use the WAN ether net port on these devices (if one is present). I have many 'DD-WRT' on WRT54GL working like this for the last 10 years. Using repeater might change the IP …. this messes up the portal authentication. Using repeater might change the the MAC .... this messes up the portal authentication. "Repeaters" are nice boxes, but you only use one if nothing else is possible. You only move the 'cable' problem to a 'logical network' problem. Btw: I had some good experiences with AP-boxes using "WDS" mode.