@krischeu:
First thing - I will give DNS a try. Entry with DNS allow. Same error. No redirect.
Testing your DNS:
Use a PC with command line access.
Connect to you portal network.
Do not use the portal login page - if it shows up, just close it.
Open command line "cmd'.
Type
ping google.com
There will be no replies, but the domain should be resolved (google.com becomes [216.58.213.142] for me :
C:\Documents and Settings\Gertjan.BUREAU>ping -4 google.com
Envoi d'une requête 'ping' sur google.com [216.58.213.142] avec 32 octets de données :
....
....
This means DNS is ok - resolving works.
@krischeu:
Second thing - When a client/customer has a "starting page" in the browser with a target https, what is your captive portal doing?
Read this : and start at here Read this again
So : you cable up, by plugging in the RJ45 plug - or you select a portal Wifi network (never ever have your device auto select Captive portal networks - selecting it needs manual interaction = you as a person entering voucher codes or user/passwords)) and the "login browser will popup. These codes may change, so automatic Wifi connection won't 'help' you here.
If it doesn't - upgrade your OS. Most OS's (Microsoft, Apple, Debian, Android's etc work fine).
@krischeu:
Third thing - pfsense book, I will talk to my boss for gold subscription.
The book talks about pfSense.
Captive portal handling is not a real pfSense thing.
It's more an unwritten RFC.
I tend to say : if your DNS is ok, Captive portal works.
(other problems are often : non-pfSEnse related : AP not setup up correctly. VLAN mess, etc)
Btw : I'm using the default Resolver (not the Forwarder) - my interface is OPT1 using IP 192.168.2.1/24. This is the gateway and DNS for all connected clients. When a client connects, it receives 192.168.2.1 as a DNS - and 192.168.2.1 as a gateway - and an IP like 192.168.2.x
When I check my ipfw tables / rules, as explained above - I have :
...--- table(CPZONE_NAME_host_ips), set(0) ---
192.168.2.1/32 0 1068615 38261875 1522157881
....
which means that all connections send to "192.168.2.1" (the gateway and DNS for my portal) are passing.
No need to create a firewall rule for DNS traffic for my captive portal (on the interface for my portal) - it works out of the box - as long as you keep settings "out of the box".
Note : your DNS resolver should 'listen' to all interfaces - or at least to your local 'LAN/OPTx' interfaces ! Does it ? Same thing for the DHCP server.
What are your tables / rules ? ? ? ? ? ? ?
The images :
Image 1 : connection to the Portal network - called "BritHotelFumel". The "warning shiled" indicated that this network is not protected with WPA - that's ok for a captive portal network)
Image 2 : I connected to network …. Windows shows a popup (!). Click on this popup.
Image 3 : My default browser opens (remark : mine is FF with an empty page) It was NOT redirected to my portal login page. No problem, I enter http://www.google.com and bingo : my portal page shows. As you already know, typing https://www.google.com will fail.
On my iPhone all this is much simpler : I select a (my) captive portal network, the login portal shows. Period.
A Android … well .... I know more the day I have an android device. I know that my clients can work with my portal, so I guess it's ok.
1.png
1.png_thumb
2.png
2.png_thumb
3.png
3.png_thumb
