Cope bad peering of ISP Deutsche Telekom
-
Network noob here,
as discussed here, five days ago I got me a new ISP (Deutsche Telekom). This ISP does really bad peering and that makes problems, for instance with downloading the snort-subscriber rules, the download never finishes. Maybe pfBlocker feeds are also affected, can't tell.
I can use a VPN to circumvent that behavior for my daily browsing routines and I already used one before with pfSense, but what I don't want to do is making the vpn the default gateway of pfSense.@DaddyGo and others.
So how can I solve this just for pfSense itself (Suricata Snort-rules), without using a vpn as the default gateway. Maybe with static routes or NAT on the WAN-interface? Any in-depth help would be appreciated. I don't know much about NAT and did policy routing only on LAN before. -
MTU issue?
Test download URL? I have access to ~30 Sites with Deutsche Telekom to check.-Rico
-
@rico said in Cope bad peering of ISP Deutsche Telekom:
MTU issue?
Test download URL? I have access to ~30 Sites with Deutsche Telekom to check.So I noticed it myself with the snort subscriber rules, you can test this yourself, if you have a snort account (for example snortrules-snapshot-29161.tar.gz).
I also have found problems with a small tool (500KB) hosted on AWS, but right now I can download it fast so sharing the url doesn't make sense. Yesterday evening the download coudn't finish at all.Also what I noticed since having the new ISP, the thinkbroadband quality monitor is showing much blue for 12 hours.
-
@bob-dig said in Cope bad peering of ISP Deutsche Telekom:
you can test this yourself, if you have a snort account (for example snortrules-snapshot-29161.tar.gz).
This is clearly a problem....
what does a traceroute point to snort.org?
there is no problem for us with this, I just tried:
have you tried this?
https://kb.netgear.com/19863/Ping-Test-to-determine-Optimal-MTU-Size-on-Router -
@daddygo said in Cope bad peering of ISP Deutsche Telekom:
what does a traceroute point to snort.org?
Shows not much I think, but dl speed defers drastically
@daddygo said in Cope bad peering of ISP Deutsche Telekom:
have you tried this?
https://kb.netgear.com/19863/Ping-Test-to-determine-Optimal-MTU-Size-on-RouterNo, because everything else is working as expected, it is a peering problem at least to AWS.
So guys, what to do in practice?
-
@bob-dig said in Cope bad peering of ISP Deutsche Telekom:
So guys, what to do in practice?
this will be hard to circumvent with NAT and things like that...
as I understood the German articles on the theme...
Deutsche Telekom is misbehaving with large network traffic suppliers "players" such as Hurrican Electric, AWS, etc.
open a ticket with measurements evidence and if they can't help you will have a reason to get rid of it
https://www.peeringdb.com/net/196
-
@daddygo said in Cope bad peering of ISP Deutsche Telekom:
this will be hard to circumvent with NAT and things like that...
Couldn't I use pfBlocker to create an alias for AWS and then selectively route this through a vpn (on WAN though) or create a static route for that somehow?
-
What do you mean by "peering". That's where carriers and ISPs meet to exchange data. For example, my ISP peers at the Toronto Internet Exchange. You mention AWS, but unless they have a point of presence at the same location as your ISP, they're not peering.
-
You can try to do that. If you can make an alias of all of AWS you can static route it via a VPN gateway. That will apply all traffic including any client traffic not policy routed.
Steve
-
@bob-dig said in Cope bad peering of ISP Deutsche Telekom:
Couldn't I use pfBlocker to create an alias for AWS
but yes, you only have to do this with all the intermediate network players
it would be a horror job and you donโt know when your packages will travel and which route
f.e.:
in the EU travels a lot of package on the HE networkBTW:
Telekom is also in a bad relationship with them+++edit:
like you said you don't just notice this problem towards AWS....(?!) -
@stephenw10 said in Cope bad peering of ISP Deutsche Telekom:
You can try to do that. If you can make an alias of all of AWS you can static route it via a VPN gateway. That will apply all traffic including any client traffic not policy routed.
Steve
Thanks steve, but where to "put" it. It should be used at least by Suricata and pfBlocker.
-
Add is as a static route in Sys > Routing > Static Routes.
It might get ugly with an alias that tries to include all of AWS as that will be huge. Your routing table will end up.... large!
There is no way to policy route traffic from the firewall itself so it will apply to all traffic that isn't otherwise policy routed.
Steve
-
@stephenw10 I checked with a rule on lan, worked flawlessly with the snort rules download.
That table I created has 2,055 records though...
How could I do that or at least test it on "wan"? Is it doable in the gui?
I can't load these pfBlocker Aliases under System/Routing/Static Routes.@DaddyGo To be clear, I want to get rid of them asap, but I signed a two year contract...
-
@bob-dig said in Cope bad peering of ISP Deutsche Telekom:
How could I do that or at least test it on "wan"? Is it doable in the gui?
I can't load these pfBlocker Aliases under System/Routing/Static Routes.For the lols I guess, I tried this, but also wasn't working:
I do have a VPS though and routing it there seems to be a viable solution. But I have configured it to connect to me and not the other way around and I am somewhat noobish when it comes to my own OVPN-installations, so the firewall itself will be the last to have internet.
-
@jknott said in Cope bad peering of ISP Deutsche Telekom:
You mention AWS, but unless they have a point of presence at the same location as your ISP, they're not peering.
Ok, then I meant routing because of bad peering or just bad routing in general.
-
Yeah, it would need to actually route to it using a static route. Outbound NAT does not route traffic.
You're right though, you can't use a URL alias in a static route. Which is reasonable since adding 2055 routes to the table would be.... ugly at best!
Steve