2nd Captive Portal - no Portal login
-
Hi,
I am using pfsense 2.4.2_1 on 64-Bit PC with 6 network cards.
There are 2 interfaces for internet and 1 for fallback with LTE.
My internal LAN interface use the captive portal. It works fine.I want to use WLAN interface with a new captive portal configuration. It is only showing me the portal login page by typing e.g. http://10.10.10.10 (This address is not existing).
When I use a voucher every thing is working. But why does it not come up with, e.g. http://kb-consulting.de?My firewall settings are:
-
…... http://10.10.10.10 (This address is not existing).
The address must exists, assigned to an interface.
edit : or are you hiding RFC 1918 addresses ?? ;D
When I use a voucher every thing is working. But why does it not come up with, e.g. http://kb-consulting.de?
The way you authenticate isn't related to a login portal showing, or not.
Add a host override on the DNS Resolver tab, using "kb-consulting.de" is the IP of the your captive portal NIC.
I use : portal.my-domaine.tld = 192.168.2.1 (192.168.2.1 == OPT1 == my portal). I'm using https pages thus "portal.my-domaine.tld " is a must. With an IP it won't work anyway (Certs from Let's Enscrypt).Btw : when showing firewall rules, do not omit the interface name. Note that GUI firewall rules are taken in account when authenticated. There are other rules, to see them : https://doc.pfsense.org/index.php/Captive_Portal_Troubleshooting - looking at them is very self-explaining ;)
-
The target address http://10.10.10.10 is a way, to be automatically redirected to the captive portal.
Another target like http://kb-consulting.de will not be redirected to the captive portal.Targets like https://www.google.de were not working since I started with the captive portal since years.
So this is the second captive portal on my firewall and the description at captive portal troubleshouting is a friend of mine. Unfortunately without an answer specially on the second installation of a captive portal.
-
The target address http://10.10.10.10 is a way, to be automatically redirected to the captive portal.
Another target like http://kb-consulting.de will not be redirected to the captive portal.So, with other words, without DNS it works, with DNS (kb-consulting.de will be resolved first) it won't.
You are good for https://doc.pfsense.org/index.php/Captive_Portal_Troubleshooting first paragraph, first line.Targets like https://www.google.de were not working since I started with the captive portal since years.
That's ok, normal and, if you think about it, a dmmd good thing.
Read this again : Using a few words : when a NIC (wifi, or cable) connects and comes up, it launches a 'hidden' basic http (not s= request) just after the classic DHCP negotiation.
Every OS uses its own 'test' URL.
If the request resolves (DNS = OK) and the page comes back with a "200" result (means page loading ok) and the result is a know reply, like the simple word "Succes",
then the OS knows it has a live Internet "connection". No more questions asked.
If not, it presumes it's behind some captive portal, and relaunches the request, but this time it opens a (simple, build-in - or system default) browser first.
Result : the page send back will be … not the word "Succes" but the ... pfSense login page.(Yes, that's the way it works - most of the captive portal support actually build into your device already).
A https request won't work because :
When a browser send out a request, it resolves the URL first - the domaine part - and the reply back should contain a certificate. This certificate should contain the domaine name you used in the URL. If so, green lock - if nothing, your browser will yell.
Now .... do you have certificate like google.com ?? Or, could your portal answer with a certificate that contains Facebook.com or google.com ? Never !
But this issue actually doesn't exists because your OS, and you, already took care of authenticating when the connection came up. Hitting the portal with an initial https request shouldn't happen.
I'm using the portal in a hotel. This means : clients who know nothing about nothing. Still they connect just fine. And believe me, my portal saw every device that exists, during the last 10 years now. -
Thank you for your very detailed answer.
First thing - I will give DNS a try. Entry with DNS allow. Same error. No redirect.
Second thing - When a client/customer has a "starting page" in the browser with a target https, what is your captive portal doing?
Third thing - pfsense book, I will talk to my boss for gold subscription.
-
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'.
Typeping google.comThere 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.
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).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.
