[solved, bad peering from Deutsche Telekom] after suricata 5.0.4_1 Update, suricata is no longer active

DaddyGo

@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

Gertjan

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.

Bob.Dig

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.

DaddyGo

@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?

Bob.Dig

@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.

DaddyGo

@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/

Bob.Dig

@daddygo No chance, two years bound. My cable internet ISP before was even worse, not with peering, but had regular hiccups all the time.

DaddyGo

@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 ISPs

You tried to drive the traffic directly through a VPN, (e.g. ExpressVPN, they have good Berlin servers)

Bob.Dig

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.

Bob.Dig

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.

DaddyGo

@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.html

I 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++

Gertjan

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.

Bob.Dig

Discussion continues here.