Different rate limits based on login ?
-
@EDaleH ,
Good to know about the bug report page. I'll have to see if I have a login there and report/ask for the feature.
I am using 24.11-RELEASE and have backups of my files. I suspected as well that IO may have to re-apply my patches on later versions.
In my case, time constraints is not really a concern. My multi login tier is my slow tier and only uses a single login and never expires.
If a client wants to use faster tier, then taht is voucher based and only the last logged in device can use it. Also these vouchers are good for 7 days.Background: My wife and I bought a campground last year. It uses a 3rd party service to run a portal and the wifi towers. It is costly and the system is dated/sucks. I am in the process of replacing all towers. We don't charge clients for internet, but still need to regulate usage, so that we have enough bandwidth to go around. This is where my so called free tier comes in. Anyone can use the Free slow Tier. 2mbs down. And each campsite that stays with us gets one voucher for one device at 6mbs, free of charge. This will let them watch netflix and such. I never expect too many devices at once to overload the bandwidth, but I will use shaping to always leave a bit for office vlan.
Anyhow, thanks again for responding to my initial post with suggestions. Was hoping I wouldn't have to do custom code, but I guess that was not a choice.
-
@Swicago said in Different rate limits based on login ?:
My wife and I bought a campground last year.
Interesting twist, I am retired and spent much of the last 2 decades running around in a Motor Home (10 yrs full time). We ended up helping sites setup their WiFi, often with pfSense. Our summer home stop was at an RV park (~120 sites) that I still take care of after about 15 years (all on pfSense) as a hobby. About 3 years ago, they brought in Fiber at great expense and we buried fiber in the Park out to all of 20 or so APs. The park's throughput last summer went from a monthly low of 7 TB to a high of 20 TB. Latency is 2 ms from the ISP and 4-6 ms to the end user. The impact on the park has been substantial, fully booked a couple of years in advance and grandkids visit because the gaming is better than at home. Most of the satellite dishes are gone because everyone is streaming instead. There are a lot of clients that come so they can work from their MH/Cottage all summer. The ISP feed is an expensive business account (conditional for bringing in the fiber about 10 Km) and revenue is now covering the entire cost of the internet itself. The wifi infrastructure, much like power/water/sewer upgrades is a capital expense that will have to be written off over time though. It is currently running on an XG-1541 max. I modified the captive portal code about 3 years ago and have ported it through each version up until the current version. Last year it had 0 down time outside of the seasonal APs loosing power during a couple of power outages. Transient stayed up because they are on a UPS. There are no office sales of wifi, no support requests and it is all automated or rented for the season. Single login at the beginning of the season/visit and automated cleanup when time/data expire. Have you implemented RFC8910 (DHCP 114) for the smartphones? Be careful with Kea as it likes to change the IPs frequently and is very different from ISA DHCP.
-
@EDaleH ,
That is the next thing I am trying to get working. RFC8910
I have the /usr/local/captiveportal/rfc8910.php pulled from mega thread https://forum.netgate.com/topic/188402/captive-portal-not-working-on-ios-devices-only-dhcp-114
I uploaded my CA cert into pfSense.
I added the 114 DHCP entry to my DHCP of my portal VLAN "https://MYDOMAIN:8003/rfc8910.php?zone=MYZONE"
I enabled HTTPS option on the portal and select my cert and entered my ddomain.I can reach the DOMAIN from all my hosts, because I added a DNS Resolver entry and point the domain to my portal ip address. This way I was able to verify that my ssl cert was good.
However, when I try to connect to the portal with Andriod it does not auto load the sign in, instead I have to click the SSID and load the sign in page, but it just times out saying it cannot reach webpage at https://MYDOMAIN:8003/index.php?zone=myzone&redirurl=http%3A%2F%2Fwww.google.com%2Fgen_204
What else am I missing?
Is there a way to talk to you directly or in a faster channel, that is if you have time. I feel I am close. I am def not a network guy, but learn really fast. -
@Swicago said in Different rate limits based on login ?:
What else am I missing?
Start with a simple windows system that doesn't need DHCP 114 to function and get the captive portal page loading in a browser. If it doesn't autoload, try http://neverssl.com to trigger the "capture".
Only chase DHCP 114 after being certain the rest is working.
The most common mistake on the certificate is to be using the evaluation one which won't work for testing, you need to be on the production cert (ACME/let's encrypt).
At first glance you are on the right path for RFC8910 but make sure it is in the same directory as index.php or provide the full path to where it really is. The directory you list is the correct one.
As far as contacting me, I have no problem helping if I can, but will not release personal contact info on the forum so you would have to provide me with a place to drop a message anonymously where you could pick it up anonymously as well. I am not sure what that is. If you have a contact at Netgate that was prepared to be an intermediary, that might work. I discourage you from publishing any contact info here as well.
I will check here in the morning and expand on what I can. Right now I have to run.
-
@EDaleH ,
Finally got it to work. I made a new portal with no login required, just accept on portal. Tested on windows as suggested and it was peachy with it.
Then did everything I did before to support mobiles and suddenly it worked too.
Then I added all my speed/voucher rules back onto the new portal and all seems to work, albeit after signing in it is a little slow to get the generate 204 page for android(10 seconds), but once connected it is fast. This was the case even with full bandwidth allowed(no restrictions), so not sure what that is about. Any suggestions as to what I still need to check.
I'll figure out a way to exchange info anonymously, if you are still ok with it.Thanks a lot for your help.
-
The DHCP 114 string is sent to the device when it gets an address along with a Captive=True. That tells any device that is checking option 114 that it should load the DHCP 114 supplied URL before going anywhere on the internet. That means Captive Portal does not even know they are there yet. Most devices require that URL to be a secure one, iOS insists on it. iOS won't work at all with an http:// link whereas Windows will for example. The version of iOS and Android also change the way they handle DHCP 114 and only the most recent versions are handling it well. in iOS for example from ver 17 on, you will find a "Load Captive Portal Page" when you press the circled i (properties page). That should load the logout page from the Captive Portal through the loading of index.php. Logout, because the DHCP 114 string now would send a Captive=False because that page is the Vendor URL page from DHCP 114 through RFC8910.php, which is the same URL as the True page unless you change it in RFC8910.php. Index.php in that case detects you are already authorized and sends the logout page instead.
@Swicago said in Different rate limits based on login ?:
cannot reach webpage at https://MYDOMAIN:8003/index.php?zone=myzone&redirurl=http%3A%2F%2Fwww.google.com%2Fgen_204
Just a guess but if you have a redirect page in the Captive Portal that is timing out, it could cause the delay. Remove all the redirects until you are happy with how it works.
@Swicago said in Different rate limits based on login ?:
a little slow to get the generate 204 page for android(10 seconds),
You will notice that the earlier string has the redirurl added to the DHCP 114 supplied? login url. It doesn't belong there. Android should only check that page after you have logged in. I expect that the 204 page is not available until after you complete the login and your delay may be an attempt to load it twice, once by the portal and once by the device after that first attempt times out. If android is sending it as an http:// string as shown, it is that "insecure" url that is triggering the Captive Portal instead of directly loading the page without having the Portal "Capture" you and send the URL itself to the device browser. iOS can't do any http:// communications and will just hang in the temp browser if this happens. While debugging, simply get rid of any redirect urls, leave them blank.
I know this is confusing but the goal under DHCP 114 is to never be "captured", instead, to load the login page directly from the Captive Portal, whereas if you try to go directly to the internet immediately, the Captive Portal should "capture" you and redirect you to the login page. Unfortunately, because of SSL encryption, the Captive Portal can't tell if you are trying to get to the internet if the page is an "https://" secure page, it can only "Capture" you if the page request is not encrypted, i.e. an "http://" page. When Apple created and implemented DHCP 114 about 4 years ago, it basically broke the logic that the pfSense Captive Portal uses to Capture a device, thus it is critical to get DHCP 114 working so the device itself can take care of getting authorized through the Captive Portal without ever being "captured". Android is still a bit of a hybrid as you can see it appears to be using an http:// site to verify connectivity. That attempt could trigger the "Capture" and send the login URL from the Captive Portal if DHCP 114 or your SSL certificate aren't working properly. It is hard to tell, but the addition of the redirurl in the first quote is a hint that the DHCP 114 string is not being respected, likely due to SSL issues? Your android should be a very recent version to aid debugging, same for iOS.
Wrt your request to communicate directly, my "anonymous" suggestion was not to replace the forum, it was to enable the exchange of direct contact information. I am a full supporter of the value of the forum to others researching issues or as a learning tool and this exchange may be helping someone else now or in the future.
-
@EDaleH
When I finally got it to work, the portal loaded instantly using Andriod. The delay is after login.
Since login is done via https, does dhcp resolver also need tls/ssl enabled?As for vital info, I am all for it staying on the forum, but the back and forth on little things makes the thread huge and convoluted. Once I am done, I plan to step by step redo what I did, just like yesterday and make sure I have things noted right in order to be successful, then I would post the steps I took, so one post has the right steps needed and not a huge thread that will confuse future readers.
Anyhow, as said I feel I am close. To recap.
Created a new portal with no limits and no autgh, just accept.
Tested on windows Windows with no dhcp114, ssl portal worked as expected. Cert valid and all.
Added dhcp 114 and tested on android. It instantly connected to portal, where as before it just hung. So dhcp 114 is working. After I accept the portal auth, that is where android then tests the internet with the generate 204 page. It takes about 10seconds for it to find it and then all is good. No sure why there is a delay, I assume I am still missing something or something is still misconfigured. -
@Swicago : extra info, about this :
@EDaleH said in Different rate limits based on login ?:
The DHCP 114 string is sent
The pfSense DHCP server sends it .... because a device was asking for it.
Not all devices do. Who does ? Who doesn't ? Easy to find out for yourself.Packet capture with these options :
=> Select the interface, select full details, select UDP as a protocol, and port "67 67" as these are the ones used by the DHCP client and server.
and fire up the packet capturing.
When you connect a "114" capable device to your portal, you will see this :
The image shows the DHCP client request, and the DHCP (pfSense) answering the request.
so the device I used is "114" compatible (an iPhone).
Microsoft based devices are also compatible (not your XP based laptop of course).
Devices with the "others OS" ? I don't know. you tell me. -
@Swicago said in Different rate limits based on login ?:
Since login is done via https, does dhcp resolver also need tls/ssl enabled?
The goal of local resolution through the resolver is to have a local IP available that is associated with the SSL URL for the captive portal login page. Once internet connectivity is established, it is no longer necessary so make sure your Domain DNS points to a local address for the Captive Portal login page. i.e. putting it into the resolver is not enough, your DNS has to be correct as well. Typically they would point to 192.168.1.1 if you are using the default pfSense setup.
in iOS, there is a delay while the "No Internet" indicator is on after logging in, ,,, but if you try, the internet is already there, iOS is just sorting it out so to speak. Are you sure you don't have connectivity for those 10 seconds?
-
@Swicago said in Different rate limits based on login ?:
but it just times out saying it cannot reach webpage at https://MYDOMAIN:8003/index.php?zone=myzone&redirurl=http%3A%2F%2Fwww.google.com%2Fgen_204
Your device, give it an static IP setup, with the correct IP, network, gateway and DNS (the last two should be the portal interface of pfSense).
No DHCP so no option 114, so the device doesn't know about the portal login page etc.
The old portal detection system still works.Now, you must be able to go to "https://MYDOMAIN:8003/index.php?zone=myzone" manually, it should show you the portal login page right away.
There could be a delay, and I'll invent a possible reason right now :
If your portal network supports both IPv4 and IPv6, and knwoing that your device will always prefers IPv6, it (the browser) will resolve "MYDOMAIN" as always, and if a IPv6 comes back, it will use that to connect to the web (portal) server.
Or, the pfSense captive is IPv4 only ...
So, there will be a delay before your device decides to fall back to the ancient IPv4 that it also received when doing the resolving of "MYDOMAIN".Permanent solution :
Your captive portal interface should have a IPv4 only.
and/or
Your MYDOMAIN should only resolve to an IPv4.Btw : I'm just brainstorming here.
You can give your device a static DHCP setup on the portal, so it will always get the same IP.
Knowing your IPv4, you can packet capture the IPv4 of your device. Ask for all the details.
So you can see what it is doing, what request get what answer, what requests don't etc. So you can deduct why it is waiting. -
@Swicago said in Different rate limits based on login ?:
does dhcp resolver also need tls/ssl enabled?
the DNS Resolver does need SSL/TLS enabled and pointed at your certificate
-
@EDaleH said in Different rate limits based on login ?:
the DNS Resolver does need SSL/TLS enabled and pointed at your certificate
Never had that one activated (enabled) on my pfSense. Not for my LANs not for my portal.
Also called DOT, right ?
DOT would be fine, I guess, for super trusted devices - and you have to set up manually the DNS host address and the DNS pfSense host LAN IP on the device first.
Afaik, DHCP is not going to do that.
The IP will be used to connect to the the DOT capable DNS server (in this case : our pfSense resolver) and a certificate exchange will tell the DNS client that de cert mentions the pfSense DNS host name, as it is present in the cert. If this test works out well, the DNS client will trusts the DNS server, and a DNS request can take place.Using way less words : DOT doesn't belong on the captive portal (my opinion, of course).
DOT on a LAN already asks for a manual ( !! ) setup on every device. Nobody is going to do that on a captive portal network.Better yet, from what I make of it,, the 'pf' initial portal firewall doesn't even allow "TCP 853" access.
(see /tmp/rules.debug and look for all the portal firewall rules )Port 853 proto TCP could be reached on pfSense if you add the IP host on the allowed hosts list, but that would expose all the pfSense ports on the captive portal .... Not good for a non trusted network.
Golden rule : captive portal users should use their device with standard, out of the box "network" settings.
For those who do not want that their DNS traffic going over UDP, port 53, over the wire or (yes, I know) open Wifi, then well ...... do not use a captive portal.
Or, next best solution : connect anyway. And as soon as you are connected, fire up your favorite VPN, so everything from this point will be scrambled, DNS included. -
@Gertjan said in Different rate limits based on login ?:
Using way less words : DOT doesn't belong on the captive portal (my opinion, of course).
Well, I had to google that to try to fully understand your reply. I have a simplistic view. We are asking for secure communications between the device and pfSense and iOS for one seems to demand it. When the browser (temporary or other browser) asks for a page that uses SSL security, the only way it gets the certificate data is if it is stored on the system already, available through internet access or locally supported. My understanding suggests it is a good idea to ensure the device can resolve to an address and reach the Captive Portal web page without failing to achieve that or be monitored/messed with, by a local unscrupulous client hanging around to mess things up. I turned that on 3 or 4 years ago and everything has worked extremely well. I am not sufficiently familiar with it to argue one side or the other. As I recollect, without it I was getting a "man-in-the-middle" warning.
This google search (DNS DOT) result seems to make sense:
"DoT works by sending DNS requests over an encrypted TLS tunnel, adding a layer of security over an existing TLS connection. The data in the request is then encrypted with a unique key unique to the communication session. The DNS request and response are then sent as data packets encrypted and integrity-protected by the TLS protocol. This adds an extra layer of protection, allowing only the intended devices involved in a communication session to access the data. By doing so, DoT helps protect user data and prevents unauthorized third-party access, which can be especially useful when users use shared networks, such as public Wi-Fi.... cloudns.net "
-
I enabled SSL/TLS on DNS resolver and selected my CERT. That seemed to slow down the initial sign in a bit.
Here is what my packet dump for the DHCP.09:59:29.226604 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 332: (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 318) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from xx:xx:xx:xx:xx:xx, length 290, xid 0x89ea128, Flags [none] (0x0000) Client-Ethernet-Address xx:xx:xx:xx:xx:xx Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message (53), length 1: Discover Client-ID (61), length 7: ether xx:xx:xx:xx:xx:xx MSZ (57), length 2: 1500 Vendor-Class (60), length 15: "android-dhcp-14" Parameter-Request (55), length 12: Subnet-Mask (1), Default-Gateway (3), Domain-Name-Server (6), Domain-Name (15) MTU (26), BR (28), Lease-Time (51), RN (58) RB (59), Vendor-Option (43), URL (114), Unknown (108) SLP-NA (80), length 0"" 09:59:29.226767 xx:xx:xx:xx:xx:xx > xx:xx:xx:xx:xx:xx, ethertype IPv4 (0x0800), length 403: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 389) 192.168.0.1.67 > 192.168.0.3.68: [udp sum ok] BOOTP/DHCP, Reply, length 361, xid 0x89ea128, Flags [none] (0x0000) Your-IP 192.168.0.3 Client-Ethernet-Address xx:xx:xx:xx:xx:xx Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message (53), length 1: Offer Server-ID (54), length 4: 192.168.0.1 Lease-Time (51), length 4: 555068 Subnet-Mask (1), length 4: 255.255.255.0 Default-Gateway (3), length 4: 192.168.0.1 Domain-Name-Server (6), length 4: 192.168.0.1 Domain-Name (15), length 9: "home.arpa" URL (114), length 74: "https://MYDOMAIN.tld:8005/rfc8910.php?zone=MYZONE" 09:59:29.242187 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 328) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from xx:xx:xx:xx:xx:xx , length 300, xid 0x89ea128, Flags [none] (0x0000) Client-Ethernet-Address xx:xx:xx:xx:xx:xx Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message (53), length 1: Request Client-ID (61), length 7: ether xx:xx:xx:xx:xx:xx Requested-IP (50), length 4: 192.168.0.3 Server-ID (54), length 4: 192.168.0.1 MSZ (57), length 2: 1500 Vendor-Class (60), length 15: "android-dhcp-14" Parameter-Request (55), length 12: Subnet-Mask (1), Default-Gateway (3), Domain-Name-Server (6), Domain-Name (15) MTU (26), BR (28), Lease-Time (51), RN (58) RB (59), Vendor-Option (43), URL (114), Unknown (108) 09:59:29.242282 xx:xx:xx:xx:xx:xx > xx:xx:xx:xx:xx:xx, ethertype IPv4 (0x0800), length 403: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 389) 192.168.0.1.67 > 192.168.0.3.68: [udp sum ok] BOOTP/DHCP, Reply, length 361, xid 0x89ea128, Flags [none] (0x0000) Your-IP 192.168.0.3 Client-Ethernet-Address xx:xx:xx:xx:xx:xx Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message (53), length 1: ACK Server-ID (54), length 4: 192.168.0.1 Lease-Time (51), length 4: 555068 Subnet-Mask (1), length 4: 255.255.255.0 Default-Gateway (3), length 4: 192.168.0.1 Domain-Name-Server (6), length 4: 192.168.0.1 Domain-Name (15), length 9: "home.arpa" URL (114), length 74: "https://MYDOMAIN.tld:8005/rfc8910.php?zone=MYZONE"I removed MACs and actual domain name. But from the looks of it, it seems to be getting the 114
As mentioned, the sigin page does show, I accept and then the devices waits for that generate_204 page for a bit. It does not connect instantly, like it did w/o dhcp 114v and SSL/TLS portal.
-
Arrrrrrrrrrr Stupid mistake. my dhcp 114 entry still had 8005 instead of 8003 in it. I created a second barebones portal yesterday, to make sure it was working right on widnows 11(latest).
I forgot to change it back to 8003.Now the only problem I have manual log out page.
I would have thought I could access it with
https://MYDOMAIN.tld:8003/logout.php
But I get nginx 404 not found error.
Direct port IP
https://192.168.0.1:8003/logout.php
also gives nginx 404 not found error.
It is only when I use the LAN IP (not VLAN IP) of the https://192.168.200.1:8003/logout.php does the page show.
Funny thing is, after portal login, I get the logout page for a short bit, before andrioid closes it. But I seem to not be able to reach the logout page after being fully connected. Suggestions? -
@Swicago said in Different rate limits based on login ?:
. Suggestions?
That one I can help with. You are getting the default logout page. Go to the captive portal and download that page. Then save it in the /usr/local/captiveportal/logout.php directory and now you have both control over it and the ability to load it directly.
-
There does not appear to be a download button for default logout page.
I can download error page and my login page, but no logout page -
@Swicago said in Different rate limits based on login ?:
https://MYDOMAIN.tld:8003/logout.php
But I get nginx 404 not found error.
Direct port IP
https://192.168.0.1:8003/logout.php
also gives nginx 404 not found error.Did you create / upload a logout.php file ?
@Swicago said in Different rate limits based on login ?:
It is only when I use the LAN IP (not VLAN IP) of the https://192.168.200.1:8003/logout.php does the page show.
Your "MYDOMAIN" resolves to 192.168.200.1, right ?
Port 8003 is the captive portal's port, right ?@Swicago said in Different rate limits based on login ?:
Funny thing is, after portal login, I get the logout page for a short bit, before andrioid closes it.
That's probably this one :
That's another example of an option that doesn't exists anymore, as it doesn't work anymore.
You know why .... (so why are you surprised it doesn't work ?? ).
I'll give you a hint : most, if not every browser these days, will not allow popup windows anymore. And I bet you won't find many browser with it activated, as it was "as nice try, but everybody hated them".So, shut down that option, and forget that it exists.
But there is good news also.
Remember the future ? The "Option 114" functionality ? It has you covered.
I can go straight to the Portal disconnect page, and disconnect my session, with the tap of a finger (ok, two taps).When I go to my current Wifi connection (my portal connection) I have to tap in the blue circled I, and then I see :
That I am connected to a 'portal'
And when I click on the (I translate) blue text "Open the page of the portal" I will see right away :
where I can disconnect the session.
This page is the same as the login page ! Because an open session exist, instead of the login page, this page is shown. Brilliant, right ? No need to learn or make another page. the device already knows about it.Me ,as an pfsens portal admin, could even put on this page the time I was connected, the number of bytes that I consumed, etc.
The thing is, this functionality is to new. This is bleeding edge.
Most phone OSes don't even know that this portal 'status' (logout) is avaible (look to the east).
US Phone (Apple) do this for a while know, and it works great.
But ordinarily people (like me) don't know this functionality yet - I guess I'm the only one in France.All this said, you can use plan B :
If you really have to logout users, do it for them ?!
Here :
which means : after 5 minutes of no activity on the session( the MAC/IP) then pfSense will disconnect the portal user for you.
This will work great : just charge 10 $ per kilo byte for your portal.
Now you, and your portal users don't have to worry, they will will disable their Wifi on their device as soon as they are done. This means : no more traffic. This means they will be disconnected automatically.Ok, 5 minutes is way to small of course
Mine is set to 120 minutes (of non activity).
But I don't care, and don't ask money for my connection, and I've enough bandwidth to offer.
I use the portal KIS rule : If you can connect to it, that's great. If you can't, that's fine also.
I've tried about every new device that exists out there, and as soon as I remove the shrink wrap, the device can connect to my portal just fine. Slide on the Wifi, select my portal, and bam, if offers a login page. Me,a s the admin, I know all the passwords ^^ If the device can't login, a discussion with the owner must take place, as people tend to "do things" with their phone / device. That's fine for me.Wait for it : Plan C ! Give your users an iPhone or iPad
(I'm joking again, and a lot, this evening) -
Yes, the dhcp 114 is giving my device a notification where I can see the connection and log out. But I just wanted a backup solution in case this didn't work right on all devices, such as TVs.
Turns out the URL for logout is the same as the login.
When I enter https://MYDOMAIN.tld:8003/index.php?zone=MYZONE it loads the logout page. SO that solves that issue as well.Now it appears I can support new and old devices.
Thank you both for all your help and insights. -
Found a bug in
One line 1742 you will find function "portal_ip_from_client_ip"
If someone calls https://MYDOMAIN.tld:8003/index.php and omit "zone=MyZone", this throws an Exception in PHP on line 1746 due to global variable $cpzone being "" empty string.
I added the following to /etc/inc/captiveportal.inc
function portal_ip_from_client_ip($cliip) { global $cpzone; /* Fixes bug when portl URL is called without zone */ if(empty($cpzone)) { return false; }The function returns false at the end, if it cannot find what zone interface you belong too by default. So all this does is the same, but fixes that bug that will show a message in pFsense crash reports.
