How to use the pfsense name instead of the IP address in http?

[FSC830]

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

[goldsoft]

@Gertjan
The IP address has been successfully transformed into a domain name, but it also caused a deadlock. How can this be resolved

http://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]

@Gertjan

[Gertjan]

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

[goldsoft]

This post is deleted!

[goldsoft]

@Gertjan Thank you very much for your guidance.

[goldsoft]

@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 resolved

http://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.

[Gertjan]

@goldsoft

Try this :
Force redirect to preset URL :

I know, not a real solution, but it would break the recursive redirection.

[goldsoft]

@Gertjan The user has been authenticated and can access the internet. Further redirection would be meaningless

[Gertjan]

@goldsoft

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.

[johnwilliams1]

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

[Marsh35]

@johnwilliams1 Thanks for info!

[VinzzB]

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:

1. Create your CP config in the GUI using the default ports (>8000).
2. 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>

3. 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!
4. 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.
5. 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!

[Gertjan]

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

[VinzzB]

@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                  *:*

[Gertjan]

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

[VinzzB]

@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.com

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