Websites no longer reachables

This is a link that we can’t see with IPFire in the middle, while we read very well connecting upstream of IPFire.
http://guide.debianizzati.org/index.php/Debian_e_firmware

And this is the result of the command dig soa guide.debianizzati.org from the console of IPFire.

dig soa guide.debianizzati.org

; <<>> DiG 9.11.19 <<>> soa guide.debianizzati.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13229
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;guide.debianizzati.org.                IN      SOA

;; ANSWER SECTION:
guide.debianizzati.org. 3599    IN      CNAME   debianizzati.org.
debianizzati.org.       3600    IN      SOA     dnsl1.gidinet.com. hostmaster.gidinet.com. 2015100701 3600 600 1209600 3600

;; Query time: 298 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jun 09 11:21:28 CEST 2020
;; MSG SIZE  rcvd: 129

Yesterday during a Google Meet session the connection dropped many times, until I disconnected IPFire.
There are also many problems simply by logging into Facebook and always when there is IPFire in the middle.

I now do a new installation, but you will understand that a firewall in production must guarantee reliability, especially these days.
I really like IPFire.
However, I would like to understand how to diagnose issues.
It is not the first time that I suggest the introduction of tools and a guide for troubleshoting.

New installation of IpFire.
I confirm that there are problems with DNS.
The only way to work without problems, I’m sorry to say, is to not use IpFire.
Without help from you to identify the cause of the problem, I really don’t know what to do.

This is the link to FireInfo

|18:06:12|unbound: [1379:0]|notice: Restart of unbound 1.10.1.|
|---|---|---|
|18:06:12|unbound: [1379:0]|notice: init module 0: validator|
|18:06:12|unbound: [1379:0]|notice: init module 1: iterator|
|18:06:12|unbound: [1379:0]|info: start of service (unbound 1.10.1).|
|18:06:12|unbound: [1379:0]|info: generate keytag query _ta-4a5c-4f66. NULL IN|
|18:07:02|unbound: [1379:0]|info: validation failure <4393-sigfail.verteiltesysteme.net. A IN>: signature c rypto failed from 8.8.8.8|
|18:07:05|unbound: [1379:0]|info: validation failure <sigfail.verteiltesysteme.net. A IN>: signature crypto failed from 8.8.4.4|
|19:09:30|unbound: [1379:0]|info: validation failure <softwareupdate.vmware.com. A IN>: No DNSKEY record fo r key vmware.com. while building chain of trust|
|19:10:31|unbound: [1379:0]|info: validation failure <vcsa.vmware.com. A IN>: No DNSKEY record for key vmwa re.com. while building chain of trust|
|19:11:01|unbound: [1379:0]|info: validation failure <communities.vmware.com. A IN>: No DNSKEY record for k ey vmware.com. while building chain of trust|
|19:18:49|unbound: [1379:0]|info: validation failure <ocsp.msocsp.com. A IN>: No DNSKEY record for key clou d. while building chain of trust|
|19:22:41|unbound: [1379:0]|info: validation failure <communities.vmware.com. A IN>: No DNSKEY record for k ey vmware.com. while building chain of trust|
|19:22:52|unbound: [1379:0]|info: validation failure <communities.vmware.com. A IN>: key for validation vmw are.com. is marked as invalid|
|19:22:57|unbound: [1379:0]|info: validation failure <communities.vmware.com. A IN>: key for validation vmw are.com. is marked as invalid|
|19:23:12|unbound: [1379:0]|info: validation failure <www.vmware.com. A IN>: No DNSKEY record for key vmwar e.com. while building chain of trust|
|19:23:12|unbound: [1379:0]|info: validation failure <download3.vmware.com. A IN>: No DNSKEY record for key vmware.com. while building chain of trust|
|19:23:27|unbound: [1379:0]|info: validation failure <communities.vmware.com. A IN>: key for validation vmw are.com. is marked as invalid|
|19:23:28|unbound: [1379:0]|info: validation failure <download3.vmware.com. A IN>: key for validation vmwar e.com. is marked as invalid|
|19:23:28|unbound: [1379:0]|info: validation failure <www.vmware.com. A IN>: key for validation vmware.com. is marked as invalid|

How did you configure the DNS server?
WAN side DNS servers? Mode?

I have already answered above.
I have tried all DNS combinations and there are always problems.

Sorry to say, but IPFire since a couple of years ago changed DNS management model has always been carrying problems randomly.
It is absolutely necessary to have a web page where we can test, both from the Red and from the Green zone.
The tests are not for me, but for the development team to understand what is not working considering that the ISP are different and also the same ISP (like Vodafone) is different from Country to Country.
We cannot waste so much time behind a problem without knowing where to get our hands.

IPFire is an excellent product for schools and small businesses.
Where the router is not enough, but there is no need for complicated firewalls like pfsense or where there is not a sufficient budget to buy an appliance.
IPFire also has very useful features in these contexts and that other firewalls do not have, such as the web filter and the accelerator update.

However, the IPFire team must decide if it wants to work for an excellent product for a domestic use or a product for a professional use because in this case we cannot have problems of this type nor ask a technician to work hours and hours without being paid only to understand what’s going on.

Mine is a constructive criticism and I do it with regret.

You did not specify your network configuration and your environment,yet.
Would be very helpful to answer your problem.

Instead, it seems to me that I have already explained everything.

Router
(with Access Point. Vodafone line)
LAN IP 192.168.43.2
|
Red NIC (192.168.43.3/24 - Gtw 192.168.43.2)
IPIfire
Green NIC (192.168.201.1/24)

DNS: 8.8.8.8 - 8.8.4.4
Tested with UDP and TLS
Also tested with DNS from ISP

Add-ons:

  • Guardian
  • IDS with Emerging Threads Community and only emerging-malware.rules
  • Clamav

FireInfo

How is the situation without Guardian, IPS and clamav?
Maybe some of them blocks.
Just try to be shure.

Is your IPFire an ‘exposed host’ of the Vodafone router?

I installed iPFire once again.
These are the steps after installation, from the administration web page:

  • Activation of Fireinfo
  • Activation of ProxyWeb Transparent on the Green
  • Activation of URL filter and Update Accelerator
  • In ULR filter activation of the Shalla rules and activation of the adv filter only.
  • Installation of mc, htop, iftop, iperf3, clamav, squidguard, squid-accounting, sarg, guardian.
  • Activation of Clamav in ProxyWeb
  • Guardian activation.
  • Activation of UDV on Red with the sole rule “emerging-malware.rules” of Emerging Threads Community
  • GeoIPBlock activation with blocking of all countries except IT

Everything works.

As soon as I activated DNS 8.8.8.8 and 8.8.4.4 by removing the check box “Use ISP-assigned DNS servers” the page is no longer reachable.
After deleting the two DNS and reactivating the check-box, the page is reachable again.

The most bitter thing is that no one of the development team is giving me any advice to identify the problem that seems obvious to me, not mine, but of IPFire.
I have not “messed” with the rules, nor installed strange modules or altered the code.

Have you tried to change the DNS settings before activation/installation of restraining modules ( URLFilter, clamav, guardian, GeoIPBlock ) ?

Thus it is possible to differentiate between IPFire problems and a reject of DNS packets of your ISP.

But why should my ISP block DNS?
If I configure my PC with static IP and Google DNS, I have no problems.
However, no, the IPFire configuration is in the sequence I have indicated above. I will try to do a new installation.
The platters of my HDD are consuming due to the many installations made.

Why should you do a new installation?
Just deactivate some parts.

When I set up my IPS (IDS) I had picked the wrong rule and somehow/someway blocked DNS. I think Bernhard is trying to help you narrow things down and figure out if IPS (IDS) is really the problem.

As Bernhard mentioned a re-install is not needed. Just uncheck everything IPS and click Save.

Effectively, if I disable all the services and then activate the DNS of Gogle and then, finally, reactivate the services, the vmware page becomes visible again, but the Ipfire page is not yet visible.
I have to clear the DNS again to see it.

You understand that it is not even possible to continue testing in this way, by removing and placing a service.
And I’m talking about an ipfire installed just 4 hours ago!

I did a new installation and testing from a clean browser in “private” mode after each single activation of the service.
I confirm that “random” there were problems after activating IDS and GeoBlocking.
However, there may have been contingent problems.
Now I’m monitoring the system in the coming weeks.

I always believe that there must be other tools to test the situation other than activating and deactivating the single service.

Which IPS groups and which countries have you blocked?

IDV on Red with the sole rule “emerging-malware.rules” of Emerging Threads Community
All countries except Italy.
In any case, I don’t understand what GeoBlocking has to do with this issue. It should filter the accesses, not the navigation.

Now I found the debian server updates blocked and I had to disable IDS to be able to do them.
It is not possible to continue like this.
The firewall was turned on just over 2 hours and with no configuration except the one I said above, with DNS enabled first.
Now the DNS are “Broken”

Disable IPS, please.
Does the problem persist?

Enable stepwise IPS rules.
When do you get DNS problems? The last activated rule should be your “bad boy”.

In Italian Web Gui IPS is identified as Intrusion Detection System, to add a bit of confusion.
I disabled it hours ago, to be able to work.
Yesterday the problem was solved by deleting the DNS and enabling those of the provider.
Stepwise doesn’t appear in the rules of Emerging Threads Community

stepwise = step by step
Sorry for the lacking clarity. :wink:

Bernard, there is only one rule!
For days I have always been keeping the same configuration