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:
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:
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. 
Bernard, there is only one rule!
For days I have always been keeping the same configuration
As the name states this topic contains several rules ( cf. http://rules.emergingthreats.net/open/suricata-5.0/rules/emerging-malware.rules ).
These rules can be activated/deactivated ( cf. wiki.ipfire.org - Rule Selection ).
I can’t believe even one of these rules blocks Debian’s apt update / upgrade
This sounds like the shellcode IPS rules, and would be the intended behaviour then as Debian packages mostly contain executable shellcode.
I don’t know these rules in depth. I do not use the IPS ( too much effort for my small home installation ).
See the wiki article.
A general assistance is hard, because the rule set needed depends on the special environment of the system, which differs from case to case.
The point, Peter, is how to diagnose the problem.
I’ve been dragging it around for weeks.
And I changed the DNS; and I activated and deactivated the individual services; and I made new installations; and I changed the providers of the rules; …
Now you can’t ask me to test every single rule!
If I also need to disable IPS and Guardian, what use is IpFire that it cannot already do with a small Dlink router or with that of the Internet provider?
Said this, I don’t think I’m the only one in Europe to use that rule, right?
On Monday I disconnect Ipfire from the network because at this point there are more issue than advantages. If there is any suggestion for making a diagnosis, I will surely consider it.
That is not yet “try to deactivate”, “try to activate”, “try to …”
Meanwhile, I do not make updates on other IpFire to not have to find myself having other blocks.
