RDSH Verbindungsabbrüche

[illumina7 3]

Moin zusammen,

 

ich hab ein großes Problem in meiner neuen Serverumgebung und langsam weiß ich nicht mehr wirklich weiter.

Kurz zur Umgebung:

- 2 identische Supermicro Server mit folgender HW:

      2x Epyc 7302

      256GB Ram

      Supermicro H11DSi-NT Mainboard

      Adaptec SmartRaid 3154-8i

      7x INTEL SSDSC2KG960G8 im Raid10 (6 + Hotspare)

      Intel X710-DA2

      Nvidia Quadro P1000 (f. RemoteFX)

      Windows Server 2016 ENT als Hyper-V Host

      Switchunabhängiges Teaming für die 2x1GBit NICs (Windows)

- 3 Standorte

      Hauptstandort: Sophos XG210 mit 3 Leitungen: 

          dedizierte EtherConnect Leitung ohne Zugriffsmöglichkeit

          Tsystems 100/40 Leitung, feste IPv4, bintec rs353jv hängt am Anschluss

          Vodafone Business 500/60 Leitung, feste IPv4, derzeit hängt die Vodafone Box dran, eigentlich Fritzbox 6660 Cable

          ca. 50 Mitarbeiter intern

          Hier stehen die beiden Server

          Site-to-Site IPSec Tunnel über Vodafone <-> Vodafone mit Standort B, Tsystems Leitungen als Failover konfiguriert

          Netzwerktopologie sieht folgendermaßen aus:

          Beide Server und sonstige Netzwerkressourcen hängen an einem neuen Netgear 48Port GBit Switch, an diesem hängen mehrere HPE Switches sternförmig, an denen wiederum alle Clients verteilt hängen.

      Standort B: Sophos XG135

          dedizierte EtherConnect Leitung ohne Zugriffsmöglichkeit

          Tsystems 100/40 Leitung, feste IPv4, bintec be.ip hängt am Anschluss

          Vodafone Business 500/60 Leitung, feste IPv4, derzeit hängt die Vodafone Box dran, eigentlich Fritzbox 6660 Cable

          ca. 20 Mitarbeiter

         1 Dlink DGS-1210-48, für 20 PCs und 5 Drucker/Kopierer

       Standort C: Sophos XG135, ist aber noch nicht vollständig angebunden

          mit der Anbindung muss ich auch warten, bis wir den Fehler finden können.

          ca. 50 Mitarbeiter

 

Die beiden Server replizieren die VMs über die 2x10Gbit (dediziert), insgesamt laufen über beide Hosts verteilt 18 VMs, allesamt Server 2019 ENT.

Alle User arbeiten in einer Terminalserverumgebung, bestehend aus 4 RDSH (max. 25 User pro RDSH) und 1 Broker.

Um den ganzen etwas Geschwindigkeit zu verleihen, haben die RDSH jeweils die Quadro für RemoteFX Beschleunigung aktiviert, ich weiß das Feature ist abgekündigt, allerdings muss ich das nutzen, bis das GPU-P Feature endlich nachgepatcht wird.

Auf den RDSH wird fast ausschließlich in gehosteten Web-Anwendungen und mit Office gearbeitet, zusätzlich werden Zoom und Teams Meetings in den Sitzungen abgehalten (hierfür die WVD VDI Optimierungen eingespielt), intern haben wir Sfirm und noch zwei andere SQL Server basierte Anwendungen laufen.

Alle RDSH VMs haben folgende Ressourcen: 8 vCPUs, 32GB Ram, 100GB VHD, 1 NIC zum vSwitch, die User arbeiten mit Profildisks. Es steht ein Fileserver für die Profildisks zur Verfügung, ein zweiter Fileserver für die SMB Shares (je 2 vCPUs, 6GB Ram).

Am Serverstandort können alle User absolut problemlos arbeiten, Geschwindigkeit ist wie wenn man lokal auf einem Rechner arbeiten würde, zum Teil auch mit 2 Bildschirmen in den RDP Sessions, läuft wie es soll.

 

Am Standort B ist es über VPN eine Katastrophe, immer wieder friert die Anzeige ein oder die Benutzer bekommen reihum RDP Session Timeouts, müssen einige Minuten warten, bis wieder eine Verbindung hergestellt werden kann. Hier taucht auch hin und wieder mal die Meldung "Ein interner Fehler ist aufgetreten" auf.

An manchen Tagen läuft es aber auch hier richtig flott und problemlos, praktisch der Idealzustand, wobei selbst da hin und wieder einzelne User mal rausfliegen, während alle anderen nichts davon mitbekommen.

Allerdings ist es so - während die Verbindung zu den RDSH Hosts abbricht, kann ich parallel per RDP auf den anderen Servern weiterarbeiten - dort ist auch die Geschwindigkeit wesentlich besser, obwohl die dann zum Teil auf dem gleichen Host liegen.

 

Auf einem 3. Server, Backup und Testserver, alter Fujitsu RX200 S7 (Dual E5-2640, 64GB DDR3, Intel Server SSDs Raid5, Server 2019 Ent, hängt am gleichen Switch, Windows NIC Teaming aktiviert), habe ich auch die Hyper-V Rolle installiert und einen bestehenden Terminalserver geklont, diesen dann in eine eigene Sammlung verschoben und nur für mich zum Testen bevor die Änderungen ins Produktivsystem gehen, läuft auch alles bestens. Sprich: Ich fliege via VPN vom Produktiv-RDSH raus, aber kann parallel auf dem Test-RDSH ohne irgendwelche Probleme weiterarbeiten - auch richtig performant.

 

Was wir schon (zusammen mit dem Dienstleister der die Sophos Firewalls eingerichtet hat) zwecks Fehlersuche unternommen haben:

- alle Router getauscht -> keine Veränderung

- mehrmals Internetleitungen geprüft (Vodafone und Tsystems) -> keine Veränderung

- Unter Windows Server das Teaming aufgelöst -> keine Veränderung

- RSC und VMQ für die RDSH deaktiviert -> keine Veränderung

- alle Server/Switch/Firewall Netzwerkkabel an beiden Standorten getauscht -> keine Veränderung

- mit dem Sophos Support alle Logfiles auf Fehler geprüft -> nichts gefunden

- Intel Netzwerktreiber aktualisiert -> keine Veränderung

- Supermicro UEFI Update eingespielt -> keine Veränderung

- Supermicro Chipsatztreiber etc. aktualisiert -> keine Veränderung

- die Sophos XG210 gegen eine Leih-XG230 getauscht -> keine Veränderung

- RDSH VMs zwischen den Hyper-V Hosts migriert -> keine Veränderung

- Netzwerkperformance mit diversen Tools getestet -> alles bestens

   (vServer-Client, Client-vServer, vServer-vServer, Host1-Host2, Host1-vServer, Host2-vServer, etc. also jegliche mögliche Kombination)

- Raid Array Performance geprüft -> r/w top, nichts auffällig

- an manchen Tagen funktioniert die Verbindung über Tsystems-Tsystems gut, am nächsten Tag funktioniert es nur über Vodafone-Vodafone, die Woche darauf geht überhaupt nichts mehr, bis ich den Site-to-Site Tunnel auf Telekom-Vodafone umgestellt habe.

- Ereignisprotokolle ohne Ende gewälzt, versucht den Fehler auf dem Test-RDSH zu reproduzieren - bisher erfolglos, es sind keine offensichtlichen Fehler auf dem Broker und den RDSH zu finden.

EDIT:

- Site-to-Site Tunnel ist immer stabil und verbunden, egal über welche Leitung, aber im Tunnel selbst haben wir schon Paketverluste -> niemand weiß wirklich warum

   der Dienstleister schiebt es auf die Vodafone Leitungen, die Vodafone Leitungen sind mehrfach geprüft und iO, auch über die Telekom Leitungen treten die Paketverluste im Tunnel auf, ich tippe nach wie vor darauf, dass an den Firewalls irgendwas nicht stimmt.

   So drehen wir uns seit ca. 2 Monaten im Kreis und langsam aber sicher wird mein Chef ungeduldig.

 

EDIT2:

- Im Zuge der Fehlersuche habe ich festgestellt, dass Winserver sich mit Firewall Regeln der User zumüllt und nicht mehr löscht, die alten Regeln hab ich gelöscht (insgesamt knapp 10k verwaiste FW-Einträge) und das ganze per Registry Eintrag abgeschaltet -> keine Veränderung

- Alle Clients sind Win10 Pro Clients mit 20H2 und 21H1, alle Clients sind in der Domäne

- Wir nutzen derzeit nur Windows Defender und die Windows Firewall, keine Software von einem Drittanbieter, zusätzlich filtert und prüft die XG210 den Traffic ins Internet, intern gibt es keine Restriktionen.

- Fair Share CPU Scheduling, Dynamic Disk Fair Share und Dynamic Network Fair Share per Reg Eintrag deaktiviert -> keine Veränderung

 

Irgendwie stecke ich eben in einer Sackgasse fest, wir haben bestimmt noch das ein oder andere mehr probiert, das ergänze ich wenn es mir wieder einfällt.

 

Über einen Tipp oder Denkanstoß würde ich mich sehr freuen.

Bei Fragen einfach fragen.

 

Grüße

illumina7

 

      

bearbeitet 29. September 2021 von illumina7

[winmadness 78]

Evtl. helfen Dir meine Erfahrungen mit VPN Verbindungen weiter. Konfiguration: VPN mit IPSec / IKEv2, OPNSense als VPN Server, Windows 10 als VPN Clients, Internet Provider Vodafone und Telekom im Home Office. Fehlerbild: manche Tage ohne Probleme, andere Tage mit Programmabstürzen bzw. VPN Verbindungsproblemen.

Bei uns lag es an IPv4 über Dual Stack (Lite). Nachdem die VPN Verbindung über IPv6 aufgebaut wird haben wir keine Probleme mehr.

[cj_berlin 1.129]

vor 23 Stunden schrieb illumina7:

 

- Site-to-Site Tunnel ist immer stabil und verbunden, egal über welche Leitung, aber im Tunnel selbst haben wir schon Paketverluste -> niemand weiß wirklich warum      

An dieser Stelle würde ich versuchen, RDP komplett nur über UDP zu fahren. Da haben Paketverluste zwar Audio-/Video-Artefakte zur Folge, aber die Stabilität der Sitzungen dürfte weniger von Paketverlusten beeinträchtigt sein.

vor 23 Stunden schrieb illumina7:

 

Auf einem 3. Server, Backup und Testserver, alter Fujitsu RX200 S7 (Dual E5-2640, 64GB DDR3, Intel Server SSDs Raid5, Server 2019 Ent, hängt am gleichen Switch, Windows NIC Teaming aktiviert), habe ich auch die Hyper-V Rolle installiert und einen bestehenden Terminalserver geklont, diesen dann in eine eigene Sammlung verschoben und nur für mich zum Testen bevor die Änderungen ins Produktivsystem gehen, läuft auch alles bestens. Sprich: Ich fliege via VPN vom Produktiv-RDSH raus, aber kann parallel auf dem Test-RDSH ohne irgendwelche Probleme weiterarbeiten - auch richtig performant. 

Hat diese Büchse auch eine GPU und die RemoteFX-Vorbereitung?

[illumina7 3]

vor 29 Minuten schrieb winmadness:

Evtl. helfen Dir meine Erfahrungen mit VPN Verbindungen weiter. Konfiguration: VPN mit IPSec / IKEv2, OPNSense als VPN Server, Windows 10 als VPN Clients, Internet Provider Vodafone und Telekom im Home Office. Fehlerbild: manche Tage ohne Probleme, andere Tage mit Programmabstürzen bzw. VPN Verbindungsproblemen.

Bei uns lag es an IPv4 über Dual Stack (Lite). Nachdem die VPN Verbindung über IPv6 aufgebaut wird haben wir keine Probleme mehr.

Danke für deinen Hinweis bezüglich Dual Stack. Habe das jetzt nochmal in der Tarifbeschreibung nachgelesen und folgendes gefunden:

Dualstack

Vodafone stellt die statische IPv4-Adresse per reinem IPv4 zur Verfügung (kein IPv6-Support/Präfix). Die Bereitstellung der dynamischen IP-Adressen erfolgt mit gleichzeitiger Unterstützung von IPv4 und IPv6 (Dual Stack).

Als Business Kunde sollten wir mit der statischen IPv4 also grundsätzlich keinen DS (Lite) Anschluss haben.

 

vor 9 Minuten schrieb cj_berlin:

An dieser Stelle würde ich versuchen, RDP komplett nur über UDP zu fahren. Da haben Paketverluste zwar Audio-/Video-Artefakte zur Folge, aber die Stabilität der Sitzungen dürfte weniger von Paketverlusten beeinträchtigt sein.

RDP läuft schon komplett via UDP, nur testweise hatte ich es an meinem Arbeitsplatz auf TCP umgestellt - allerdings mit sehr mäßigem Ergebnis - es ist einfach sau lahm.

Ich habe gestern Nacht, nach langer Recherche im Sophos XG Forum noch etwas gefunden: die IPS der Sophos blockiert u.a. UDP Pakete oder verwirft sie komplett, habe dann eine Ausnahme für die Terminalserver gesetzt, heute flutscht es richtig. Bis jetzt auch noch kein Disconnect/Abbruch, aber das muss noch nicht unbedingt etwas heißen, wir hatten durchaus schon Tage an denen es richtig gut funktioniert hat.

[winmadness 78]

vor 28 Minuten schrieb illumina7:

Als Business Kunde sollten wir mit der statischen IPv4 also grundsätzlich keinen DS (Lite) Anschluss haben.

Evtl. noch einmal nachfragen bzgl. Dual Stack bzw. evtl. auch mal Anbindung über IPv6 testen. Wir hatten mit IPv4 bei beiden Anschlussarten Probleme - Dual Stack und Dual Stack Lite.

[illumina7 3]

Also RDP lief gestern den ganzen Tag super flott auf fast allen Arbeitsplätzen, nur an 2 PCs am Standort B trennt es immer mal wieder die RDP Session.

Den einen PC hatte ich letzte Woche sauber neu installiert mit Win10 (inkl. Treiber und Updates), es sind alles die identischen Fujitsu PCs im ganzen Haus, denke nicht, dass es irgendwie an der Hardware liegt. Der Dlink Switch meldet auch keine Fehler auf den Leitungen.

Heute Nachmittag möchte ich die XG135 am Standort B durch die eine alte SG105 ersetzen und schauen wie es dann kommende Woche aussieht, mit der SG105 lief das alles tiptop vorher.

Der Fehler macht mich noch wahnsinnig, wenn an Standort A auch alle ständig Verbindungsabrüche hätten, dann könnte ich das auf die Server bzw. RDSH-Farm schieben, aber dort läufts echt überragend gut, selbst wenn hier 20 Leute ein Zoom Meeting in der Session abhalten läuft das ohne Probleme.

Der Fehle wäre auch einfacher zu suchen, wenn an Standort B absolut alle die Abbrüche hätten, aber immer sporadisch einzelne Arbeitsplätze und auch nicht immer die gleichen.

Mit Wireshark und dem Packte Tracking der Sophos konnte ich gestern übrigens nichts feststellen, allerdings trat in dem Zeitraum auch nichts auf.

[MurdocX 903]

Habt Ihr in der Sophos die Flood-Protections an? Intrusion prevention > DoS attacs

 

Zum Thema XG könnte man jetzt ein Fass aufmachen... Ich belass es mal bei: Wenn du mit deiner SG-UTM zufrieden bist, dann spare dir den Umstieg auf die XG.

 

IPS - Ein Tipp eines Support-Technikers -> Keine default Regeln verwenden. Stattdessen:

• Critical - Maßnahme Sitzung verwerfen
• Major  - Maßnahme Sitzung verwerfen
• Moderate - vorgeschlagene Maßnahme
• Minor - vorgeschlagene Maßnahme
• Warning - vorgeschlagene Maßnahme
   

bearbeitet 1. Oktober 2021 von MurdocX

[illumina7 3]

Flood Protection ist an, aber nur für WAN -> LAN, auf der VPN ist keine IPS Regel gesetzt.

 

Ich hatte vorgestern noch zwei DoS Bypass Rules angelegt:

Von * nach NetzadresseStandortA 3389 TCP und UDP

 

Wir mussten die SGs rauswerfen, die waren zu klein dimensioniert für die Verlagerung auf die RDSH Server und auch schon ~6 Jahre alt.

Die XGs sollten eigentlich mehr als ausreichend sein, laufen auch fast nur im Leerlauf vor sich hin, aber irgendwie haben wir absolut nur Probleme damit.

Irgendwie hat unser Sophos Gold Partner auch nicht so den ultimativen Plan von den Kisten, habe jetzt schon einige falsch konfigurierte Einstellungen gefunden, die in der Dokumentation von Sophos anders drin stehen...

Und genau hier vermute ich irgendwo einen Fehler, leider sind die XGs für mich komplett neu und ich hab jetzt erst notgedrungen angefangen mich mit denen auseinanderzusetzen.

 

Default Regeln sind fast überall im Einsatz.

 

Hast du sonst noch einen Tipp bezüglich Sophos?

 

Mir ist gestern Nacht noch etwas komisches via Shell aufgefallen:

-> XG210 an Standort A hat ca. 10% dropped Packets RX auf LAN1 (interne Lan Schnittstelle, Switch zeigt aber 0 Errors auf dem LAN Port)

 

 

EDIT:

Mir ist eben noch aufgefallen, dass via SSL VPN die Datenrate auch extrem mies ist, komme beim SMB File kopieren auf 2-400 KB/s(!) und das bei einem eigentlichen Upload von 6-7 MB/s.

Der Remote VPN Zugang läuft auch auf der 210er.

EDIT2:

Eben SSL VPN über die XG135 getestet, hier kommen tatsächlich 6-7 MB/s dauerhaft an beim SMB Filecopy. Auf der 135 läuft sonst aber praktisch nichts außer dem VPN zwischen den beiden Standorten (Kein IPS/Filter/etc.).

bearbeitet 1. Oktober 2021 von illumina7

[MurdocX 903]

Schalte bei Dir testweise mal für einen Tag die Flood-Protection und IPS komplett ab und schau ob es sich verbessert. 

[illumina7 3]

Ips aus/anschalten verändert nichts. 

Ich bin mir auch ziemlich sicher, dass wir schon die volle Bandbreite im site2site hatten, das haben wir ja ursprünglich ausgiebig getestet. 

 

Ich hab jetzt an beiden Firewalls mit MTU und MSS rumgespielt, mit mtu 1460 und mss 1320 habe ich die volle Bandbreite im Tunnel und auch per SSL vpn. Ich lasse die Werte jetzt eingestellt und schau Sonntag nochmal was dann los ist.

Wenn im site2site nur 0,7-1MB/s ankommen, dann ist mir schon ziemlich klar, dass immer wieder einzelne RDP Sessions abreißen, das ist zu für 15 Sitzungen mit teilweise zwei FHD Monitore.

 

Noch eine Frage: hab noch etwas mit der flood protection getestet. Ist es normal, dass die nach Aktivierung erstmal so gut wie alles blockt? Sogar den ipsec Tunnel, bevor ich die WAN Ips in den Bypass eingetragen hab?

 

EDIT: Bin jetzt zwei Stunden später endlich zu Hause und habs trotzdem gleich getestet. Jetzt ist Performance wieder komplett weg, sowohl site2site als auch übern externen SSL Tunnel kommen wieder nur 0,3-1MB/s an. Die XG210 idlet vor sich hin, Bandbreite ist derzeit auch komplett ungenutzt. Ich denke mein Problem liegt irgendwo an der Sophos, nicht an der Windows/Serverumgebung.

bearbeitet 1. Oktober 2021 von illumina7

[illumina7 3]

Guten Morgen, 

zwar war hier jetzt sowieso nicht so viel los, aber vielleicht hat mal jemand ein ähnliches Problem und ist über mögliche Tipps zur Behebung dankbar.

 

Man mag es kaum glauben: die Sophos XG Appliances waren Schuld an den Abbrüchen, was ich von Beginn an vermutet hatte, aber das Systemhaus vehement abgestritten hat.

So richtig bewusst geworden ist mir das aber erst, als bei einem Packet Capture aufgefallen ist, dass die XGs die Pakete aus dem VPN Netz in der falschen Reihenfolge zusammengesetzt haben. Also die Pakete gingen korrekt raus, 1-2-3, die Empfänger XG hat daraus dann z.B. 3-1-2 gemacht womit dann die Anwendungen nichts mehr damit anfangen konnten und die Pakete neu angefordert haben. Das hat teilweise zu einem sogenannten TCP Ack Storm auf den VPN Verbindungen geführt, 2000+++ Anfragen für die fehlerhaften Pakete innerhalb weniger Sekunden pro Client, da könnt ihr euch vorstellen was auf den Leitungen los war, wenn 20-30 Clients jeweils 2000+ Paketanfragen abschicken. Dabei kamen die Pakete auch wieder in der falschen Reihenfolge an und so hat sich das häufig noch weiter aufgebaut. Während dieser ACK Storms war dann kaum noch Bandbreite für den übrigen Traffic verfügbar, so sind dann oft alle Verbindungen zeitgleich abgerissen.

Der Sophos Support war übrigens sehr wenig hilfreich, außer endlos langer Fragenkataloge kam da nicht viel rum.

 

Die Lösung des Problems, eher auch etwas notgedrungen, da wir jetzt ja kurzfristig wieder Homeoffice anbieten müssen und nach 4 Monaten ergebnisloser Fehlersuche auch meine KollegInnen an Standort B langsam richtig angenervt waren von den ständigen Ausfällen: Ich hab alle Sophos rausgeworfen und durch pfSense Firewalls ersetzt - die VPNs fetzen jetzt in alle Richtungen. Keine Abbrüche, keine Timeouts, volle Bandbreite nutzbar, komplett stabile iperf Werte! MTUs hab ich alle auf default zurückgestellt bzw. gelassen, das war ja die Vermutung vom Support und des Systemhauses, dabei musste ich die letzten 10 Jahre an keinem Router/Firewall jemals an den MTUs rumschrauben und auch jetzt nicht.

Was den Fehler an den XGs genau ausgelöst hat kann ich so letztendlich nicht genau sagen, aber ich bin von Sophos Produkten und deren (kaum existenten) Premium Support erstmal geheilt.

[MurdocX 903]

Von der Sophos-XG bin ich auch nicht mehr der Fan. Wir setzen sie auch ein. Was sich hier dennoch rausstellt ist, dass es ein lokales Problem bei Dir ist. Das Verhalten kann ich nicht nachvollziehen. Ich würde die Kisten zurücksetzen, alle Updates einspielen und nochmal sauber konfigurieren.

 

Danke für deine Rückmeldung. Konnte der Support deine Vermutung mit den Paketen nachvollziehen?

[illumina7 3]

Nicht so wirklich, also der Support hat ja das Packet Capture bekommen und kann den Fehler dort sehen, als Antwort darauf kam wieder ein endlos langer Fragetext ohne wirklichen Bezug zum Fehlerbild.

Wir hatten auch noch den Distributor Support (Infinigate) zugeschaltet, die konnten aber bei Ihren Messungen nie einen Fehler feststellen, sie hatten unter anderem S2S IPSec Tunnel mit Ihren eigenen Netzen hergestellt und gebencht, gecaptured etc.

Da muss ich sagen war die Kommunikation dann ziemlich gut, zu den falsch zusammengesetzten Paketen konnte uns dort aber auch niemand wirklich weiterhelfen.

 

Nach mehreren 100 Stunden Fehlersuche hatte ich dann aber auch genug davon, ich mein wir hatten Tage, da mussten wir scheinbar völlig grundlos alle MitarbeiterInnen an Standort B heimschicken. Die IPSec Tunnel waren online aber es kam kein Traffic zustande, egal wie oft wir die XGs rebootet hatten.

Zwischendurch hatten wir die Appliances auch auf Werkseinstellungen resettet und neu konfiguriert, leider auch ohne Erfolg.

Als wir die XG230 leihweise vom Systemhaus bekommen haben, hatten wir die Konfig allerdings nur eingespielt, nicht neu eingerichtet.

Das Verhalten bei uns konnte niemand nachvollziehen, dabei haben wir eine ganz einfach Standardkonstellation.

 

Nachdem die Fehlersuche die letzten Monate mein Arbeits- und Privatleben komplett in Beschlag genommen hatte, hat es mir dann auch gereicht und da musste was anderes her. Ich hab dann gute 2 Wochen gebraucht bis ich mich durch die pfSense Doku gewühlt hatte, aber es hat sich definitiv gelohnt.

[djmaker 95]

Erst einmal herzlichen Dank für dein ausführliches feed back. Du hast Ja wirklich Troubleshooting auf allen möglichen Ebenen gemacht. Herzlichen Glückwunsch zur Problembehebung.

 

Ich hoffe das dein Privatleben wieder in Ordnung kommt, ich denke viele können hier längere Lieder davon singen. In diesem Sinne wünsche ich Dir ein erholsames Wochenende und eine besinnlichen 2. Advent.