Good day IPFire community,
We recently upgraded one of our IPFire firewalls to version 164, in the past week.
With that being said, we found that the IPFire firewall thereof, does not have internet when we come in, in the morning and when rebooting the firewall - internet connectivity is then re-established. Has anyone experienced the same effect?
What kind of internet connection do you have?
Are there any errors in /var/log/messages?
Good day Bernhard,
Thank you for your response.
Please note that we have setup a simple Wan (the Red ethernet card is connected to an ISP router) and Lan nework (we have enabled web browsing through the green network thereof).
With regards to the error log, is there anything (e.g.) in specific I should keep an eye out for (there are a number of logs generated so I would like to ensure that I do not miss anything).
Assuming that your WAN is per DHCP, you should look at messages tagged ‘dhcpcd’ and messages about the red0 interface.
Hi Bernhard,
Thank you for your response, it is much appreciated and noted.
Kindly note that WAN is setup to make use of a static IP address. However, we will review the log files accordingly and advise should we be able to spot anything or if we require any further clarification.
Hi Bernhard,
Please be advised that we have since done the following due to the logs mainly showing connection attempts from the red interface and there seems to be no obvious errors listed against the interface thereof.
1.) We upgraded the firewall to that latest software version. However, the issue still persisted thereafter.
2.) We then setup a new IPFire firewall and the same effect then persisted.
3.) We have now raised an inquiry with our ISP to try and determine if their router is perhaps not experiencing intermittent connectivity issues and we have removed the static DNS settings from the firewall to try and establish if they are the cause of the issue which recently transpired.
Hi Bernhard, please note that by removing the DNS settings/IP address set manually. The IPFire no longer looses internet connectivity.
Hi,
that would indicate a problem caused by your ISPs DHCP server, since Core Update 164 did not change anything related to DHCP in IPFire.
Please let us know if this turns out to be caused by IPFire down the line, so we could investigate and solve this problem for all users then. 
Thanks, and best regards,
Peter Müller
Good day Peter, thank you for your response and the above mentioned has been well acknowledged.
Please note that the issue experienced is unfortunately not resolved. After various troubleshooting and investigations, we found that the loss of internet connectivity is caused by the Web Proxy service stopping overnight (kindly note that all other services on the IPFire, firewall work as expected when the web proxy stops). In addition to this, we no longer reboot the entire firewall when the issue occurs, we simply just restart the web proxy and all is then in order.
Do you perhaps know what could cause the web proxy to stop abruptly and how we could possibly combat the issue experienced?
The logs of web proxy are stored in /var/log/squid/.
Especially /var/log/squid/cache.log may be interesting ( if logging is switched on in the WebGUI ).
Hi Bernhard, thank you for your feedback.
We will ensure to review those logs accordingly and advise further, should we pick up anything unusual.
Hi Bernhard, the IPFire machine which had its web proxy service stopping has not had its web proxy stop since the 13th of April 2022. With that being said, we have not made any new changes to the firewall thereof.
However, we have since noticed that one of our other IPFire firewalls had its web proxy service stop abrubtly two days in a row. Please see the screenshot attached which illustrates the logs generated (the firewall was rebooted just after 07:00 AM this morning. However, looking at the logs there seems to be no logs generated between 08:00PM on the 20th of April and 07:00AM on the 21st of April. Do you perhaps know what caused this? as we assume that we then would not be able to determine the true cause of the web proxy stopping abrubtly).
