Problems with pfsense.localdomain hostname

[fw]

I have a Netgate 3100. Currently, pfsense.localdomain resolves to 10.0.1.1, which is my LAN ip address. I have two questions/issues:

1. how do I tell pfsense to resolve the hostname to one of the other interfaces, or is it hardcoded to resolve to LAN ip only? (for example my OPT1 interface has ip 10.0.2.1, and MAINVLAN interface has ip 10.0.10.1)
2. I am not able to log into the LAN ip 10.0.1.1 via https even though the LAN firewall rule has the anti lockout rule enabled (as well as being completely open (allow set to source=* dest=* port=* etc). OPT1 and MAINVLAN rules are also completely open. I am able to ping 10.0.1.1, but cannot connect to it via https. I am able to https to the other interfaces without any problems. It is only a problem specifically with the LAN interface. Does anyone know what might be going on here?

[stephenw10]

Not really. By default the webgui should listen on all IPs. Does it just timeout?

You might have a port forward on LAN sending the traffic somewhere else for example.

We would need to see more of your config to be bale to tell you anything further.

Steve

[fw]

It times out. What part of my config would be helpful? Also, what about my first question? A workaround would be to have pfsense.localdomain resolve to one of the other interface IPs, but I don't see any settings or indication of what it is supposed to resolve to.

[stephenw10]

I've never tried to make it resolve to anything else, so I'm not sure TBH.

Obviously it should work to LAN. What firewall rules do you have on LAN?

What port forward rules do you have?

[johnpoz]

@stephenw10 said in Problems with pfsense.localdomain hostname:

Obviously it should work to LAN

Exactly - I would look to fixing the issue vs some work around..

There should be no reason why if your on the lan, you can not access the lan IP for the web gui.. Especially if you have antilock out enabled (default)

With antilock out - it should be pretty impossible to block your own access with even a floating rule..

[fw]

@stephenw10 I don't do any port forwarding. The firewall rules for my LAN currently are 1) antilockout rule, plus 2) completely open (src=* dst=* type=IP4 port=*)

[fw]

@johnpoz said in Problems with pfsense.localdomain hostname:

With antilock out - it should be pretty impossible to block your own access with even a floating rule..

Ok thanks. Maybe it is getting blocked by something outside of the firewall then. There is a unifi wifi AP and an unmanaged switch in-between my computer and the netgate device. I will try connecting my computer directly to the netgate LAN port to see if that works.

[johnpoz]

I don't see how AP could do anything.. How about sniff on pfsense lan IP when you try and access.. What do you see?

Unless maybe you running some sort of captive portal on your AP?

[stephenw10]

Yes or at least check the state table to see what states are opened from your client and on which interfaces.

[fw]

I figured out what the problem was. I had switched the webconfigurator to http instead of https at one point during console mode. Chrome had apparently cached the LAN IP as https instead of http, but not the interface IPs. So when I typed the LAN IP into chrome, it expanded it to https://10.0.1.1, which no longer worked. I guess the other interface IPs were expanded to http://*.

[stephenw10]

Ah, yeah, Chrome loves to do that.

[fw]

@stephenw10 I need to just stop using chrome completely. All it does is cause me headaches.

[jimp]

It was doing you a favor, though. Go back to HTTPS :-)

[fw]

@jimp yes did that already :) Although Chrome does not work at all with my self signed certificate. I added my SSL certificate and my intermediate root authority certificate in my keychain (MacOS) and it still refuses to connect over HTTPS. If I click on the security icon in Chrome to view the certificate, it says that it is trusted by the OS, even though Chrome says that it is "revoked". Firefox works great though.

[jimp]

Probably the default cert lifetime. The GUI certs on 2.4.4-p3 and earlier default to 2000 days, Macs only allow 825 now (and will lower that to 389 soon).

https://redmine.pfsense.org/issues/9825

[fw]

@jimp this is a Chrome specific issue. MacOS says that the cert is trusted. Firefox also says that it is trusted. Also, I generated the Cert a couple of weeks ago, so this is definitely not reaching a cert lifetime issue.

[jimp]

It still can be. Look at the change made in https://redmine.pfsense.org/projects/pfsense/repository/revisions/71185882dc168e49347f0924f33a207aaf6e2db0/diff and make that edit yourself by hand (but use 389, not 825, and then go to a shell prompt (ssh or console) and run pfSsh.php playback generateguicert and see what happens.

[fw]

@jimp Ohh I see what you are saying. I'll give that a try. Thanks.

[fw]

That worked thanks! It's annoying that Chrome's error was this:
NET::ERR_CERT_REVOKED

instead of this:
NET::ERR_CERT_VALIDITY_TOO_LONG

[johnpoz]

Exactly!!! BS error that doesn't say what the problem is!