So after our supervisor borrowed the router I'm using as a WAP, I remembered I still have another REAL (lol) AP.
I set it up and tried changing between the APs. Now I don't need to re-login.

"Much ask. Such noob. Wow."

lol TYVM. :)

Behind the "Captive Portal NIC", there shouldn't be any device that acts as a router.
(Some special VLAN cases might be an exception here)

'Router mode' should be deactivated on Wifi Access Points.

I protect my AP's with a firewall, so no connection is accepted coming from clients on "Captive Portal OPT1", except those coming from pfSEnse, so I can manage my AP's.

Two choices:

1. Do not forward HTTPS requests to the captive portal. HTTPS requests just hang.

2. Forward HTTPS requests to the captive portal and generate certificate errors for your clients.

Neither is perfect, but option 1 is IMHO better than option 2.

This is not a captive portal problem. HTTPS/SSL/TLS is designed to prevent a man in the middle from displaying content without generating a certificate error.

Since this thread appears to be written entirely in Japanese Haikus: ;)

A common problem
While info is lacking
No answer may be known

What hardware are you using?  Alix? I would think even a pentium 4 could handle this with no issue.  What is the make of the AP?  Is your link 10,100,1000?

@Gertjan:

Time to detail :
Your network setup.
DHCP server settings
How many entries in dhcp leases file (here : /var/dhcpd/var/db )

Use also all the https://www.google.fr/search?q=FreeBSD+dhcpd:+DHCPDISCOVER+no+free+leases&ie=utf-8&oe=utf-8&gws_rd=cr&ei=B6XzVtL1L4Pyav2Fr_gJ wisdom …..

i am running captvie portal with almost 220 device registered with us. i have 20 Mbps two links that i am using both by loadbalancing.

I suggest to set the redirection url before and after authentication
it is good also to isolate these different subnets of captive portal interfaces from eachother by using Aliase and apply this aliases in the firewall rules of each captive portal interface.
i read once but i am not sure if this is correct , Apply Captive portal always on Opt interface not LAN interfcae

Bet Wishes

@assistenzanet95:

@Derelict:

So when LAN is disabled can CP clients resolve names?

Can they ping OPT1 address?

Do you have anything in Allowed IP addresses or Allowed Hostnames?

What happens if you put http://10.10.10.10/ into a browser on a CP client?

What version of pfSense is it?

No when i disable LAN i can't resolv names on CP

You have something hosed. You are going to have to post screenshots of all your interfaces, all your firewall rules, and all your CP settings. Could be one or more of of a 1000 different things.

Yes i can ping the entire OPT1 network, but i can't open the  webpages oh the antennas.

I presume antennas means access points. I don't know why you would want to be able to access your access point web interfaces from the portal network. Most people want the opposite.

Yes in the allowed IP addresses i have about 70 antennas and about 20 Allowed Hostnames

Again, no idea why you care about the access point web interfaces from the portal network.

Nothing happens if i try to open http://10.10.10.10, my OPT1 address is 192.168.100/22

The point is to eliminate the need for working DNS to get the portal page. If it doesn't come up it's broken. Again, screenshots of everything.

My version of pfSense is 2.1.1

Ancient. Upgrade. At least to 2.1.5 if you want to take small steps.

@strike101:

the voucher is set to expire after 3 days

i haven't checked the DHCP lease time.. it's on default AFAIK,

Takes 3 seconds to check ….. and far less then 3 days by default .....

Going from the very old 2.2.3 to a beta version ….  :o
What about the current 2.2.6 ? ( $PORTAL_ZONE$ already exists in the current version https://github.com/pfsense/pfsense/blob/RELENG_2_2/etc/inc/captiveportal.inc#L60 )

@cmb:

@dpacheco:

The image show $PORTAL_ACTION$ no $PORTAL_ACTIONS$  (custom portal page have been working fine since 2 years and haven't been changed).  Don't know how this is treated by pfSense, but it seems that this is the normal behavior, at least for what is seen when everything works fine, client POST to /$PORTAL_ACTION$ and is redirected to the $PORTAL_REDIRURL$

I could have sworn it was typoed in one of those screenshots, but on second look, apparently not. It is still a problem that it's in there that way though, what are the contents of your portal page?

Ok.  The actual login page is a PHP file that detects if browser is a desktop or mobile one and redirect to a HTML file, which is uploaded directly on pfsense box by the file manager tab.

func_desktop.html.txt
func_index.php.txt
func_movil.html.txt

Hello,

I've finally posted the how to that goes with my single step captive portal wrapper here https://forum.pfsense.org/index.php?topic=108493.msg604190#msg604190
If you find this useful, could you consider putting it as sticky post ?

Regards,
Ozy.

You're trying to route traffic from the WAN side of the PFS. This is completely wrong. You seem to be trying to use your firewall as an internal router. Any traffic passing through from the WAN side needs to be port forwarded, which isn't really what you want to do here. Set the captive portal on the LAN side and route your guest traffic through from LAN to WAN, using the WAN address for managing the PFS. It's how firewalls are supposed to work.

Hi,

I create qrcode with this link : http://xxxxxxxx.fr/ubhZKcJbY6a3 (replace xxxxxxxx.fr with other website, ubhZKcJbY6a3 is a voucher code)

When user scan qrcode, it will redirect to portal auth page and the voucher field will autofill.
If a user is redirected with other url, the voucher field will empty and he could authentificate with his credentials.

$URL = htmlspecialchars($_GET["redirurl"]); if (strpos($URL, 'http://xxxxxxxx.fr') !== false) { $Code = str_replace("http://xxxxxxxx.fr/", "", "$URL"); } else { $Code = ""; } ?>

The problem sounds like a DNS issue. As to why, you'll have to provide some more information first. Like what DNS server(s) are you clients using? And what tests have you run so far? Have you tried running a dig or nslookup against any of the problem sites from a client? If so, what response do you get?

Yes.  Actually @Gertjan was correct. I can now access the server by putting it in the allowed IP list. Thank you!

on your captive portal form you can use the macaddress through this codes:

$arp=`arp $ipaddress`; #run the external command, break output into lines $lines = explode(" ", $arp); $macaddr = $lines[3]; #Actual code