Hohe Latenz und Paketverlust
-
Etwas OT, wir hatten in den letzten Wochen immer wieder den Fall das einer unserer Telekom Anschlüsse über AT/Wien geleitet wurde, die Laufzeit war dann bis zu 300ms und die Leitung quasi nicht benutzbar.
Das ganze war sporadisch vorhanden, dann war das Routing wieder ok und ein paar Tage ging das wieder los, war gut mit traceroute zu sehen.
Spannend war auch das es immer nur einen von zwei VDSL Anschlüssen betroffen hat.
-
@slu said in Hohe Latenz und Paketverlust:
Etwas OT,
Nein, passt doch.
wir hatten in den letzten Wochen immer wieder den Fall das einer unserer Telekom Anschlüsse über AT/Wien geleitet wurde, die Laufzeit war dann bis zu 300ms
Das würde ich mir nicht mal erwarten, wenn es per VPN über Tokyo läuft... -
ja das war nicht lustig, muss aber dazu sagen das zwei ISP beteiligt waren, daher ist es für mich schwierig zu sagen wer jetzt am schlechten Peering schuld war...
-
-
@Bob-Dig
ich kann dir das nicht sicher sagen, die Strecke war purISP DE - Level3 (Wien) - Telekom DE.
Die 300ms entstanden wenn ich mich richtig erinnere zwischen Level3 und der Telekom. -
Kannst ja, wenn das auftritt mal ein Tool wie Pingplotter verwenden, das zeigt dir dann wo genau es klemmt.
Sehe da eher ein Provider Problem.
-
Hallo zusammen,
sorry, dass ich erst jetzt wieder antworte. Inzwischen konnte ich das Problem weiter eingrenzen.
Es sind tausende solcher DNS-Anfragen, die das Netz lahmlegen.
Habe festgestellt, dass die Anfragen vom DNS-Server eines Windows-Servers in einer per VPN verbundenen Niederlassung kommen. Sobald ich den DNS-Server dort beende, normalisieren sich Latenz und Paketverluste wieder.
Auf dem betroffenen Windows-Server habe ich aber keine Schadsoftware gefunden, daher stellt sich nun die Frage, woher dieser die Anfragen bekommt.
Hier sieht man noch gut, wie die DNS-Server mit den Anfragen offenbar Ping Pong spielen.
Vielleicht hat jemand so etwas ja schon mal gesehen.
Vielen Dank und beste Grüße
-
Kann ein Client sein der den Server im Standort anfragt.
Mit einer Überschrift bei den Zeilen könnte man das besser interpretieren.
Das ist einer der Gründe, warum ich jeglichen DNS Datenverkehrt auf meine pfSense umbiege, so frage ich nur einmal im WAN und dann greift der Cache.
Aber warum fragt der Server nicht deine pfSense, sondern er will direkt im Iet anfragen?
Wie hast du das Forwarding für DNS gelöst? -
Wir haben heute wieder massive Latenz und Paket Verlust, evtl. gehen deine DNS Anfragen verloren und werden wiederholt?
Stand 12.01.2024 ~ 9:18 Uhr ein Ping über einen OpenVPN UDP Tunnel von der einen pfSense auf die andere:
PING 192.168.12.1 (192.168.12.1) 56(84) bytes of data. 64 bytes from 192.168.12.1: icmp_seq=1 ttl=63 time=102 ms 64 bytes from 192.168.12.1: icmp_seq=4 ttl=63 time=103 ms 64 bytes from 192.168.12.1: icmp_seq=5 ttl=63 time=98.8 ms 64 bytes from 192.168.12.1: icmp_seq=7 ttl=63 time=91.6 ms 64 bytes from 192.168.12.1: icmp_seq=10 ttl=63 time=91.3 ms 64 bytes from 192.168.12.1: icmp_seq=13 ttl=63 time=89.1 ms 64 bytes from 192.168.12.1: icmp_seq=14 ttl=63 time=89.5 ms 64 bytes from 192.168.12.1: icmp_seq=15 ttl=63 time=92.7 ms 64 bytes from 192.168.12.1: icmp_seq=16 ttl=63 time=91.6 ms 64 bytes from 192.168.12.1: icmp_seq=17 ttl=63 time=82.6 ms 64 bytes from 192.168.12.1: icmp_seq=18 ttl=63 time=94.9 ms84 packets transmitted, 59 received, 29.7619% packet loss, time 83519ms rtt min/avg/max/mdev = 29.509/78.218/143.459/27.896 ms -
Als zweite Grafik wollte ich oben eigentlich die hier einfügen:
-
@NOCling said in Hohe Latenz und Paketverlust:
Kann ein Client sein der den Server im Standort anfragt.
Mit einer Überschrift bei den Zeilen könnte man das besser interpretieren.
Das ist einer der Gründe, warum ich jeglichen DNS Datenverkehrt auf meine pfSense umbiege, so frage ich nur einmal im WAN und dann greift der Cache.
Aber warum fragt der Server nicht deine pfSense, sondern er will direkt im Iet anfragen?
Wie hast du das Forwarding für DNS gelöst?Wir haben zwei Standorte mit jeweils einer pfSense und jeweils einer eigenen Windows-Domäne.
Auf beiden pfSense sind die DNS-Forwarder gleich konfiguriert:
Also eigentlich nur die Standard-Einstellungen.
An beiden Standorten läuft dann noch der DNS-Server auf den DCs.
Besten Dank für die Unterstützung!
-
@ShaneDeak
DNS-Forwarder aktiviert und in den General Settings steht dann ausschließlich der lokale DNS Server?Dann sollte eigentlich absolut nix über die VPN laufen.
Die Anfragen deuten jedenfalls auf eine Malware hin. Also solltest du lokal rausfinden, von welchem Client sie kommen und diesen erst mal kalt stellen.
-
@viragomann said in Hohe Latenz und Paketverlust:
DNS-Forwarder aktiviert und in den General Settings steht dann ausschließlich der lokale DNS Server?
Ich habe zwei WAN-Gateways und in den General Settings für jedes Gateway einen externen DNS-Server eingetragen. Ist das nicht richtig so?
-
@ShaneDeak
Nein. Das zwingt einen Request über das angegebene Gateway.
Ein Gateway ist da nur einzutragen, wenn der angegebene DNS ausschließlich über dieses zu erreichen ist. Bspw. der DNS Server des Internet-Providers.ABER noch einmal:
Du hast einen internen DNS Server. Dieser sollte doch auch genutzt werden. Und DNS Lookups sollte doch dann ausschließlich dieser machen.
Dann konfigurierst du doch am besten alle Geräte so, dass sie direkt diesen Server abfragen. Das kannst du auch per DHCP an die Geräte verteilen.Ein Forwarder auf der pfSense ist dann gar nicht nötig. Aber wenn, dann sollte in General Setup der interne DNS Server eingetragen sein, damit die Anfragen dahin weitergeleitet werden.
Auf der pfSense kannst du dann noch per Filterregel nur dem DNS Server Lookups nach draußen erlauben.
-
@viragomann
Die pfSense ist der DHCP und dort übergebe ich auch den internen DNS-Server an die Geräte. Jetzt habe ich auch im General Setup nur noch den internen DNS, ohne Gateway-Zuweisung, eingetragen.Danke!
-
Würde den AD Server an die Clients als DNS raus geben, im AD aber die Sense als forwarding hinterlegen.
Die Sense dann als reinen Resolver mit Cache laufen lassen.So hast du eine saubere Struktur.
Aber ja, könnte was unerwünschtes sein, was auf einem Client ausgeführt wird.
-
@NOCling said in Hohe Latenz und Paketverlust:
Würde den AD Server an die Clients als DNS raus geben, im AD aber die Sense als forwarding hinterlegen.
Die Sense dann als reinen Resolver mit Cache laufen lassen.So hast du eine saubere Struktur.
Aber ja, könnte was unerwünschtes sein, was auf einem Client ausgeführt wird.
Genau das.
Ordentlich rekursive Struktur vom Gerät direkt am Internet nach unten. Wenn interner DNS dann gern den nutzen, der macht dann aber kein Forward irgendwo hin sondern schickt an die Sense und die schickts raus - ggf. als Resolver wegen ordentlich dezentral und Co.
Ansonsten verweise ich da mal an https://malwaretips.com/blogs/remove-s-thebrighttag-com/ wo das Thema u.a. behandelt wurde, dass das als AdFarm auch malicious gern irgendwo injected wird - also sehr ungeil wenn man das so oft im Log sieht, da würde ich aber schonmal den DNS Block auf der Sense reinkloppen und ordentlich die Clients am Standort abfarmen, wer sich da Murks eingetreten hat.
Ansonsten bei DNS immer möglichst hierarchisch arbeiten. Wenn man eine simple interne Domain hat, kann man auch direkt die Sense als DNS an die Clients geben und macht nur nen Domain override für die DC Domain, aber prinzipiell sollte die Sense das letzte Glied vor dem Internet sein, damit man da ggf. mit pfB nochmal filtern kann um solchen Mist rauszuwerfen. :)
Cheers
-
Ich konnte den infizierten Client ausfindig machen und habe nun keine Probleme mehr.
Die Tipps zur DNS-Struktur werde ich auf alle Fälle noch umsetzen! Vielen Dank allen für die Unterstützung!
-
Dann auch mal einen Blick auf pfBlockerNG werfen und hier ggf. die Firehole 1 und ggf. auch 2 einbauen.
Das hält dann schon mal das eine oder andere Böse auf Distanz. -
@NOCling
Das würde aber die Nutzung des DNS Resolvers auf der pfSense voraussetzen. Im Forwarder-Betrieb, wie aktuell, hilft das nicht.
