I had this problem from core 135. I was new at the time, but now at 146 I believe. I moved my office equipment and have green and blue connected with no issues. From Ipfire SSH I can ping to network IPs without issue on both subnets. I had not made any config changes between working and non-working conditions other than moving equipment and I ensured cables were placed identically.
This had been happening for a long time. In the past when my ISP went offline, it made it impossible to reach http:/IP:444 on Green, and when ISP came online I would then again be able to reach admin. Is this normal?
It is normal that you cannot reach the gui via http:/IP:444 the correct url is https://IP:444 but
is not normal that you cannot reach the webgui when red is offline. It can take a bit longer to render some pages of the webgui without DNS but is should connect.
Have you configured a proxy in your browser that must resolved before the first access? If yes you should add an exception for the IP. Also some Plugins of Virusscanners or Malware protection need online access before they allow to browse anything.
Your toying right? You had to have realized that was a typo lol
My DNS PiHole is internal, and I have local entries, plus who needs DNS when your using IP addresses.
When red is up I have no problems any time, but the minute red goes offline, I can’t get to the wui from green. Its always been this way for me since using the IPFire. Weird Id say.
I just try it out:
I disconnected my cable from my red wait for a minute for being sure and connect to the wui and I can without any problem.
I am just thinking maybe it is a hardware problem/setting?
I am using a HPE NC382T one side for red one for green and my build-in lan for blue.
but for me it sound like there something waiting for red to be online, and if I am not mistaking that only effect your boot-up, as ipfire will wait for red to be online, but again I think they change it.
How do your setup looks like?, because I think in my early days with ipfire, I had something like that, but at that time I was using usb-lan’s for green and blue, but still it’s a wile ago.
Btw I am just trying to help I am no developer’s like Arne or Michael and the rest, but just thought to try it on my box and maybe that help you find your problem.
This is very extrange. I take many installations behind me and has never happened to me.
Try to determine the problem. I advise you several things:
DNS Servers only do a name to IP translation. Therefore, if you put “https://IP:444” the DNS service should not take action since there is nothing to translate. PiHOLE does more than just block page access.
- In the state you are in, perform a “tracert 18.104.22.168” for example to determine what jumps it takes to get there.
Try this yourself but with RED disconnected. In this case, from point 3 it should give an error and make 30 jumps without being able to get there. (Logically, there is no internet)
Remove elements from the equation. That is, it removes PiHOLE from the network (temporarily, for testing, logically) and enables DHCP on the GREEN interface of IPFire (in case the PC does not have a Fixed IP). Can you access the IPFire GUI?.
Disconnect the RED interface cable from IPFire. Can you access the IPFire GUI?.
When you carry out all these tests, you have to verify that you can surf the Internet less in the cases that you have the cable disconnected from the RED Interface of the IPFire.
Tell us the results.
If the PiHole is under load it may not answer for local hostnames if it was offline and has some external queries in the queue.
Browser plugins or the browser if a proxy is configured by a hostname. In this case it must resolve the proxy before it can ask it for the url. Thats why i ask for plugins or proxies.