[solved, bad peering from Deutsche Telekom] after suricata 5.0.4_1 Update, suricata is no longer active
-
@bmeeks I disabled pfBlocker, but it is still horribly slow. I do have a new ISP, so maybe there is some "bad" peering involved? I will try and let is do its thing for more time. Also, nobody else seem to have this problem.
acme security 0.6.9_2
Cron sysutils 0.3.7_4
openvpn-client-export security 1.5_4
pfBlockerNG-devel net 3.0.0_6 -
@bob-dig said in after suricata 5.0.4_1 Update, suricata is no longer active:
@bmeeks I disabled pfBlocker, but it is still horribly slow. I do have a new ISP, so maybe there is some "bad" peering involved? I will try and let is do its thing for more time. Also, nobody else seem to have this problem.
acme security 0.6.9_2
Cron sysutils 0.3.7_4
openvpn-client-export security 1.5_4
pfBlockerNG-devel net 3.0.0_6Do you use the DNSBL feature of pfBlockerNG-devel? If so, simply disabling pfBlockerNG-devel does not necessarily undo the changes to the DNS resolver done by DNSBL. At least that's the way I understand it based on some replies from other users with similar issues as you. Only after they undid the DNSBL changes did the rules download work. Simply disabling pfBlockerNG-devel was not enough.
Using the DNSBL feature causes changes to be made to probably the most crtical component of your Internet connection: your DNS where all human-readable URLs are translated into appropriate IP addresses. If that part is monkeyed with, then all sorts of stuff can break.
-
@bob-dig said in after suricata 5.0.4_1 Update, suricata is no longer active:
@bmeeks I disabled pfBlocker, but it is still horribly slow. I do have a new ISP, so maybe there is some "bad" peering involved? I will try and let is do its thing for more time. Also, nobody else seem to have this problem.
acme security 0.6.9_2
Cron sysutils 0.3.7_4
openvpn-client-export security 1.5_4
pfBlockerNG-devel net 3.0.0_6A user yesterday or the day before was experiencing a problem with the Snort GPLv2 rules downloading. His fix, turning off DNSBL, then the download worked. Apparently some IP list he had turned on in DNSBL was blocking the AWS address space where the Snort GPLv2 rules are hosted. He disabled pfBlockerNG-devel first, but no change. Then I suggested he turn off DNSBL and undo the changes it had made to the
unboundconfiguration and then everything worked.I do not mean to pick on you, @Bob-Dig, nor am I singling you out. Rather I'm saying this for the benefit of others that may read this thread.
When you configure lots of IP Block Lists from various sites, you really need to be watchful of what exactly is on those lists and also realize that they can block all kinds of legitimate stuff along with bad stuff. So when something is not working on your end, your very first troubleshooting step should be looking at all the blocks from the "blocking packages" you have installed. Next, start turning those packages of one-by-one to see if your problem corrects. As I mentioned, a large majority of the time it will be corrected by turning off the blocking things. And you also need to be really aware of what the blocking packages are doing to your firewall configuration and know exactly what it takes to truly disable the package. One example is the link between pfBlockerNG-devel, its DNSBL feature, and the critical
unbounddaemon in pfSense. Ifunboundis not working, then very little with your Internet connection will work.In the case of Snort or Suricata, simply turning off the service will not remove existing blocks. You will also need to go to the BLOCKS tab and clear all blocked IP addresses there. So all of these blocking packages can cause you trouble in several different ways. And removing them from the troubleshooting tree is usually not as simple as just disabling them. They make changes in other parts of the firewall configuration that take other manual action to revert.
-
@bob-dig said in after suricata 5.0.4_1 Update, suricata is no longer active:
Also, nobody else seem to have this problem.
YES, hassle-free for us, and I agree with the words before me...
if I know well you are in the EU, me too., so that is a good guide
-
I disabled all I could find of pfBlocker, but still... Next try will be uninstalling it.
Uninstalling also didn't helped.
So last thing I changed was my ISP, back to my old one. That snort rules where a matter of seconds...
With switching ISP I also disabled IPv6. I checked before that IPv6 worked in general, at least from the WAN Interface.
So maybe my new ISP IP or whole range is blocked (Deutsche Telekom) or it is somewhat of an IPv6 problem, can't tell for sure. -
@bob-dig said in after suricata 5.0.4_1 Update, suricata is no longer active:
(Deutsche Telekom
Hmmm T-Com
try only through IPv4 gateway
-
If it's an IPv4 <> IPv6 issue, like the IPv6 peering of your ISP isn't working as well as IPv4, you could try the new pfBlockerNG-devel-3.0.0.6 Python mode No-AAAA facility : list the URL's that should be accessed using IPv4 only.
Normally, you would know it's an IPv6 issue : the URL used by pfBlockerNG to download a feed should also work using a browser. A browser pluging will tell you if it's using IPv4, or IPv6, if IPv4 is also available, if IPv6 is also available.
No DNSSEC - using Ipv6 - the browser didn't even ask for an IPv4 :
IPv6 used, IPv4 available (and or the site uses other pages that are IPv4 only) :
Btw : shutting down pfBlockerNG, and force reloading it ( ! ) should be enough, as pfBlockerNG wouldn't place firewall rules any more, wouldn't 'instruct' unbound with an URL list, and wouldn't activate Python mode : pfBlockerNG will not interfere with any DNS transactions : at that moment, it's neutral. If only de installing pfBlockerNG would help then that's a real bug.
But normally, it's not the package. It's the settings. -
Today I took a look and saw this.
Hadn't any time to test anything before but now I did by just going to the snort site in my Browser, logging in and downloading the snort rules. With the new ISP [Deutsche Telekom AG], download was fast in the beginning and then again became very very slow and took minutes to finish, but it did finished at least.
I then switched the gateway in pfSense to old ISP [Pyur/Tele Columbus AG], cleared the Browsercache and did the same thing again, it was a matter of seconds. All tests where done with IPv4 only.So in the end I can only suggest one thing: to decouple the update of the Suricata package from the update of the rulesets. Then Suricata wouldn't be stopped and it would be more clear where the problem is coming from, although the installation log is very clear in that regard, still the consequences are harder then they should be in my opinion.
Thanks for reading.
-
@bob-dig said in [solved, ISP-peering-problem] after suricata 5.0.4_1 Update, suricata is no longer active:
With the new ISP [Deutsche Telekom AG], download was fast in the beginning and then again became very very slow and took minutes to finish, but it did finished at least.
I then switched the gateway in pfSense to old ISP [Pyur/Tele Columbus AG], cleared the Browsercache and did the same thing again, it was a matter of seconds.Hi,
You make it clear for yourself that, things will change after you change your ISP GW.
So isn't this a pfSense issue?
-
@daddygo No, I use the new ISP all the time and they are known for there bad peering (customers are hostages) but I had no real problem until with the snort rules. But I guess, it can happen to everyone (with a bad ISP). I don't even think that it is the snort guys anymore, but still they could. Will try another DSL-ISP with a friend.
-
@bob-dig said in [solved, ISP-peering-problem] after suricata 5.0.4_1 Update, suricata is no longer active:
and they are known for there bad peering (customers are hostages)
if you have a chance to escape, please
(ISP)useful readings:
https://www.theregister.com/security/
https://www.expressvpn.com/blog/5-bizarre-edward-snowden-tweets/ -
@daddygo No chance, two years bound. My cable internet ISP before was even worse, not with peering, but had regular hiccups all the time.
-
@bob-dig said in [solved, ISP-peering-problem] after suricata 5.0.4_1 Update, suricata is no longer active:
No chance, two years bound.
I love Germany / Berlin..... (Berlin Techno, Trance, etc), I have been there a lot and my relatives live there.
I’m sorry for this stupid situation, there are always such ISPsYou tried to drive the traffic directly through a VPN, (e.g. ExpressVPN, they have good Berlin servers)
-
Had another "incident", wanted to download a small app named ZenTimings, which is hosted on: amazonaws.com
It is only 516KB, but with Deutsche Telekom, you almost can't download it, switching to other ISP or VPN, no problem.Damn, I regret.
@DaddyGo I don't want to route everything through a VPN, maybe I have to.
-
I was able to verify this 100%, that this is a peering problem of Deutsche Telekom, other ISP using the same Line, like 1&1, don't have this problem. The Download starts and then gets terrible slow, but there is no disconnect or reject , which make things even worse I think. But also there is a time frame where it does work, I think to the beginning of every day, there seems to be some kind of counting going on and then peering will become miserable again. So you could think that maybe pfBlocker was the reason, but in reality, it is the time of day.
Just to let you know.
-
@bob-dig said in [solved, bad peering from Deutsche Telekom] after suricata 5.0.4_1 Update, suricata is no longer active:
Just to let you know.
So, as I see it, it’s not just your problem and it’s not today’s thing.
f.e.: https://www.reddit.com/r/de_EDV/comments/agor82/grausames_peering_bei_der_telekom_update/
https://www.teltarif.de/forum/s80229/peering-ist-ein-erhebliches-groesseres-problem/1.htmlI think you need to choose a good VPN provider, Nord or Express VPN I have a lot of experience with them and .... - a little privacy it won't hurt anyone.
if you're worried about the speed, I'll tell you....
for example, ExpVPN - in PT
ISP 1000/500 FTTH
pfSense, Supermicro EPYC 3151 with LOM 4 pcs. Intel I350
the established VPN speed: D 670 - 720 / U 370-400 it is enough for everything.PS:
bufferbloat A++ -
To make things worse, or better : a "peering" issue can be cut in half, or doubles : Wha(s been seen before : our ISP all trying to propose their 'IPv6' - none of them actually read the reaRFC : they made something up that looks like an IPv6 RFC.
So, if you have IPv6 : stop it, reboot everything, check that's it is gone, and try again.Guess what happens when an ISP uses IPv6 - and implements it badly (many do so) : you think you can't access resources any more because their IPv6 peering is plain bad.
Our their iPV6 implementation is plain bad.
Or both.Start to check with what one might "presume working Ok" : IPv4 only.
If an ISP has bad peering - or blocks networks like "amazonaws.com" then I really would like to know : that info wasn't knows before ? You really want to use an ISP that blocks hostnames like that ? I understand, one can find tonnes of pure BS on "amazonaws.com" - it's just up to us not to go there .... If your ISP start to "pfBlockerNG' over your head, I would advise to leave them.
And before choosing another ISP : But document yourself about a new choice first. Remember : "money" is not an issue - but "not much' won't bring you much. .
And never read their own advertisement.Btw : a bad IPv6 implementation or peering can be redone on your side : join he.net.
Or VPN out.
By default : leave your ISP. -
Discussion continues here.
