Captive portal Help

[kylerees2023]

Hi All, im in need of some help with my captive portal. Im trying to set it up on my guest network so that when anyone joins you have to agree to the T&C's.. However once ive configured it, i try and join the guest network it connects but without internet and the captive portal page doesnt pop up. I delete the captive portal and i can connect back to the guest network again. Im just wondering what im doing wrong and if someone could help me out in setting it up?

Cheers

[Gertjan]

@kylerees2023

Your pfSense version ?

You want a guest network. If you trust all these guys, for the the easy mode : add a AP to your LAN, add a nice SSID, a nice easy password (or not) and you'll be fine : no portal needed.
If you don't trust the guys, and just want to give 'Internet' : a portal would do fine. I should use a dedicated interface, a OPT1 or LAN2, a second LAN with it's own IPv4 network, typically, LAN2, the portal interface using 192.168.2.1/24. Set up the DHCP server on LAN2 accordingly.

Initially : a pass all firewall rule on LAN2.

Very important : keep the initial, official pfSense DNS settings.

Also important : On this page you will find two (3 ?) captive portal video's. You have to see them. When you saw them, you know why.

Troubleshooting Captive Portal

Your devices have to use their default DHCP mode. Static settings can be used if you know what your doing. But you have to be sure about your "guests" ; by default, they don't know what they are doing. For example, if they have forced their device not to use the DNS supplied DNS, it's game over.

[oldschoolrouterjockey]

Hey @kylerees2023
Did you ever sort this out? Im having the same problem (SG-1100 pfsense+ 23.01) where theres no auth, i just want people to agree with T&C. I did look at https://docs.netgate.com/pfsense/en/latest/captiveportal/common-scenarios.html

And have checked:

• L1 - L3 is good as my wifi guests get the DHCP from my pfsense
• My wifi guests are using the DNS server fed to them by pfsense (the pfsense's IP local network address just like all the other interfaces)
• Pfsense's DNS resolver is set to allow all networks
• My wifi guests are also getting pfsense's IP local network address as default gateway
• The guest network was indeed automatically added to the outbound nat auto map rule
• For the time being there are no firewall rules blocking any inbound traffic into pfsense from the guest interface
• Im trying to force things by starting with an http-only URL to open on my wireless device.

What else is there to check on?

[Gertjan]

@oldschoolrouterjockey said in Captive portal Help:

What else is there to check on?

The logs
See here : StatusSystem LogsSystemGUI Service

Apple (iPhone; IPad, iMac ) devices will use this URL : http://captive.apple.com/hotspot-detect.html

192.168.2.156 - - [13/Sep/2023:06:46:40 +0200] "GET /index.php?zone=cpzone1&redirurl=http%3A%2F%2Fcaptive.apple.com%2Fhotspot-detect.html HTTP/1.0" 200 1503 "-" "CaptiveNetworkSupport-443.120.3 wispr"

Btw : 192.168.2.156 is the IP of the device connected to the captive portal - 192.168.2.0/24 is my captive portal network.

Another example :

192.168.2.198 - - [13/Sep/2023:07:13:05 +0200] "GET /index.php?zone=cpzone1&redirurl=http%3A%2F%2Fconnectivitycheck.gstatic.com%2Fgenerate_204 HTTP/2.0" 200 842 "-" "Mozilla/5.0 (Linux; Android 13; SM-G781B Build/TP1A.220624.014; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/116.0.0.0 Mobile Safari/537.36" 

192.168.2.198 is an android based device on the portal.

So, this android devices us the URL http://connectivitycheck.gstatic.com/generate_204

Do you see these request in the GUI log ?

connectivitycheck.gstatic.com and captive.apple.com are of course first resolved.

Why do devices connected to these URL as soon as they connect to a network, right after the the DHCP phase ended ? Because that's what all devices do these days. Even a "Microsoft Windows 11" PC does something comparable.
Note the http:// request - is won't be a https request.

The http request, coming into the pfSEnse portal web server, if it didn't contain "192.168.2.1" ** is rewritten as

192.168.2.1/index.php?zone=cpzone1&redirurl=http://captive.apple.com/hotspot-detect.html

and the original URL is added using the '&redirl' parameter.

** remember : my portal uses 192.168.2.1/214

This request will spit out the captive portal login page.

On the pfSense side, there is a firewall rule that redirect all incoming "port 80 TCP" (aka "http") to the internal pfSense captive portal web server.
Just above this rule are some 'table rules' : these contain the IP and MAC addresses of all the devices who are already granted access.

This :

@oldschoolrouterjockey said in Captive portal Help:

Im trying to force things by starting with an http-only URL to open on my wireless device.

Isn't needed.
My experience with the captive portal is : as soon as I connect my device, mostly using the portal's Wifi SSID, my phone, the captive portal login page will popup automatically.
This can't be an optional behavior, as I'm using the portal for a hotel. These "hotel clients" don't know nothing about "captive portal" or that they have to do something to get an working Internet connection, like using strange URL with an IP addresses (like 192.168.2.1) in it.
The same thing goes for the "free wifi" @mac Donalds, the local airport Wifi and any other public wifi hotspot.
A portal "Wifi SSID" shouldn't uses no encryption what so ever, as this isn't really needed : there is nothing to protect this connection. True is, that, as soon as portal clients have established a Internet connection with the portal, they activate their "VPN" and form now on, they are protected. Still a bit optional, as most traffic is https (TLS) these days.

Btw : "Wifi" is just a way of connection. When a device using a Ethernet cable, it's all the same : plugin in the cable, and the OS will pop up a notification or even a browser right away with the captive portal login page. Here also : no need to go looking for it.

At the end you'll be using the https login, as this permits to use a create a more understandable user experience.
Like : the SSID is called : "MacDonandsFreeWifi"
Instead of using http and presenting a captive portal logging page like http://192.168.2.1/index.php?zone... the user now sees

https://portal.MacDonandsFreeWifi.tld/index .....

This implies that you own (== rent) the domain name "MacDonandsFreeWifi.tld" (yep, a couple of $ each year). You can't just auto attribute this domain name to yourself. The browser the captive portal user is using on his device has to trust the domain name. With this trust, the login page won't show up.

edit :
I do not recall if there were any issues with 23.01. Normally, you shouldn't stay behind on updates / upgrades as this is a perfect way to have troubles (with issues that are already solved for others).
I'm using 23.05.1 and it works fine.

But when I was using 23.01 it worked back, from what I remember.

[oldschoolrouterjockey]

@Gertjan
OK theres nothing in the "GUI Service" logs except entries where I view those logs or do anything with the captive portal settings page. I cleared them all out and set it to display new logs at the top.

When I turn wifi off and turn it back on theres nothing new put in the logs after refreshing the logs page except my visit to that log page for GUI Service.

The same thing happens for both Androind and IPhone.

I did check again with 'arp -a' that the pfsense does see mac addresses corresponding to my 2 devices on the captive portal vlan.

Heres my firewall rule:

Heres my config page: (the very last on for HTTPS portal is past the bottom of this image, but it is unchecked)

[Gertjan]

@oldschoolrouterjockey

When you de activate the captive portal on the Guest network interface, and you connect a device, the device should have a working connection.

The interface settings :

Your one and only firewall rule for that interface is ok for right now.

The DHCP server settings for Quest interface should look like this :

Note : I've reserved 192.168.2.2 to 192.168.2.9 for myself - the APs on the Portal/Quest network.

With the above settings, you've created a 'normal' like LAN, network.

Check on your device that you obtained the correct IP settings using DHCP :
An IP like 192.168.2.x
The gateway should be 192.168.2.1
DNS should be 192.168.2.1
The network should be 255.255.255.0

TEST DNS on your device (always test DNS !) :
Use dig, nslookup, or use an app on your phone that can 'ping'.
Ping to microsoft.com.
You should see that 'microsoft.com' gets resolved :

..... microsoft.com [[20.112.250.133]] ...

and the bonus : ICMP should be getting back : ok, ping works.

If all this is ok, you can activate the captive portal.

I'll change my captive portal settings like yours as soon as my portal clients are gone (a hotel here). I'll post / edit back here in two hours later.

In advance :
Don't leave these two empty :

@oldschoolrouterjockey said in Captive portal Help:

When I turn wifi off and turn it back on theres nothing new put in the logs after refreshing the logs page except my visit to that log page for GUI Service.

The same thing happens for both Androind and IPhone.

When you shut down the Wifi on an iPhone, and the put it back on again, and select the Guest network SSID, check :
The IP - DNS - gateway(router) received. These should be ok.

The iPhone will throw out a request to "captive.apple.com" (see URL above).
So it will do a DNS request for first. Detailed unbound DNS logging will show you this request. This DNDS request should be made against pfSense - in my case 192.168.2.1 - your Quest network IP, Any other DNS (IP) is unreachable thus will break the portal functionality.

And last and not least : you've added a layer of complexity : VLANs.
My advise : go simple first: make a portal work on a physical interface.
Then : make a VLAN work (with portal).
Then : make a portal work on VLAN.

[Gertjan]

@Gertjan

I've rendered the captive portal settings as empty as possible :

I took my phone, and connected to the portal's SSID.

This is what I saw :

Hitting the login button logged me in - the internet connecting was ok.

192.168.2.6 is the IP of my Phone.

edit :
Hummm. Sorry.
This :

is not there by default - I had to remove that also.
I do think it doesn't really matter.

[oldschoolrouterjockey]

ok I took your advice and backed up a bit and disabled the portal. (I was already 100% confident of my vlans and layers 1-3)

Then tried again with the android and it still didnt work. So I SSHed to the android from my pfsense command prompt and found I could ping any IP on the internet but couldnt resolve DNS. so that was the problem.

I did a tcpdump from pfsense on the new interface and got this:

09:25:09.517923 IP 192.168.5.254.domain > 192.168.5.13.32096: 1716 Refused- [0q] 0/0/0 (12)

All my configs in the DNS resolver looked good so I stopped/started the DNS Resolver and reactivated the captive portal and now everything is working perfectly!

[oldschoolrouterjockey]

also as far as better locking down on the firewall rules, what is the bare min allowed into the firewall to permit things to work correctly?

Ive put this together but its apparently not enough? My goal there is to allow DNS, HTTP(nonS) and also 8002 from clients to the local firewalls address, and then to allow to get to port 80 anywhere on the internet except for things local to the firewall, then deny everything else local to my firewall before then allowing them to go anywhere on the internet.

Im guessing theres still something beyond those 3 ports Ive allowed?

[oldschoolrouterjockey]

as is customary for me, as soon as I ask for help I figure it out. I needed to add UDP there for that 1st rule

[Gertjan]

@oldschoolrouterjockey

Yeah, accepting DNS is a must have. DNS is mostly UDP btw, and rarely TCP.

@oldschoolrouterjockey said in Captive portal Help:

and also 8002

Don't need to do that.
The device will do the "http" (port 80) request initially. There is no need that the portal user needs to know that "port 8002" is used on the pfSense side.
Initial user port 80 traffic gets redirected at the firewall level to port 8002. The portal user's browser will never know it was talking to the server over this port. Or port 8003 when https is used.

# Captive Portal
rdr on igc1 inet proto tcp from any to ! <cpzoneid_2_cpips> port 80 tagged cpzoneid_2_rdr -> 192.168.2.1 port 8002

where igc1 is the portal interface, and "cpzoneid_2" is the portal zone ID, 192.168.2.1 is the portal IPv4.
A second portal instance will use, probably, port 8004 and another ID.

http portal mode is ok to "make it work".
Go to the https version, as most browsers will bark, showing warnings that will be errors in the near future, when not-TLS is used for any http traffic.
Also, the RFC1918 Portal IP won't show up anymore, the local pfSense portal host name is now used, because that's what certificates is all about.
Ones "https portal authentication" is set up, your done done with it installation. It will work well from then on.

There is a price tag, as you will need to rent a domain name. Annual fee : less then 5$ / year ?
Before you chose a registrar, make sure that it will work with "Lets encrypt", the pfSense package that will handle the automatic certificate renewal.

Advantage is : portal login goes over https, so there is no need anymore use any SSID security, the traffic is already encrypted. As soon as the user is logged in, all subsequent traffic is also using TLS : all mail, web and whatever uses TLS these days.
And as said above : portal users that want to add their own security : that's where VPN ISPs come in handy. : even you as the pfSense admin can 'see' their traffic anymore, you will have to trust your portal user ( ! ), which is actually a strange situation because portal users are actually 'untrusted' as they can do what they want with YOUR internet connection.

edit :

Purely optional :

If you have the NTP deamon running on pfSense, have it also listening on the portal interface.
Add this :

to the portal DHCP server (192.168.2.1 is my portal interface IP).
Add a rule like this :

to the portal firewall so portal users can use the pfSense NTP if they want to.