Problems with pfsense.localdomain hostname

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!