Help with CP on OPT1
-
I am not a firewall expert, but none the less, I have been tasked with adding a Captive Portal to the OPT1 interface of our PFS.
When I enable the CP, clients on OPT1 lose internet connection (expected, obviously) but the login page does not redirect (suspected DNS issue? but it works with CP off?) but more interestingly, I am unable to access the PFSense in a browser via it's IP address either!
I assumed this was some odd config issue so I have just set up a test box; Same behaviour.
- Installed fresh PFS 2.7.2
- Added the interfaces ix0 (WAN), ix1 (LAN), em0, (OPT1)
- Set IP Addresses, DHCP etc.
- Test internet on LAN, all good
- Add the firewall rules for OPT1 (as it defaults to block everything, for the sake of argument, I've added "source" OPT1 any any any etc)
- plug into OPT1, get an IP, test internet, all good!
- Enable CP on the OPT1 interface (no fancy settings, selected local database auth), boom, no more web gui (via the OPT1 IP address obv) and no CP login prompt.
What have I missed?
My observations:
I can ping OPT1, but put that IP into a browser, endless spinning.
If I ping the hostname for the PFSense, I get the IP of the LAN interface rather than OPT1. I can see this causing issues with the CP Redirect, but the fact I can't access the GUI via its IP is strange, right? also, I am not using the HTTPS CP, so it should redirect to the IP anyway?
I was under the impression CP denied access via the firewall, so in my test setup, I ran "pfctl -d" to disable the firewall, no change.
Disabling CP makes OPT1 spring back into life instantly, I can access the GUI and web once again.
Any help with this would be greatly appreciated!
-
@RobinWright said in Help with CP on OPT1:
When I enable the CP, clients on OPT1 lose internet connection (expected, obviously) but the login page does not redirect (suspected DNS issue? but it works with CP off?) but more interestingly, I am unable to access the PFSense in a browser via it's IP address either!
This is all very normal.
Normally, you admin your pfSense from your LAN, so when you activate the portal on the interface OPT1, nothing happens.
When you connect - physically, by wire, or using radio, also known as Wifi, then the magic starts to happen.
Your portal device should receive a DHCP lease from pfSense, over the OPT or portal interface.
Check it !! ( ! ) -
On a Microsoft Windows device : type "ipconfig /all". Other OSes : you'll know what to do.
The IP received should be in the network of the OPT = portal network.
The gateway received should be the IP of the OPT - portal interface.
The DNS received should be the IP of the OPT - portal interface ( !! ).@RobinWright said in Help with CP on OPT1:
Add the firewall rules for OPT1 (as it defaults to block everything, for the sake of argument, I've added "source" OPT1 any any any etc)
plug into OPT1, get an IP, test internet, all good!Ok that you've tested this before activating the portal.
These tests must pass.@RobinWright said in Help with CP on OPT1:
What have I missed?
I can't tell.
But I'll tell you how it works (the simplistic way) :
The "captive portal" isn't a pfSense thing. pfSense is just a firewall.
The captive portal works because : your device - supports it.
This means that when you use a Windows 95 PC, you might be trouble ^^
What happens is : as soon as the device got an DHCP lease, it (the OS ! not you as a user) will send out a http (not https !) request.
For example, an Apple OS based device will throw out :
http://captive.apple.com/hotspot-detect.htmlIf the device is not connected behind a portal, if will receive a page back with one word, 7 letters :
Success.Try for yourself ^^
if 'something else comes back, the device will presume a portal.
It will signal you by whatever means it has : opening a browser, a tray task message, whatever.The very same request will get repeated : (my example) http://captive.apple.com/hotspot-detect.html
and the Login portal shows up.
What happened :
"apple.com" will get resolved first.
So, for this to work, you have to pass TCP and UDP port 53 DNS traffic ( !! ) on your portal OPT firewall rule list. You have a pass all right now (UDP, ICMP and TCP, or "all", right ?)
Ok, it will get the IP of "apple.com", for me it is "17.253.109.202", and connects to that server.
The thing is : on pfSense, a non logged in devices will a) go no where and b) will have their port 80 TCP (a web request) redirected to 127.0.0.1 port 800x but you don't care to where it goes, you don't need to do this manually.Here it comes :
This part : "... redirected port 80 TCP to 127.0.0.1 port 800x..." is a firewall rule on pfSense - and that's all there is to make a portal work on the pfSense side ! (so what can go wrong ?
)But guess who is listing on this 800x TCP port ?
[24.03-RELEASE][root@pfSense.bhf.tld]/root: sockstat -4 | grep 'nginx' root nginx 15632 5 tcp4 *:8003 *:* root nginx 15389 5 tcp4 *:8003 *:* root nginx 15295 5 tcp4 *:8003 *:* root nginx 15270 5 tcp4 *:8003 *:* root nginx 15061 5 tcp4 *:8003 *:* root nginx 14986 5 tcp4 *:8003 *:* root nginx 14727 5 tcp4 *:8003 *:* root nginx 14494 5 tcp4 *:8002 *:* root nginx 14438 5 tcp4 *:8002 *:* root nginx 14208 5 tcp4 *:8002 *:* root nginx 13937 5 tcp4 *:8002 *:* root nginx 13720 5 tcp4 *:8002 *:* root nginx 13499 5 tcp4 *:8002 *:* root nginx 13318 5 tcp4 *:8002 *:* root nginx 69034 5 tcp4 *:443 *:* root nginx 69034 7 tcp4 *:80 *:* root nginx 68828 5 tcp4 *:443 *:* root nginx 68828 7 tcp4 *:80 *:* root nginx 68365 5 tcp4 *:443 *:* root nginx 68365 7 tcp4 *:80 *:*The 8003 and 8004 lines are all my captive portal web server, 8003 = (probably) http and 8004 is https.
And I lied : this isn't the simple explanation. This is all there is to know.
This Troubleshooting Captive Portal will learn you that you should 'break' DNS. The default Netgate resolver settings will do just fine. An important detail, amongst other : unbound should listen to your OPT1 - portal interface.
So this :
will deal with that.
Btw : you will discover that "http" portal access was great, in the past.
These days, browsers don't like 'http' anymore. So you'll say : ok, go mode https.
But now your browser will yell even more - pfSense, the portal web server will give your browser a certificate that your browser doesn't trust !! ( and while you reach that stage: think about : you've created a certificate - a CA actually, and made a certificate with this (your) CA. And now your browser tells you it doesn't trust a thing you made yourself ?! ?? ( ?? ).There are solution for this also
Anyway, I'm getting ahead of myself, if needed, we'll get back to this.
-
@Gertjan Good morning (sorry for the late reply, making the post on a Friday was foolish on my part)
Everything you have said has made sense; which leaves me more confused as to why this doesn't work.
With CP active on OPT1, I will receive an IP via DHCP as expected. Ignoring the redirection not occuring (I can see the device attempt to access the generate_204 URL or equiv, it just times out trying to resolve) It's bizarre to me that am unable to access the firewall itself and it's CP page http://IPADDRESS:8002/?zone=ZONENAME by directly typing it into the browser. *
The HTTPS portal uses the hostname, which resolves to the LAN interface IP on OPT1, which would be a problem, but it's fine, I can fallback to http on this particular portal and use the IP address if it worked...(I have some Google intigration on the live prod box that requires the browser session be 'secure' for the LAN)
At this point, I believe this may be an OS issue (as you say, it is the OS that is controlling this process) where some strange caching stuff is going on where I am switching networks, testing etc.
I will be setting up 2 VMs today, both hosting a single CP on their 'LAN' interface to see if the problem persists. If it doesn't, I may roll with that as a solution despite being inefficient.
*Thinking about this now, it may be possible that I could not access via the IP because Chrome just loves assuming https:// but I am fairly sure I specified http at the time. I will try my test environment again today.
-
@RobinWright said in Help with CP on OPT1:
I can see the device attempt to acces ..
I forgot to mention this one : Here : Status > System Logs > Settings
and check :
as I guess it might be useful to see errors.
Now go here : Status >System Logs > SystemGUI Service
and there you will see web browser request coming from devices connected to the portal : example :
192.168.2.201 - - [15/Jul/2024:10:57:41 +0200] "POST /index.php?zone=cpzone1 HTTP/2.0" 302 0 "https://portal.bhf.tld:8003/index.php?zone=cpzone1" "Mozilla/5.0 (Linux; Android 14; SM-A057G Build/UP1A.231005.007; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/126.0.6478.134 Mobile Safari/537.36"192.168.2.201 is the device's IP
192.168.2.1 is the captive portal pfSense IP
You saw the status code = 302 == a redirection == Ok.Side note : I use https login, so my captive portal web server uses a signed, valid certificate that says it's "portal.bhf.tld".
@RobinWright said in Help with CP on OPT1:
It's bizarre to me that am unable to access the firewall itself and it's CP page http://IPADDRESS:8002/?zone=ZONENAME by directly typing it into the browser. *
You've checked if the portal's web server is running ?
@RobinWright said in Help with CP on OPT1:
http://IPADDRESS:8002/?zone=ZONENAME
That's not the right one.
I check my portal accfess from the consolE 5ssh §° /
[24.03-RELEASE][root@pfSense.bhf.tld]/root: curl "http://192.168.2.1:8002/index.php?zone=cpzone1" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> <html lang="fr-FR"> <head> <title>Brit Hotel Fumel</title> <meta name="viewport" content="width=device-width, user-scalable=no" /> <link rel="stylesheet" href="captiveportal-2style.css" type="text/css" /> </head> <body> <div style="text-align:center; margin:0 auto;"> <form method="post" action="http://192.168.2.1:8002/index.php?zone=cpzone1"> <p>Bonjour, <br />Vous êtes sur le portail d'accueil "Internet" de</p> <p><a href="http://www.brit-hotel-fumel.fr/" class="linkExternal"><img src="captiveportal-nvxx-logo.png" class="centerImage" alt="Brit Hotel Fumel Logo" ></a></p> <p>Tout d'abord, nous vous conseillons de consulter notre Livret d'accueil.</p> <p>C'est ici <a href="https://www.brit-hotel-fumel.fr/wp-content/plugins/pdfjs-viewer-shortcode/pdfjs/web/viewer.php?file=https://www.brit-hotel-fumel.fr/wp-content/uploads/2024/02/ROOM-DIRECTORY-BH-FUMEL.pdf&attachment_id=1773&dButton=true&pButton=false&oButton=false&sButton=false#zoom=page-actual&pagemode=none&_wpnonce=f7f80c7bc4" class="linkExternal">Livret d'accueil</a> (Veuillez cliquer/taper sur le mot surligné).</p> <hr> <p>Souhaitez vous accéder l'Internet ?</p> <p>Veuillez saisir le numéro de votre chambre</p> <input name="auth_user" id="auth_user" type="text" size="12" maxlength="10" placeholder="Numéro de chambre"/> <p>Et le mot de passe que vous trouvez</p> <p> dans notre Livret d'accueil.</p> <input name="auth_pass" type="password" size="12" maxlength="10" placeholder="Mot de passe"/> <input name="redirurl" type="hidden" value="https://www.google.com/" /> <input name="zone" type="hidden" value="cpzone1" /> <p><input name='accept' type='submit' class='button' value='Accéder à l´Internet' /></p> </form> </div> </body> </html>There is my login page.
-
Merci pour votre réponse.
Sorry, my french is ...elementary at best.
@Gertjan said in Help with CP on OPT1:
I forgot to mention this one : Here : Status > System Logs > Settings
I will check in on this ^
@Gertjan said in Help with CP on OPT1:
You've checked if the portal's web server is running ?
I can access it via the LAN interface and the WAN (this FW is inside the network, just for testing purposes)
I have just gotten into the office. The test I have conducted this morning on the test box is to set up the same (effectively default) CP on both interfaces.
Still broken on OPT1. But then, at the console I reassign the interfaces, swapping the LAN and OPT1. The once dead OPT1, now LAN (ethernet) spings into life and vice versa for the old LAN, now OPT1 (fibre).
So I am still thinking I must have a firewall issue; These are the rules I set up.
-
@RobinWright said in Help with CP on OPT1:
Sorry, my french is ...elementary at best.
Mine also.
But the content of the portal html is not important.
Important is that it shows up.Firewall rules :
You don't need the lock out rule. When portal visitor try to acces the pfSEnse webGUI, or SSH, they might be getting locked out.
See that a a bonus. You don't want potential hacker on your networks.The third rule isn't needed.
The captive portal doesn't use IPv6 - it can't.So, rule 2 by itself is just fine. That is, if the portal network's name is "GUEST'.
@RobinWright said in Help with CP on OPT1:
now OPT1 (fibre).
You use local 'LAN' fibre connection ??
-
I can see in the log there is a 302 response, so I'd expect a redirect. I can also see the GET request for /index.php?zone=guest
10.254.0.10 is a Chromebook currently connected via OPT1. The browser will sit and wait, then timeout when trying to access PFS. See below for an example of attempting to view the GUI.
Interesingly, if I type in the IP for the GUI, or the CP Login page, there is no entry on the log.
The IP for OPT1 is definitely 10.254.0.1.
-
@Gertjan said in Help with CP on OPT1:
You use local 'LAN' fibre connection ??
Yes, 10Gb Fibre internet, so fibre into the main LAN switch.
-
Nice.
But do check and show : the DNS and gateway (see above, way earlier).
Just to be sure.This :
means that the captive portal web server received the request - and delivered (status = 200 = Ok) the request page /index.php&redire .... to the web browser = 10.254.0.10.And nothing shows up ?
-
@RobinWright said in Help with CP on OPT1:
Yes, 10Gb Fibre internet, so fibre into the main LAN switch.
Ah, ok. You mean your ISP connection is a 10 Gb fiber connection.
That connection doesn't get into a switch.
It goes into pfSense, the WAN interface, or in a device, your ISP modem/router/whatever, and this device's LAN is connected to the pfSense LAN - using a classic RJ45.
Right ?10 Gb fibre LAN is .... extremely rare, I never saw a SOHO local network using 10 Gb, fiber based ....
Do they even exist : 10 Gb fibre access points ?But (sorry
) you can't be that network crack as you are using ... Chrome 
-
Sorry, I assumed from the portal content that you were french!
@Gertjan said in Help with CP on OPT1:
And nothing shows up ?
Yeah, I was getting nothing.
I will make FW rule changes you suggested, I was just trying to replicate the automatically generated LAN rules.
I was typing this reply (below) but my MacBook just popped up with the portal randomly (I have a myriad of devices on this task at the moment)... I check my phone, also now loading the portal. Nothing on the chromebook still, so I renenewed it's IP Lease and now that is working..! Totally bizarre. What on earth happened? I was getting the same issue on prod, so I can hopefully find out what changed; but that seems unlikely.
@Gertjan said in Help with CP on OPT1:
But the content of the portal html is not important.
Important is that it shows up.Curl requests for both addresses return the same response. (on the PFS shell)
OPT1 address
LAN address
Edit: I failed to crop screenshots.
-
@RobinWright said in Help with CP on OPT1:
Sorry, I assumed from the portal content that you were french!
Noop, that's the language I use, because I live in France.
I'm dutch.@RobinWright said in Help with CP on OPT1:
Nothing on the chromebook still,
I don't trust these devices, as they do things like 'using their home DNS = 8.8.8.8' as we all know why and who build them.
Normally, this isn't an issue, but when you add a captive portal to the mix, everything has to play by the rules.@RobinWright said in Help with CP on OPT1:
Curl requests for both addresses return the same response. (on the PFS shell)
That's correct.
As said earlier : the portal web server listens to all (== all interfaces). The sockstat command told you.
It even listens on WAN ^^But who is going to ask on your LAN interface an index.php using port 8002 ?
Nobody.
Only on your GUEST interface this rquest, using port 80 using TCP, will get redirected to 10.254.0.1 port 8002.See here : this file /tmp/debug.rules and look for all the 'portal' firewall rules.
Looks like it's working now ?
-
@RobinWright
As pointed out by Gertjan the WAN connection is to the internet. Fiber is becoming common with the adoption of SFP+ in lieu of RJ45 ports. What is important is that the WAN/Internet connection go directly to the WAN interface on the system you have pfSense installed on.This is also true for LAN, it must connect to it's own interface, which is a different interface than the WAN, on the system you have pfSense installed on.
Now, for the OPT1 interface it too must have a separate or different RJ45/fiber connection to your device(s) you wish to capture. You indicated you plugged directly into OPT1 and could ping both LAN and I assume your OPT1 subnets, (i.e. 192.168.1.1 and 192.168.3.1 for example.) Each of those interfaces should have separate DHCP servers setup. As long as you plug directly into the OPT1 interface, you are getting your IP from the OPT1 DHCP server. That device should be able to ping itself and the gateway.
One possible concern is your mask for the LAN and OPT1, both should be /24, i.e. not overlap. They are separate networks after all.
Your configuration will require you plug your devices that use the captive portal (Normally a WiFi Access Point) into OPT1 either directly or through their own separate switch(s). It can NOT be plugged into the same network as LAN unless you have at least Level 2 switches and have setup VLans on it. If that is the case, you can ignore the next paragraph.
If using L2 for LAN and OPT1 with an L2 switch, you must setup a VLAN interface on the switch, then under Interfaces, Assignments, VLans. Next, add it as an interface under Interfaces, Interface Assignments. That interface will now show up as an option for Captive Portal, use it for the portal. Then go and setup DHCP on it. For example, if you choose VLan ID 10, use 192.168.10.1 as the IP for the interface DHCP. For the firewall setup a pass all rule. Make sure the Access Point enables the matching VLan ID on the Station ID you are connecting through.
-
@Gertjan said in Help with CP on OPT1:
Looks like it's working now ?
It seems so, just a mystery as to why? My test methodology is typically to change something, test and restore if it doesn't work.
Perhaps it was just the devices acting out of sorts. (We have a lot of Chromebooks come through here)
I will try and get the prod setup working...
