I have a few tips.
But first : you are using the latest (2.3.4-RELEASE-p1) .version, right ?
If not, well ….
Start by saving your config for later analysis, and bring all settings to default.
Leave LAN as proposed.
Setup your WAN connection.
Now, check that you have an Internet access from any device on LAN - and pfSense of course.
Create a group called "portalusers", and assign it this privilege "User - Services: Captive Portal login".
Create a user "test" with password "test", make it member of the portusers group.
Activate captive portal.
Set "After authentication Redirection URL" : set it to whatever, but something correct like : "https://www.google.com"
Authentication method ; select "Local User Manager / Vouchers"
Save - the portal is running now.
IF you use LAN as the interface for the captive portal, no need to add or touch the 'hidden' GUI firewall rule (actually, you can't - its hidden) . The default 'pass all' rule will do for now. DO NOT ADD anything. It's ok like this.
Now, its time for some basic checking.
On the device you use for testing, BREAK the connection (rip out the cable - switch off the wifi radio).
Activate it.
Get a command prompt ( run cmd, open a shell session, or, at least, go view network connection settings)
CHECK if you obtained an IP - and it which MUST be in the range of the DHCP server that's running on the captive portal (your LAN or OPTx interface on pfSense).
This implies that DHCP (client) must be active on your device.
Check also : what is the gateway on the device ? Must be the IP of pfSense. The DNS MUST be pfSense also (same IP gateway).
Now, for the most simple test - and most f*ck up here : ping to google.com (NOT to 8.8.8.8 !) do this : "ping google.com".
There will be NO ping replies but the name resolution part (translating google.com to 216.58.198.206) should work. This shows you that you can not reach the internet, but, somehow, DNS still works. DNS HAS to works, otherwise the captive portal doesn't work - or "no device on the LAN will work".
DO NOT use the DNS Forwarder - use the default DNS Resolver on pfSense. ( This is part of the golden rule : keep everything to default except if you know how to deal with it )
Bookmark and read this : https://doc.pfsense.org/index.php/Captive_Portal_Troubleshooting
Now, when your device has an IP, a DNS and a gateway, you see that you do not have to open a browser (you shouldn't do so - if it has a default home page to a https site, things will break because your browser will NOT accepts replies from any site except this https site.
So, a browser will up all automatically - windows launches one after a popup, iPhone/Pad will do so by themselves, Android : I don't know but I guess they do
This browser will go to some http:// site and, by magic, gets redirected to the page that the pfSense serves : our built in login page.
If credentials are ok, you will get redirected to our "After authentication Redirection URL" which proves right away your are connected.
Note : it takes 5 times more time to write this up as setting up basic captive portal access using pfSense.
Btw :
"even activating DHCP …." ?? without it you'll be an expert to make it work.
"activated a Proxy on the browser " : What ? Why ?
Do not edit the default login page except if you have some minimum html knowledge, respect the minimal 'html coding' as shown on the captive portal settings page.
"do not start with radius" or whatever (proxies like Squid) . radius is nice if you know what it is. Know how to set it up. And, most important, know how to debug it, and know how to debug the inter communication between pfSense and radius. As usual, hours and hours of reading will reduce setup time to minutes.
Do not make complicated setups: keep it simple. These tend to works for years - mine does now for nearly a decade ( !! ).
Read - but do not trust - what you find on the Internet. Most isn't recent, talks about old version - ALWAYS miss an essential thing (up to you to find what it is). pfSense.org pages are valid, the rest is just a story of a guy writing up something ones.
Always make a minimal working situation first, then add very small steps towards your final setup. When errors are shown you can focus very easy on what went wrong, and go back to the working situation "with one click".
The captive portal can work on LAN, but it really works best on a separate, dedicated interface, like OPT1. You can put on that interface special firewall rules for captive portal users. This is a chapter of itself, and depends on what kind of visitors you have on your portal.
