How to use the pfsense name instead of the IP address in http?
-
Because :
@Gertjan said in How to use the pfsense name instead of the IP address in http?:
is hard coded
so editing the nginx config is useless, as pfSense re creates that config file every time it starts nginx.
When you look at your own file at /etc/inc/system.inc, you'll find it around line 1331 (the github version is ahead - more recent).
Instead of
$cp_hostcheck .= "\t\tif (\$http_host ~* $cpint_ip) {\n";you change that to
$cp_hostcheck .= "\t\tif (\$http_host ~* pf.home.arpa) {\n"; -
G Gertjan referenced this topic on
-
@Gertjan
After modifying the /etc/inc/system.inc file, the nginx-pass-CaptivePortal.conf file can correctly display the domain pf.home.arpa, and it still displays after restarting the service, indicating that the modification is successful. However, the login page has not changed and still appears in the form of an IP address, http://192.168.0.1:8002/index.php?zone=pass&redirurl=http%3A%2F%2Fqq.com%2F. -
I just tested the http login .... and yes, I saw also "192.168.2.1".
So more work needs to be done.
The story continues here /etc/inc/captiveportal.inc locate function portal_reply_page() around line 1811.Four lines lower, you'll see
$ourhostname = portal_hostname_from_client_ip($clientip);That function return the IP if http was chosen, the domain name if otherwise (https).
A solution might be : locate function portal_hostname_from_client_ip($cliip) :
After $ifip = portal_ip_from_client_ip($cliip);
Add on a new line :
$ifip = false;Like this :
but take note : this is messy.
Its always easier to do what the entire planet does : use https, as it is the future
-
And keep in mind that after each update you need to make this changes again.
So I do with my changes for printing QR codes for voucher access.Regards
-
@Gertjan
The IP address has been successfully transformed into a domain name, but it also caused a deadlock. How can this be resolvedhttp://pfsense.home.arpa:8002/index.php?zone=pass&redirurl=http%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fqq.com
-
-
@goldsoft said in How to use the pfsense name instead of the IP address in http?:
How can this be resolved
By undoing what you did, so you'll get the stable situation back.
Its (not) clear to me that more has to be changed.
Sorry, can't do more here. -
This post is deleted! -
@Gertjan Thank you very much for your guidance.
-
@goldsoft said in How to use the pfsense name instead of the IP address in http?:
@Gertjan
The IP address has been successfully transformed into a domain name, but it also caused a deadlock. How can this be resolvedhttp://pfsense.home.arpa:8002/index.php?zone=pass&redirurl=http%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fpfsense.home.arpa%3A8002%2Fhttp%3A%2F%2Fqq.com
I hope someone can help me solve this problem because I really need this functionality.
-
G goldsoft referenced this topic on
-
Try this :
Force redirect to preset URL :
I know, not a real solution, but it would break the recursive redirection.
-
@Gertjan The user has been authenticated and can access the internet. Further redirection would be meaningless
-
I get it.
Consider this : when you visit the captive portal's IP or host name manually, the request will get handled by the nginx (the web server handling the captive pirtal login page) : the used host name will be stored in the redirect parameter.
Or, the url (host name) is the host name of the web server itself.
After a valid login, you will get redirected to this 'redirected url'.
Which was ... the same page.
And from now on, this goes in circles : you saw what happens.Simple solution : never enter or use the captive portal's host name, as the portal will auto redirect to this url anyway.
To break this redirect loop, I proposed the 'https://www.whatver.tld' solution.
-
@goldsoft To change the URL, you can follow these steps:
Access your router settings. Look for the configuration related to the URL or redirection. Replace "http://192.168.1.1" with "http://pfsense" in the configuration. Save the changes.This should update the URL as you want. If you need more detailed instructions, please specify your router model for further assistance. Also, consider using the essay writing service at for academic help.
-
@johnwilliams1 Thanks for info!
-
I've managed to get CP working with a custom dns name, a valid LE certificate and running on the native http(s) ports 80/443.
First make sure you have registered a domain name for use in CP (eg login-guests.mydomain.com)
Setup:
- Captive portal on GuestNetwork - 192.168.10.1)
- Configure Dns resolver. Resolve login-guests.mydomain.com to 192.168.10.1
- configure domain name in CP config (SSL domain name)
- Configure ACME for trusted SSL cert on CP login page. Bind this certificate in the CP configuration pages.
Run CP on native http/https ports:
- Create your CP config in the GUI using the default ports (>8000).
- Change the pfsense config.xml and add the following two lines under the captiveportal element. Save the file and reboot the router.
<captiveportal> <guest_network> ... <listenporthttps>443</listenporthttps> <listenporthttp>80</listenporthttp>- Edit the captiveportal.inc file, go to the function 'captiveportal_init_webgui_zone' and comment or remove the 2 calls to system_generate_nginx_config(). This will disable the re-creation of the nginx config files for CP!
- Explicitly add interface IP to nginx file. Under /var/etc edit the file nginx-[name]-CaptivePortal-SSL.conf. Add the interface IP in the 'listen' command. (eg: listen 192.168.10.1:443; ). I've disabled the IPv6 ([::]:443) listener.
- Start the CP service.
This seems to work well. Users are redirected to the domain on port 443 (https).
There is one thing to keep in mind: This configuration may be lost when updating/upgrading pfsense! -
@VinzzB said in How to use the pfsense name instead of the IP address in http?:
Edit the captiveportal.inc file, go to the function 'captiveportal_init_webgui_zone' and comment or remove the 2 calls to system_generate_nginx_config(). This will disable the re-creation of the nginx config files for CP!
Not regenerating the nginx config will have side effects, like not putting the new certificates in place when they are are renewed.
I'm using the captive portal for more then a decade now, and never had to do all this.
My setup :
I'm using the LAN for my own 'private' network, this is my trusted network, and a second LAN (OPT) interface for the non trusted users, the captive portal network, on 192.168.2.1/24.
My pfSense host name is called pfsense. The domain is my-domiain.tld
The portal interface host name is defined as portal.my-domiain.tld
This domain, my-domain.tld, is renewed by the acme pfSense package every 60 days.My captive portal web server has two (multiple) instances, one for http (port 8002) and one for https (port 8003) : (the port 80/443 is the GUI instance )
[24.11-RELEASE][root@pfSense.domain.tld]/root: sockstat -4 | grep 'nginx' root nginx 40295 5 tcp4 *:8003 *:* root nginx 40257 5 tcp4 *:8003 *:* root nginx 38709 5 tcp4 *:8002 *:* root nginx 38563 5 tcp4 *:8002 *:* root nginx 36734 5 tcp4 *:443 *:* root nginx 36734 8 tcp4 *:80 *:* root nginx 36532 5 tcp4 *:443 *:* root nginx 36532 8 tcp4 *:80 *:*Keep in mind that current ( 2024 ) browsers dislike port 80 (http) usage. It a protocol from the past. They will emit warnings. It's all https these day.
The fact that port 8002 or port 8003 is used isn't an issue. These days, every device is portal aware and will get redirected to the correct port. Portal users will never have to enter the captive portal login URL to get and use the login page. If they have to do this, your portal setup is 'broken'.
So, afaik, the captive portal works out of the box, as advertised.
No need to change anything outside of the portal GUI settings. -
@Gertjan said in How to use the pfsense name instead of the IP address in http?:
The fact that port 8002 or port 8003 is used isn't an issue. These days, every device is portal aware and will get redirected to the correct port.
The correct port does matter when dealing with guest users. We don't control their local Firewall. Some guests use the local firewall to block or inspect outgoing http/https traffic on other ports. These users don't always have privileges to change firewall rules (company devices). So the best way to avoid this problem is to serve the portal on the native http(s) ports.
Guest users will automatically redirect to the portal and/or will be notified when extra steps are needed to access the internet. My setup currently works perfectly, including SSL. The SSL certificate renewal on the binding could be an issue tough. I'll keep that in mind and will test this!
Port 80/443 is still used for the pfsense GUI (which is available from the private lan). However, my CP GUI process is only listening on the Guest interface. Which is (imho) better. One disadvantage of this approach: when the CP process stops, the router will serve the pfsense GUI again on that IP / domain.
[2.7.2-RELEASE][admin@router...]/root: sockstat -4 | grep 'nginx' root nginx 21127 5 tcp4 192.168.2.1:443 *:* root nginx 20892 5 tcp4 192.168.2.1:443 *:* root nginx 20654 5 tcp4 192.168.2.1:443 *:* root nginx 20518 5 tcp4 192.168.2.1:443 *:* root nginx 20389 5 tcp4 192.168.2.1:443 *:* root nginx 20050 5 tcp4 192.168.2.1:443 *:* root nginx 19875 5 tcp4 192.168.2.1:443 *:* root nginx 19624 5 tcp4 192.168.2.1:80 *:* root nginx 19609 5 tcp4 192.168.2.1:80 *:* root nginx 19316 5 tcp4 192.168.2.1:80 *:* root nginx 19021 5 tcp4 192.168.2.1:80 *:* root nginx 18766 5 tcp4 192.168.2.1:80 *:* root nginx 18693 5 tcp4 192.168.2.1:80 *:* root nginx 18448 5 tcp4 192.168.2.1:80 *:* root nginx 88476 5 tcp4 *:443 *:* root nginx 88476 7 tcp4 *:80 *:* root nginx 88409 5 tcp4 *:443 *:* root nginx 88409 7 tcp4 *:80 *:* root nginx 88103 5 tcp4 *:443 *:* root nginx 88103 7 tcp4 *:80 *:* -
@VinzzB said in How to use the pfsense name instead of the IP address in http?:
The correct port does matter when dealing with guest users. We don't control their local Firewall.
Guest users that want to connect to 'some network' to get an Internet access so they can keep in contact ... that's why most of us offer a captive portal. Not for the money, just as a service, and the resources are avaible
Limiting to destination ports that they have decided, like 80, 443, 25, 110,143, 995 etc ...
Well ok, not an issue for me, and it will their problem. Its fine that they block their device's incoming connections, I get that. But when they also start to limiting to port X and port Y, but not port Z, that has nothing to do with security, that's just an overdoses of Toctic.
I saw them : they couldn't even connect to my network.
But they wanted to connected as facebook had to be updated, and their data usage of their carrier was 'empty' (dono what they are doing, but their 100 monthly Gbytes isn't enough these days) so they needed my portal. But they couldn't use it.
Took me a moment, and then I found it : their own paid "firewall" permitted only their own home network and refuses all the others.
Great. They are safe, that's for sure.
And no "Internet" except @home.
ROFL.@VinzzB said in How to use the pfsense name instead of the IP address in http?:
My setup currently works perfectly, including SSL. The SSL certificate renewal on the binding could be an issue tough. I'll keep that in mind and will test this!
Cant' be an issue.
When visiting a site, any site, it will be a https site. As there are no more http sites left to visit. Browser will even warn if a site is http only.
So, the captive portal, as any other TLS (https) "web site", uses a 'valid' certificate. With valid I mean : a cert that is recognized and accepted by any web browser.
Up to you as the admin to make sure that : renewal happens every 90 days. Letsencrypt says : renew every 60 days, which gives you 30 days to debug the situation if auto renewal didn't happen.During your daily (or weekly, or if time is an issue, monthly) log-file-checkup, you see :
which means : all is well,
If certificates become really important, as no valid certs means : web site down, then you can use something like this with auto notification if certificate didn't get renewed for 'some reason'.To check if you portal is fine : connect to it, inspect the cert - its just 4 clicks away :
and if your still have doubts, every week you are aloowed to manually renew also :
Hit the issue button :
seconds later you should see a Green Success message, and you have a new Portal/pfsense certificate.
Don't believe what is shown, check again with your browser.
An issue ? That's a feature : the moment has arrived that you can show (to yourself) who is the admin
@VinzzB said in How to use the pfsense name instead of the IP address in http?:
Port 80/443 is still used for the pfsense GUI
Be ware that the pfSense GUI nginx listens to ALL interfaces, and that includes even WAN.
You've showed it yourself :root nginx 88476 5 tcp4 *:443 *:* root nginx 88476 7 tcp4 *:80 *:**.443 means : any (or all) interfaces
It's not defined what happens when multiple instances of the same process are listening to the same interface, port and protocol.
Normally, that's a syntax error.
nginx is probably an exception and is smart enough (I guess ?) that more then one nginx process can listen to the same port, same interface but it's undefined who answers the incoming connection.
If a captive portal visitor sees a browser opening this :
then something really went wrong.
-
@Gertjan said in How to use the pfsense name instead of the IP address in http?:
Well ok, not an issue for me, and it will their problem. Its fine that they block their device's incoming connections, I get that. But when they also start to limiting to port X and port Y, but not port Z, that has nothing to do with security, that's just an overdoses of Toctic.
I don't agree that this is their problem. CP is running on a different port that is not designated for http(s) traffic.
Port 8002/8003 are used for different purposes. eg. Port 8002 is used by Teradata ORDBMS and port 8003 by M'sft SCCM. Blocking these outgoing ports IS better for security. This way a user is not able to (accidentally) connect to a service on an unknown network Not blocking this traffic could potentially lead to an information leak (depending on the services). Especially services that can be configured through DHCP or other autoconfig services.
I do get your point that this is somewhat ridiculous, as a device always needs to allocate high dynamic ports to connect to other servers anyway. But security wise it is (a little) better to block these requests by default.
I have a brand new pc with a clean installation of Windows 11. It was not able to connect to port 8002/8003 as it was blocked by the WIndows Firewall by default! I think this block happened because i had chosen "untrusted network" when connected for the very first time (= do not share device on the network). In this instance I do have control over this local firewall.
@Gertjan said in How to use the pfsense name instead of the IP address in http?:
When visiting a site, any site, it will be a https site. As there are no more http sites left to visit. Browser will even warn if a site is http only.
The https certificate only works for my CP domain (of course). I have disabled the interception of https traffic.
Yes, you are correct that most browsers will not use http in favor of https. Especially on websites using HSTS, which enforces https for a certain period on that domain. This is not an issue. When a Windows, Android or iOS device connects to a network, the device will always start a normal http request in the background. A message or notification is shown to the user when it receives a redirect to a CP page. This is sufficient. There is no need to show invalid Https certificates when browsing other public domains.The renewal of LE certificates works. However, the CP process does needs a restart after the renewal in order to pick up the new certificate by nginx. No big deal. This can be configured on cert renewal.
@Gertjan said in How to use the pfsense name instead of the IP address in http?:
Be ware that the pfSense GUI nginx listens to ALL interfaces, and that includes even WAN.
You've showed it yourself :My PF GUI is not exposed to my WAN interfaces. However, nginx does listen on all interfaces. This traffic is blocked on my WAN interfaces (main and failover WAN).
@Gertjan said in How to use the pfsense name instead of the IP address in http?:
It's not defined what happens when multiple instances of the same process are listening to the same interface, port and protocol.
This is defined in the nginx doc. more specifically:
nginx first tests the IP address and port of the request against the listen directives of the server blocks. It then tests the “Host” header field of the request against the server_name entries of the server blocks that matched the IP address and port. If the server name is not found, the request will be processed by the default server.The listen directive with an explicit IP will take precedence over the wildcard directive. So in this case the PF GUI will be shown when the CP process is stopped. However, The red PF page will be shown on the CP domain because the hostname is invalid. But you can access the PF gui when entering the right domain / hostname. As it will be listening on that interface.
example:
PF GUI domain: router.somedomain.com
CP GUI domain: guests.somedomain.comWhen CP process active:
- browsing to router.somedomain.com will redirect and serve the CP GUI
- browsing to guests.somedomain.com will serve the CP GUI
When CP process is inactive:
- browsing to router.somedomain.com will serve the PF GUI (with login option)
- browsing to guests.somedomain.com will serve the PF error page (invalid hostname)
In other words: this setup could expose the PF GUI on the Guest interface when something bad happens with the CP process. This could result in a security issue. I just wanted to point this out that I'm aware of this.
