Users need to detect portal manually (no pop-up browser or something after connection)
-
Hello. I am in trouble with Captive Portal configuration with pfSense.
I've heard that major devices and browsers do captive portal detection automatically. So when devices are connected to the network, they show a message like "You need to login to this network.', then redirects to login pages.
But in my environment, it seems that this process is not working well. Every guest except windows user must open the browser and type any URL that not using HTTPS manually to log in to my network. This really annoys my guests.
- Android devices send me the notification "Log in to the Wi-Fi network", but when I touch that notification, a new window pops up and closes immediately.
- iOS devices do nothing. No notification or pop-up browser for login.
- macOS also do nothing either.
- On Windows machines no problem. When I connect to the network web browser opens immediately and shows me the login page.
I am just wondering why Apple devices just do nothing and why the pop-up window closes immediately on Android. I am no idea even if apple devices do detection automatically or not.
Since I forced to use DNS resolver as my pfsense machine, so it would be not a DNS problem.
What should I do to fix this problem?
-
@guswogjs499 said in Users need to detect portal manually (no pop-up browser or something after connection):
so it would be not a DNS problem
It is a DNS problem.
That is, without even knowing about your setup, I have a very big chance to be right.
A captive portal is actually build more on OS support as pfSense support.Do this test :
Connect to your Captive portal network - wifi or cable.
Check that you receive an IP - network - gateway and DNS. This is done typically when the client is using a DHCP client - and the pfSense captive portal interface has a DHCP server activated.
The gateway and DNS are typically the IP of the interface that pfSense uses for the captive portal.
Now - before authentification - ping something like "google.com".
There will be no reply, but the URL "google.com" should be resolved = you will see an IPv4 being used for the ping.
Try with some other urls to be sure.
This test assures that DNS = name resolutions works and is aviable for the captive portal clients before identification, right after DHCP did it's job.Read also Troubleshooting Captive Portal
My experiences show me, for the last several years, that Apple devices detect the portal always, as do Miccrosoft devices. samsung stuff had it ups and downs, but recently, for a year or two now, they work well now. Nobody comes to see me because they can't connect. These nobody's are clients of a hotel, who often don't know shit about portals etc.
When you log to a remote syslog system, you can actually see more details about the captive portal inner working : the web server that hosts the login page will dump the http(s) requests it received from the client's devices.
Also : it's not a secret any more that https portal requests seem to work much better as http portals.
This means you need a certificate that is accepted by the browser on the client's device : it should be signed by a known certificate authority. The acme package comes into play here. And you'll be needing a domain name, which enables you to create a cert like "portal.your-domain.tld".edit : iOS devices : this might be of interest.
Also : use the portal on a dedicated interface / network - activating it on LAN makes things more complicated, although it can be done.
The captive portal can be set up with pfSense not being the DNS.
The captive portal can be set up with pfSense not being the gateway.
The captive portal can be set up with pfSense not being the gateway.
But before you set up your portal, first, make it work as shown in the two official Netgate's videos. When that works for you, add changes step by step and test - test - test. -
Thanks for your reply sir.
I've just tried the test you posted in macOS. And here is my resut:
-
Check that you receive an IP - network - gateway and DNS
All is OK. Received IP successfully from pfsense. -
Now - before authentification - ping something like "google.com". There will be no reply, but the URL "google.com" should be resolved
Exactly. No reply, but google.com was resolved. -
Try with some other urls to be sure.
Tested with msftconnecttest.com, apple.com, connectivitycheck.gstatic.com. Same as 2. My terminal shows me each URLs IP, and no reply from ping.
I already reviewed that pfsense official document but no luck.
-
-
@guswogjs499 said in Users need to detect portal manually (no pop-up browser or something after connection):
All is OK. Received IP successfully from pfsense
and the other 3 ?
"IP" must be in the pool of then DHCP server used on the captive portal.
DNS and Gateway should be the IP of the captive portal interface.
Network mask should be ok - typically a /24.What are your captive portal firewall rules ?
When you start, you should have one rule :
"IPv4 pass all".
-
In actually, I am using a VPN connection. So what I can clearly know is the client IP - which is in the pool of the DHCP used on the captive portal.
This is my firewall rule:
-
Again :
What is your client IP ?
DNS IP ?
Gateway ?If your are using a Microsoft device, type
ipconfig /all( info can be obtained by 'mouse' also )
@guswogjs499 said in Users need to detect portal manually (no pop-up browser or something after connection):
I am using a VPN connection.
What has that to do with the captive portal ?
Using the captive portal over VPN ? That's most likely a no go.
Setting up a captive portal for the first time over VPN ? Forget it.
Also : really, reserve an dedicated interface for the captive portal. Captive portal visitors are "non trusted" network clients, and have nothing to do on a LAN network, by default "trusted".Most important : make it work using a known, default setup.
When it works, and only then, you can deviate from the known path, step by step.Note : on a clean 3 (three !!) NIC pfSense device that you've installed 10 seconds ago, you can set up and activate a captive portal in less then 5 minutes.
Proof : Captive portal on 2.4It is possible to use the LAN as a captive portal. Just be aware of browser caching and firewall state, among others.
-
Sorry for my late reply.
I reviewed my system and confirmed that there is no problem with IP addresses except gateway. Client IP is in pfsense DHCP pool, DNS resolver is pfsense. But I am using VPN connection, "ipconfig" command gives me "blank" in default gateway section.
And yes, I am setting up a portal over VPN; since I need to pop up a website when users connect to my VPN service, so I am trying to use Captive Portal service in my VPN. If this idea is impossible, please let me know.
-
@guswogjs499 said in Users need to detect portal manually (no pop-up browser or something after connection):
If this idea is impossible
Never tried it. I tend to say : your are the first.
So : you tell us.I have a question : a captive portal is a system that shows some text on a browser screen before the visitor access resourcess like the Internet.
All these visitors gave one thing in common : the are unknown to your network. You, as an admin, you don't know who they are. You never met them, You can't contact them.A VPN access to your network : everything is the totally the opposite : you know who they are, you gave them instructions about how to contact your server, you gave them probably unique certificates, surely access codes, passwords, probably programs etc etc.
And you still want them to s a captive portal login page ? To do what ? To re do another form of login again ? To show them something ? What about sending them a mail with the info ?Note : I admit : because it takes 30 seconds or so to activate a captive portal on an "VPN type Interface" :
I activeted on this interaface.
From a pfSense point of view, I have a second portal now.But .....
Looking a little bit more closely, I knew it was a no-go for sure :01000 16792437 13322481061 skipto tablearg ip from any to any via table(cp_ifaces) 01100 129678999 98884667447 allow ip from any to any 02100 0 0 pipe tablearg MAC table(cpzone1_pipe_mac) 02101 0 0 allow pfsync from any to any 02102 0 0 allow carp from any to any 02103 13287 0 allow layer2 mac-type 0x0806,0x8035 02104 0 0 allow layer2 mac-type 0x888e,0x88c7 02105 0 0 allow layer2 mac-type 0x8863,0x8864 02106 1027 0 deny layer2 not mac-type 0x0800,0x86dd 02107 33222 2597331 allow ip from any to table(cpzone1_host_ips) in 02108 55419 8372687 allow ip from table(cpzone1_host_ips) to any out 02109 207 66899 allow ip from any to 255.255.255.255 in 02110 0 0 allow ip from 255.255.255.255 to any out 02111 908 91676 pipe tablearg ip from table(cpzone1_allowed_up) to any in 02112 1432 113829 pipe tablearg ip from any to table(cpzone1_allowed_down) in 02113 1393 1436314 pipe tablearg ip from table(cpzone1_allowed_up) to any out 02114 243 18468 pipe tablearg ip from any to table(cpzone1_allowed_down) out 02115 7093749 1438943159 pipe tablearg ip from table(cpzone1_auth_up) to any layer2 in 02116 9524100 11855615143 pipe tablearg ip from any to table(cpzone1_auth_down) layer2 out 02117 20092 2158055 fwd 127.0.0.1,8003 tcp from any to any 443 in 02118 3752 367769 fwd 127.0.0.1,8002 tcp from any to any 80 in 02119 22865 9016893 allow tcp from any to any out 02120 20741 3682838 skipto 65534 ip from any to any 02200 0 0 pipe tablearg MAC table(cpzone2_pipe_mac) 02201 0 0 allow pfsync from any to any 02202 0 0 allow carp from any to any 02203 0 0 allow layer2 mac-type 0x0806,0x8035 02204 0 0 allow layer2 mac-type 0x888e,0x88c7 02205 0 0 allow layer2 mac-type 0x8863,0x8864 02206 0 0 deny layer2 not mac-type 0x0800,0x86dd 02207 0 0 allow ip from any to table(cpzone2_host_ips) in 02208 0 0 allow ip from table(cpzone2_host_ips) to any out 02209 0 0 allow ip from any to 255.255.255.255 in 02210 0 0 allow ip from 255.255.255.255 to any out 02211 0 0 pipe tablearg ip from table(cpzone2_allowed_up) to any in 02212 0 0 pipe tablearg ip from any to table(cpzone2_allowed_down) in 02213 0 0 pipe tablearg ip from table(cpzone2_allowed_up) to any out 02214 0 0 pipe tablearg ip from any to table(cpzone2_allowed_down) out 02215 0 0 pipe tablearg ip from table(cpzone2_auth_up) to any layer2 in 02216 0 0 pipe tablearg ip from any to table(cpzone2_auth_down) layer2 out 02217 0 0 fwd 127.0.0.1,8004 tcp from any to any 80 in 02218 0 0 allow tcp from any to any out 02219 0 0 skipto 65534 ip from any to any 65534 20741 3682838 deny ip from any to any 65535 13 864 allow ip from any to anyThe first part is my first working portal.
At 02200 start the ipfw rules for my OpenVPN portal.
There are no pipes ....... And no pipes mean : no good.Also : MAC addresses don't go over the VPN, so MAC filtering has to be disabled.
I activated a VPN access, and was not redirected to the portal - somehow ipfw rules (or the nginx redirecting setup) does not seem to work 'well'.
But visiting the portal with a handcradted URL = 192.168.3.1:8004/index.php.zone=cpzone2 did show the captive portal's login page - typing a user and password and ... I gained access to LAN and the Internet.
Strangely enough, when I looked at the ipfw rules and tables,
my successful login did not add my IP to the needed tables .....Wrong :
.... --- table(cpzone2_auth_up), set(0) --- 192.168.3.2/32 2014 0 0 0 --- table(cpzone2_auth_down), set(0) --- 192.168.3.2/32 2015 0 0 0 ....Let's be sure : make your live easier : no captive portal over VPN.
Or, make that nginx config part working ... and you'll be the first one
-
Thank you for the detailed reply.
This is my answer for your question:
— “To show them something?”
Yes. I need to do it. Might be weird, but it is the scenario I’m in. In my scenario, users connecting to my VPN is unknown, so no way to contact them. This is something kind of a free public VPN service.I understood that it is (almost) impossible to make a captive portal over VPN.. makes me find other alternatives.
-
@guswogjs499 said in Users need to detect portal manually (no pop-up browser or something after connection):
I understood that it is (almost) impossible to make a captive portal over VPN.. makes me find other alternatives.
There is hope.
Knowing now that the captive portal somewhat works on a VPN incoming connection, you should check up with the OpenVPN doc.
There is probably a command, to be place into the OpenVPN client config file - the .opvn file - that executes a local program to the client computer.
Just let that be a 'http://IP-of-your-OPENVPN-virtual-Interface:port-number-like-800x-you-have-to-look-it-up/index.php?zone=Your-zone-ID-you-have-to-look-it-up'For me it was
http://192.168.3.1:8004/index.php?zone=cpzone2and the captive portal showed up.
Automatic portal works well with the device I used to test - an iPhone, but I have to shut down the Wifi on my phone, using 4G, to be able to activate the OpenVPN client software. And in that case my iPhone doesn't do 'portal detection'.
Manually entering did work as shown above.And as already mentioned : disable MAC filtering on the OpenVPN Captive portal instance.
And take note : I use IPv4 and IPv6 for my OpenVPN connection so my phone prefers IPv6 all the way, bypassing the portal firewall ipfw completely. So, if you use IPv6, block it on your OpenVPN GUI firewall tab. And remove IPv6 support from the OpenVPN server.
@guswogjs499 said in Users need to detect portal manually (no pop-up browser or something after connection):
but it is the scenario I’m in
A problem without a solution isn't a problem.
Call Sisco for advise. You probably receive some free ( !!! )advise : Sorry, we don't have that as a solution ... -
"And as already mentioned : disable MAC filtering on the OpenVPN Captive portal instance."
It may be adding another layer of complexity, but there is an option within the OVPN service to use 'tap' mode which operates at L2 of the stack, so it may still be possible to use the MAC filtering with that. Or it could just break the entire setup all together, might be worth looking into though in order to add some measure of source validation even if masking a MAC is a trivial thing. For that matter on recent android builds, it's even automatically does so when logging into an unsecured WiFi net.
