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.

    a29acd86-017f-4fe0-ac56-85449940391c-image.png

    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:

    1. Check that you receive an IP - network - gateway and DNS
      All is OK. Received IP successfully from pfsense.

    2. 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.

    3. 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".

    0802553a-f1e1-437b-9036-5927f1e78cae-image.png



  • 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:

    ba37bdb8-3955-4cab-b599-3bb27d4817b0-image.png



  • 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.4

    It 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" :

    7c7b2e0c-f891-41b4-95e1-ad608861612f-image.png

    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 any
    

    The 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.

    c170c235-1dc2-4540-9ae8-f03ac3392832-image.png

    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=cpzone2
    

    and 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 ...


Log in to reply