Selected websites and web services unreachable, apparently after update to Core 155

Hi All

New to the forum and hope to get some help & suggestions.

I do IT support for a hospitality company in Namibia (Africa) and took over an IPFire server that’s used as firewall and default gateway. The server was set up by a 3rd party that has since gone out of business. I am not an expert on IPFire or Linux but learned my way around it to be mostly OK in the 4 years I have been here.
We do not have a very complicated setup - 2 MS servers, 20-odd workstations, and some NAS units. As mentioned the IPFire box serves as firewall and all the aforementioned devices use it as a gateway to the internet. We have fibre internet with the fibre modem connected to Red interface and LAN on Green.

I updated from Core-Update-Level 152 or 153 to 155 on Tuesday and it seems since then I am unable to access certain websites and -services. So far the ones in question are MS updates for the 2 MS Server 2012 R2 servers, ESET Endpoint Antivirus 7.x updates and connecting to LiveGrid, a sync service for hospitality establishments and our government’s online tax portal. The vast majority of sites & services work just fine, but the ones above are quite dead :frowning: I did not get any reports from our ISP that they are experiencing issues, I phoned them anyway and they assured me there are no problems on their side. Also, one is able the access eg. the tax portal when connected a cell phone hotsopt instead of the office LAN or Wi-Fi.

I looked at the firewall logs on the IPFire web interface but I do not have enough know-how to see if anything is the matter, nothing jumps out at me. Our firewall rules are very simple:
Allow TCP 3389, TCP 5111 and UPD 5112 for RDP from any source to our two servers
Deny TCP SSH and 444 from any source to any destination

That is my problem in a nutshell. I hope it’s something simple in the Core 155 update that can be remedied. Hope I included enough info - please say if anything else is needed. Thanks in advance for any help & suggestions!

Oh, something I forgot - I found this link for ESET IP addresses and hostnames.

It’s quite extensive, I did not go through every IP on there, but I can confirm that I can ping and TRACERT all the hostnames/IP’s for detection engine updates successfully from my machine when connected to our Wi-Fi. On the same machine ESET is unable to update and LiveGrid is not accessible.

Could you test:
WUI → Network → Proxy WWW → Clear Cache

then check Eset update and Live Grid

edit
I have a similar problem with update Eset Endpoint S. 8.x , Live Grid and some sites.
After Clear Cache is OK… until the next morning.
But Clear Cache must take place after the user has logged on to the computes.
Reboot ipfire does not help.

Hi @ncl_it

I would try to disable all the modules that can cause problems. For example, disable proxy, IDS / IPS, Location Block, etc. In other words, leave the IPFire only with what is essential to work (you cannot deactivate the Fw) and test if it works. If it works, gradually activate the protections. First, the Proxy and test. Activated the proxy, activate the Clamav and test, if it works, activate the Web Filter and test. So little by little until you find what causes problems.

You will comment to us.

Greetings.

1 Like

Hi @tphz
Thanks for the suggestion - tried it but no success. :confused: Trying @roberto 's suggestion next

Hi @roberto

Thanks - this works! :clap:
I unchecked the boxes for web proxy Enabled on Green, URL Filter and Update Accelerator. IPS and Location Block was not enabled. Restarted the server and now the problematic sites & services are all working again.

Not yet sure what the culprit is, I’ll enable the services one by one on Monday to ascertain and report back.

Thanks a lot for the help, quite simple in the end but helps if you know where to start looking. Appreciate it!

Hi @ncl_it again.

I’m glad about it :call_me_hand:.

You will tell us which module is the culprit to try to help you solve the problem.

Sometimes the Clamav is usually the culprit and the solution is to whitelist the url. Other times, directly the Proxy and in that case, it is to bypass that page so that it does not go through the Proxy.

We await the result.

1 Like

Yesterday I unchecked:

Enable Intrusion Prevention System
obraz

Enable Guardian
obraz

SquidClamav Enabled
Cache management
obraz

Today.
I started computer and I could not:
-connect to Eset LiveGrid
-update Eset Endpoint
-open the necessary page

WUI → Network → Proxy WWW → Clear Cache – this time it did not help.

Type squid restart in ssh console – this time it did not help.

In file: /var/log/squid/acces.log
many records like

TCP_MISS_ABORTED/000 0 HEAD http://repository.eset.com/v1/com/eset/apps/business/ees/windows/metadata3 - ORIGINAL_DST/

TCP_MISS_ABORTED/504 0 POST http://i1.c.eset.com/ - ORIGINAL_DST/

TCP_MISS/502 37397 HEAD http://update.eset.com/eset_upd/ep8/dll/update.ver.signed - ORIGINAL_DST/ text/html

In file /var/log/squid/cache.log
records like

2021/05/02 16:30:42 kid1| WARNING! Your cache is running out of filedescriptors 2021/05/02 16:31:36 kid1| SECURITY ALERT: Host header forgery detected on local=10.0.0.2:3128 remote=10.0.0.12:49871 FD 2663 flags=33 (intercepted port does not match 443) 2021/05/02 16:31:36 kid1| SECURITY ALERT: on URL: ts.eset.com:443 2021/05/02 16:31:36 kid1| kick abandoning local=10.0.0.2:3128 remote=10.0.0.12:49871 FD 2663 flags=33 2021/05/02 16:31:42 kid1| WARNING! Your cache is running out of filedescriptors

2021/05/02 16:40:35 kid1| WARNING! Your cache is running out of filedescriptors 2021/05/02 16:41:35 kid1| WARNING! Your cache is running out of filedescriptors 2021/05/02 16:41:36 kid1| SECURITY ALERT: Host header forgery detected on local=10.0.0.2:3128 remote=10.0.0.12:49896 FD 2112 flags=33 (intercepted port does not match 443) 2021/05/02 16:41:36 kid1| SECURITY ALERT: on URL: ts.eset.com:443

2021/05/02 16:51:35 kid1| WARNING! Your cache is running out of filedescriptors 2021/05/02 16:51:36 kid1| SECURITY ALERT: Host header forgery detected on local=10.0.0.2:3128 remote=10.0.0.12:49918 FD 264 flags=33 (intercepted port does not match 443) 2021/05/02 16:51:36 kid1| SECURITY ALERT: on URL: ts.eset.com:443

2021/05/02 18:27:14 kid1| WARNING! Your cache is running out of filedescriptors 2021/05/02 18:27:43 kid1| ERROR: NF getsockopt(ORIGINAL_DST) failed on local=10.0.0.2:3128 remote=10.0.0.200:51862 FD 9 flags=33: (2) No such file or directory 2021/05/02 18:27:43 kid1| ERROR: NAT/TPROXY lookup failed to locate original IPs on local=10.0.0.2:3128 remote=10.0.0.200:51862 FD 9 flags=33 2021/05/02 18:27:43 kid1| BUG 3556: FD 9 is not an open socket.

Hi All,

Apologies for the slow reply, had a blue Monday and yesterday was a public holiday.
So far I have enabled URL Filter and Update Accelerator and all the sites and services still work. All that’s left is the proxy, I have not yet enabled that. I’ll have to check after hours, don’t want operations disrupted during normal hours. Will report back when I have done so.

Cheers

url filter and update accelerator work through the web proxy. They don’t work independently.

Start with turning on the web proxy.

1 Like

Hi @tphz

You can try uncheck all SquidProxy:

imagen

Maybe the Squid misshapen the packages. To do this, there is a way to bypass certain URLs to the proxy.

Uncheck for not use Proxy and try again.

Tell Us something.

Regards.

3 May evening, I changed the settings to:

and I observe.

So far:

  • LiveGrid and update Eset Endpoint - not bloked
  • websites needed - not bloked

Regards

Hi @tphz.

In other words, you can say that the fault is the Proxy, right?.

The only solution I can give you is to create a bypass to the proxy in the corresponding URLs. Maybe someone can give you a better solution.

You can follow these steps so that the Proxy does not capture those requests to port 80 that it blocks.

In summary:

You need edit “/etc/sysconfig/firewall.local” with this: (www.qrz.com are the URLs that you cannot access).

start rule:
/sbin/iptables -t nat -A CUSTOMPREROUTING -p tcp --dport 80 -d www.qrz.com -j ACCEPT

reload rule:
/sbin/iptables -t nat -F CUSTOMPREROUTING
/sbin/iptables -t nat -A CUSTOMPREROUTING -p tcp --dport 80 -d www.qrz.com -j ACCEPT

stop rule:
/sbin/iptables -t nat -F CUSTOMPREROUTING

After:

[root@bs sysconfig]# ./firewall.local stop
[root@bs sysconfig]# ./firewall.local start

Try and say Us.

NOTE: You have to try this, once the steps are done and activating the Proxy

2 Likes

@roberto tanks a lot for hint

Im not progammer but many signs point to a proxy.

The file: /etc/sysconfig/firewall.local with the rules looks like this:

#!/bin/sh
# Used for private firewall rules

# See how we were called.
case "$1" in
start)
## add your 'start' rules here
/sbin/iptables -t nat -A CUSTOMPREROUTING -p tcp --dport 80 -d www.needed_website.com -j ACCEPT
;;
stop)
## add your 'stop' rules here
/sbin/iptables -t nat -F CUSTOMPREROUTING
;;
reload)
$0 stop
$0 start
## add your 'reload' rules here
/sbin/iptables -t nat -F CUSTOMPREROUTING
/sbin/iptables -t nat -A CUSTOMPREROUTING -p tcp --dport 80 -d www.needed_website.com -j ACCEPT
;;
*)
echo "Usage: $0 {start|stop|reload}"
;;
esac

After insert the rules and reboot IPFire:

  • http “www.needed_website.com” - not bloked :slight_smile:
  • Eset updates and LiveGrid - bloked :frowning:

So this is not a complete solution. :face_with_raised_eyebrow:

But… that’s not the end of the story…

Edit
After many tests, I noticed some correlation.
After some reboots (sometimes after 2, sometimes after 5th, sometimes after 1 in SSH console)
in the file /var/log/squid/cache.log shows an entry:
FATAL: Squid is already running: Found fresh instance PID file (/var/run/squid.pid) with PID 2905 exception location: Instance.cc(121) ThrowIfAlreadyRunningWith
Then Eset Updates and http webpages are blocked, but https webpages not bloked.

Sometimes helps (in my case):
Disable Proxy, Clear Cache, WUI reboot, Enable Proxy (cklick on Save and Restart)

Hi All,

I checked the box for Enabled on Green (Advanced Web Proxy), then Save and Restart - sites and services again then do not work. Surely seems to me like Core 155 changed something with the proxy…

For now I will leave the proxy disabled, I’m not going to try and add umpteen URLs/IPs for all the sites and services, there might also be ones I am not aware of.
Hopefully there will be a fix with the next core update.

Thanks again for the help.

I’m in the process of testing.

Could you uninstall clamav and squidclamav, reboot ipfire, and then test again?

Regards

Neither of those packages were installed to begin with, did not have to disable or uninstall.