Hi, You should tell us more, much more about your setup. Right now, I default to : your setup is wrong. You should correct it. Captive portal works fine for me for years now.

@mostafa.adel: only open when i am write any ip on URL like 8.8.8.8 This looks and smells like a DNS problem (DNS is the thing that translates domain names like pfsense.com to 2610:160:11:1000::18 (or the old fashoined IPv4, I guess it still exists). So, the ….. /  ..... continue to read here : https://forum.pfsense.org/index.php?topic=130521.msg723896#msg723896

@chek69: You checked you firewall ? well, as he said, … My start page, or any other page, opens immediately .... traffic (http https and - important - dns) works …. The default pfSense rule " let everything go out " should be in place. And the same firewall rule would be enough to make the portal work. I'm presuming of course, this still is a typical case of "My firewall doesn't work and I'm NOT showing you my firewall rules so you could NOT see why it doesn't work …" I connect a device to the LAN network Detail the connection please - is this by wire ? Or Wifi, and thus an AP is involved … Or : Others are uploading their own 'portal page' without knowing that "html" is not a human language, the slightest error will take everything down ... (the built in page works great). Help exists for many years already. This page will cover 99 % of all problem case : https://doc.pfsense.org/index.php/Captive_Portal_Troubleshooting

Can you give us more informations

In your Captive Portal configuration, you 'll find Concurrent user logins = If enabled only the most recent login per username will be active. Subsequent logins will cause machines previously logged in with the same username to be disconnected.

Every wifi device that joins your network takes a DHCP lease whether they go through your portal or not. The pool size needs to be sized to accommodate your device churn and your lease times and your portal timeouts, hard or idle.

hello , tough able to login into the pfsense webconsole using  the ldap user by giving it the webcfg privileges , it just works.

@stinkfly: It seems like when you tick the authentication method as Local User Name/Voucher, you don't have a choice, you have to use all 3?  Is this correct? When using vouchers, guest do not enter a user name and password, just the voucher. Even if these fields are present on the login page, the voucher ID is the one that will be used. Of course, this ID is the only identification the system has when it shows who's online. @stinkfly: What's the benefit of using Freeradius over a local database?  Number of users will be < 100, so scale shouldn't be an issue Example : "FreeRadius" can instruct the portal for each user a dedicated bandwidth. Or : How long a user can connect … Or : .... (see Google "pfSense + FreeRadius) => Answer on first link : https://doc.pfsense.org/index.php/Using_Captive_Portal_with_FreeRADIUS

Are you using a wifi access point, or a router? If its a router, you are performing a nat before the Captive Portal.

It might be easier for you to use a Ubiquity access-point and cloudkey controller as you have staff that are non IT types. You can set up guest access with a hotspot and use an app on an iDevice, Android device or web browser to print vouchers. Just remember to create a firewall rule out the guest network to the cloudkey port 8880. I had a play yesterday and it was quite easy to set up, NB I have multiple VLANS and have now disabled the hotspot SSID.       [image: IMG_0049.PNG] [image: IMG_0049.PNG_thumb]

Figured it out. In my nas table in the database, I thought "nasname" was a name/description of the NAS. Turned out to be the IP address, so after changing that everything is working as expected.

That happens when the device thinks the page it was originally going to is the portal page itself. I have found that about the only way to defeat it is to use an after-authentication URL redirect. You could probably get clever and test if the redirect URL is the portal page and, if so, issue a redirect somewhere, else redirect to the original browser request page. Or just forget about trying to send them to the page they originally requested and do the after-auth redirect.

@maxkoning: Thanks! But you didn't make this captive portal. You just edited it. Kindly read all the contents. Thanks!

@bear410hk: I dont know it is a bug or only my setting problem. anyone know what the problem in my case ? Thousands, no billions of people are using the captive portal every day. Another use number are those using IE11. So, that rules out the non-capabilities of pfSense : it works (for years now). The only thing we - and you as it seems - don't know is : how did you set it up ? For example : Using the build in logging page : it will work - you made your own and something is broken … so ;) Tell us more, and we might be able what you should or shouldn't do.

@androhit: Can anyone plz guide me to build this functionality in php or html 'html' (or even php if you which) is need to make your own login page, the one you upload here : Services => Captive Portal => [YOUR ZONE] => Configuration. Then, have a look at /usr/local/captiveportal/index.php : the file that uses your upload 'htmlt' file. And, as you can see in this "/usr/local/captiveportal/index.php", this file will tell you everything : /etc/inc/captiveportal.inc - that's will be be the place where  you 'interface' with the "Local user manager". So, two things : you should definitely know something about php, so you can read how things are done, and you will wind up having the knowledge to be able to  change the current system to something that needs YOUR typical needs.