IPFire 2.27 (x86_64) - Core Update 163 to 164 no internet pages

[rowdyronny]

Hello,

I update IPFire 2.27 (x86_64) - Core Update 163 to 164 and after the update and reboot, none of the systems on green or blue could access any webpage on the internet. I could ping the firewall’s internal IP on green, blue and orange and could ping any external IP adress like 1.1.1.1 also the IPFire interface did not respond (time out). I rebooted it twice and waited for about 5 minutes to be absolutely certain it booted completely.

After searching for a while, I found something I assumed totally unrelated to my issue. Core-161: Location Blocking stops Green access

I connected a screen and keyboard to the IPFire PC and executed the following commands :
iptables -A CUSTOMINPUT -i green0 -j ACCEPT
It still did not work so I did
/etc/init.d/apache restart
/etc/init.d/firewall restart.

Now everything works but I did disable “Location Block” , just in case. I post this here in case anyone else has this ackward issue.

[pmueller (Peter Müller)]

Hi,

your description sounds like a DNS-related issue, since pinging public IP addresses still worked, but I am not quite sure because of the following snippet:

@rowdyronny

also the IPFire interface did not respond (time out)

Were you accessing it via a FQDN or an IP address?

@rowdyronny

After searching for a while, I found something I assumed totally unrelated to my issue. Core-161: Location Blocking stops Green access

Indeed, this bug was quite a bad one, but it cannot occur with any Core Update later than 162 again, because we have built safeguards into the location filter, preventing it from being active on other interfaces than RED.

@rowdyronny

Now everything works but I did disable “Location Block” , just in case.

Does enabling the location block again make a difference? Also, are there any apparent error or warning logged on boot or while executing the /etc/init.d/... restart commands?

Thanks, and best regards,
Peter Müller

[willsten6 (David Campbell)]

Hello,
I also encountered this problem after the update IPFire 2.27 (x86_64) - Core Update 163 to 164. No internet connectivity.
I followed the advice from Rowdy Ronnie above and ran:
iptables -A CUSTOMINPUT -i green0 -j ACCEPT
/etc/init.d/apache restart
/etc/init.d/firewall restart

This got me connected again.

Hopefully I’m still safe behind firewall but I’ll be more cautious about upgrading.

Is there a known problem that’s causing this and is there a recommended fix other than above?
Thanks all,

[pmueller (Peter Müller)]

Hi,

@willsten6

Hopefully I’m still safe behind firewall but I’ll be more cautious about upgrading.

no offense intended, but it would be better if you could help us testing upcoming Core Updates, and report your findings. While we (= the IPFire development team) of course test updates, we cannot simulate all situations, especially when it comes to exotic hardware or very complex network setups. Therefore, more testing feedback is highly appreciated.

Also, I am personally quite worried about the speed people install Core Updates. Looking at this figure, roughly 45 % of all IPFire installations are more than three (!) updates behind at the time of writing. Given the rapidly changing threat landscape on the internet, I don’t think this is an acceptable amount.

@willsten6

Is there a known problem that’s causing this and is there a recommended fix other than above?

At the moment, no. I did not even get what exactly happened in your cases.

OP seems “only” to have lost DNS functionality, while in your case, there does not seem to be any internet connectivity at all. Please answer the following questions:

• What does your IPFire setup look like?
• How is your IPFire connected to the internet (DSL/DHCP/…)?
• Does this problem appear again after a reboot?
• If so, what is the output of iptables -L -n -v on your IPFire machine?
• Are there any errors or warnings being logged during boot or while executing the commands you mentioned above?
• What does your firewall ruleset look like (screenshot)?

I’d very much like to get to the root cause of this problem(s), therefore asking for all these. Thank you in advance for your help.

Thanks, and best regards,
Peter Müller

[chimpanzeejade]

I had a similar scenario after upgrading 163 > 164 just now.

• I could ping IPs on the internet
• I could not get out to any FQDNs on the internet
• I could ping the IPfire Green adapter, but not connect to it via SSH on 222 or web interface via IP on 444.

What I found was that after IPfire rebooted, the firewall service had to be started manually.

I connected to the ipfire box directly and executed:
/etc/rc.d/init.d/firewall start

and everything started working again.
I don’t have time now to investigate deeper, just sharing in case it helps someone.

[willsten6 (David Campbell)]

Hi,

*** What does your IPFire setup look like?**
HP 8100 Elite COre 2 DUO, 16GB memory, 4 port ethernet card
03:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
03:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
04:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
04:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)

[root@ipfire ~]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sr0 11:0 1 1024M 0 rom
sda 8:0 0 111.8G 0 disk
├─sda4 8:4 0 110.6G 0 part /
├─sda2 8:2 0 32M 0 part /boot/efi
├─sda3 8:3 0 1G 0 part [SWAP]
└─sda1 8:1 0 128M 0 part /boot

*** How is your IPFire connected to the internet (DSL/DHCP/…)?**
DHCP from Spectrum

*** Does this problem appear again after a reboot?**
Yes - I rebooted several times after update - could not connect to any website or ping FQDN - did not have any external IPs to ping

*** If so, what is the output of iptables -L -n -v on your IPFire machine?**
For convenience and ease I posted here:
https://metrotone.com/ipt.output

*** Are there any errors or warnings being logged during boot or while executing the commands you mentioned above?**
Did not notice but here is some output from DMESG
[18342.612185] DROP_NEWNOTSYN IN=green0 OUT=red0 MAC=00:1b:21:nn:b1:95:b8:3e:59:a8:61:6e:08:00 SRC=192.168.1.206 DST=nn.207.151.88 LEN=76 TOS=0x00 PREC=0x00 TTL=63 ID=37928 DF PROTO=TCP SPT=57794 DPT=443 WINDOW=88 RES=0x00 ACK PSH URGP=0
[18342.612346] DROP_CTINVALID IN=green0 OUT=red0 MAC=00:1b:21:nn:b1:95:b8:3e:59:a8:61:6e:08:00 SRC=192.168.1.206 DST=nn.207.151.88 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=37929 DF PROTO=TCP SPT=57794 DPT=443 WINDOW=88 RES=0x00 ACK RST URGP=0
[18382.164900] DROP_INPUT IN=red0 OUT= MAC=00:1b:21:nn:b1:90:00:01:5c:78:2a:46:08:00 SRC=192.241.213.67 DST=nnn.nn.121.184 LEN=40 TOS=0x00 PREC=0x00 TTL=241 ID=54321 PROTO=TCP SPT=48451 DPT=5984 WINDOW=65535 RES=0x00 SYN URGP=0
[18411.772559] DROP_INPUT IN=red0 OUT= MAC=00:1b:21:nn:b1:90:00:01:5c:78:2a:46:08:00 SRC=104.174.169.11 DST=nnn.nn.121.184 LEN=44 TOS=0x00 PREC=0x00 TTL=51 ID=38962 PROTO=TCP SPT=36927 DPT=23 WINDOW=44807 RES=0x00 SYN URGP=0

*** What does your firewall ruleset look like (screenshot)?**

I will be happy to provide more information.

[rowdyronny]

Hello,
I always use a bookmark, it links to The firewall on GREEN “https://192.168.48.1:444/cgi-bin/index.cgi”.

I saw no errors on the commands I entered; /etc/init.d/firewall restart.

As I checked all log files I noticed DynDNS didn’t update correctly. I ran ’ ddns -d update-all --force ’ and now it apparently updated successful.(the error was “DDNSAuthenticationError: Authentication against the server has failed” but I am sure this is not related to the original issue)

This is around the time I typed the commands ;

19:23:25	suricata:	Signature(s) loaded, Detect thread(s) activated.
19:23:25	suricata:	rule reload complete
19:23:25	suricata:	cleaning up signature grouping structure… complete

This was the first error and around the start of the reboot; the point Internet was no longer available for the users;
|18:38:39|suricata: |[ERRCODE: SC_ERR_PCRE_PARSE(7)] - parse error, ret -1, string 2,=,1,1,relative,l ittle,bitmask 0x8000|

I rebooted the firewall and once again,
Pinging 8.8.8.8 results in “Reply from 8.8.8.8: bytes=32 time=20ms TTL=58” → OK
Pinging www.google.com results in a host not found. → NOT OK
Opening the IPFire webpagepage does not work.

So I reconnect a keyboard and screen and after doing
/etc/init.d/firewall restart
it works again.

I found
suricata: [ERRCODE: SC_ERR_FOPEN(44)] - Error opening file: “/usr/share/suricata/threshold .config”: No such file or directory
so I disabled suricata on GREEN and BLUE. And rebooted.

Didn’t work, so I restarted the firewall. OK
Went into the webinterfece, turned IPS on green again and it locked me out again and no Internet.
Restarted the firewall, and was able to get to the page but no Internet (IPS disabled on GREEN and BLUE).

added the rule for green and blue, /etc/init.d/firewall restart
it works again.

I only had that NTP rule to redirect NTP requests to the firewall, I removed it but after reboot, same thing.
Pinging 8.8.8.8 results in “Reply from 8.8.8.8: bytes=32 time=20ms TTL=58” → OK
Pinging www.google.com results in a host not found. → NOT OK
Opening the IPFire webpagepage does not work.

added the rule for green and blue, /etc/init.d/firewall restart
it works again.
I will leave the screen and keyboard connected.

[rowdyronny]

I completely turned off the IPS and I am able to reboot without being blocked.

If I enable IPS for GREEN, I immediately loose access to the webinterface.
I use Talos VRT rules for registered users.

I restarted firewall with accept rule for green and everything worked again.
I turned on IPS for RED only now. Rebooted and again, all blocked.
I restarted firewall with accept rule for green and everything worked again.

[bbitsch (Bernhard Bitsch)]

Maybe this is related to this thread Enabling Talos IPS rules cause trouble after upgrading to Core Update 164

[seadoo1a (Carlos Gonzalez)]

It is, By using the Snort Community rules instead of the Talos rules, Your system will work fine with no issues on Core 164. Talos ruleset running on Core 164 is causing the issue.

[willsten6 (David Campbell)]

Carlos,

I guess my system has been unable to connect since I updated on 3/12/202

[rowdyronny]

Hello,

The animation will run forever, as far as I could deduct from the logs, some of the TALOS rules link to missing files or folders so it will never complete. The animation doesn’t matter, worst case go to the setting page, disable IPS, then restart IPCop.

Then you can go the the IPS configuration and select another Provider. Make sure to delete the TALOS rules under the Providers, by clicking the “wastebin” next to the Under Ruleset Once they fixed their issue(s) you can use them again. I suggest for now to use one of the other Providers.
Then add a new Provider of your choice. I swapped to Emergingthreats for the moment.

If the screen stops at Ruleset update for more than 5 minutes, reboot IPcop.

Once the links to Talos (damaged) ruleset are gone, everything will work again and the page will respon in a normal way.

[willsten6 (David Campbell)]

Hi,
I can’t find anyplace to disable IPS. COuld you please tell me where in the menu system that is located?
Thank you,
Slouchy

[anon42188109]

Firewall > 4th option down.

[willsten6 (David Campbell)]

That’s where I get the spinner for 3 days. See picture above. Would it be safe to kill -9 the IPS process and then try to disable?

[seadoo1a (Carlos Gonzalez)]

David,

Just reboot the firewall. Upon rebooting, you can access the page again and change your settings.