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