Category Archives: Technischer Blog

VPN-Probleme aufgrund teilweisem Leitungsausfall im Backbone des Providers

Comment

Konfuzius spricht: “Nicht immer ist die Firewall des Kunden schuld, wenn ein VPN nicht (mehr) funktioniert und der Kunde sagt, er habe nichts geändert. Das kann auch wirklich mal den Tatsachen entsprechen.” 🙂

Die hier erlebte Ausgangs-Situation für den Support Call war äußerst seltsam: Der Internetanschluss funktioniert, nur die Verbindung zwischen zwei BOVPN-Standorten zeigte extrem unübliche Verhaltensweisen – Kommunikation auf einer IP eines Standorts funktionierte, eine weitere IP funktionierte nicht, ICMP Pakete kamen in eine Richtung an, in die andere nicht, aber dann auch wieder abhängig von der Ziel-IP.

Ist-Zustand: VPN zwischen zwei Standorten funktioniert nicht:

  • BOVPN wird aufgebaut.
  • Daten fließen aber nur in eine Richtung (received-packets auf der anderen Seite: 0, zu sehen im Firebox System Manager bei Aufblättern des VPNs).
  • Ping von Standort 1 zu Standort 2 geht nicht.
  • Ping von Standort 2 zu Standort 1 geht nicht – tcpdump zeigt aber, dass icmp request ankommt und icmp reply gesendet wird.
  • Ping von Standort 2 zu Standort 1 sekundäre IP geht
  • Ping von Standort 1 sekundäre IP zu Standort 2 geht nicht
  • Beide Standorte können problemlos im Internet arbeiten, empfangen E-Mail und können von einem dritten Standort per WatchGuard System Manager administriert werden.
  • WSM nur eben nicht vom jeweiligen anderen Standort aus.
  • Teamviewer-Sitzungen sind stabil.

Nach langer Suche und mehreren Telefonkonferenzen mit dem Internet Provider stellt sich heraus:

  • Eine Strecke zwischen zwei Routern im Backbone des Providers hat zwei 10G Interfaces zum nächsten Router
  • Diese sind mittels Link Aggregation zusammengeschaltet (also 1 logische Leitung, 2 physikalische Strecken)
  • Aufgrund dessen wird über die Pakete offenbar über (src-dest-type-port) ein Hash zusammengebaut, anhand dessen bestimmt wird, ob das Paket über die eine oder die andere physikalische Leitung geht.
  • Demzufolge geht Ping mal oder mal nicht (abhängig von der Ziel IP-Adresse), ein traceroute geht mal und mal nicht, und VPN baut sich auf oder auch nicht (udp/tcp) und/oder kann in eine Richtung keine Daten senden, empfängt aber aus der anderen Richtung, (weil diese Strecke mit Typ IPSec und den jeweiligen Ziel-IPs mal in die eine Richtung auf der richtigen und in die andere Richtung auf der falschen Leitung landet).

Nach Abschalten des 10G-Interfaces der defekten Strecke war sofort Traffic auf dem VPN sichtbar und ping / traceroute verrichteten wieder völlig normal ihren Dienst.
Trotz der anfänglichen Behauptung des Providers, es liege an der Firewall des Kunden, konnte gezeigt werden, dass die WatchGuard unschuldig war 🙂

Wie findet man so etwas?

  • Binden aller verfügbaren externen IPs als Secondary IP
  • Prüfen, welche IPs auf Ping antworten
  • Pingen aller Router im Traceroute
  • Pingen der Zwischeninterfaces aus dem Traceroute (Router Eingangs-IP, Router Ausgangs-IP aus dem Transfernetz, Auslesen/Zuordnen per traceroutes in beide Richtungen)
  • Unabdingbar: ein technisch kompetenter Ansprechpartner auf Seiten des Providers 🙂
  • Die richtige Eingebung zum richtigen Zeitpunkt beim richtigen Router nach Link Aggregation zu fragen 🙂

Anbindung an ZIVIT (Atlas Zollverfahren) mit WatchGuard ab 11.12.2

Comment

Eine Anbindung an ZIVIT (Atlas Zollverfahren) mit einer WatchGuard Firebox ist mit Fireware 11.12.2 unterstützt und getestet. Das Setup basiert auf einem oder mehreren route-based VPNs, es wird also über ein/mehrere virtuelle BOVPN-Interface(s) realisiert. Um die nötigen kundenspezifischen VPN-Einstellungen in Erfahrung zu bringen, sind der Zugang auf der Website des Zoll-Portals sowie ein per Briefpost überstellter Aktivierungs-Code notwendig. Genauere Informationen zu den WatchGuard-seitigen Einstellungen können Sie über unser Kontaktformular anfordern.

Einrichten von Threat Detection and Response – Teil 1

3 Comments

In dieser Artikel-Serie (bestehend aus 5 Teilen) wird das Setup von WatchGuard Threat Detection and Response beschrieben:

1. (Dieser Artikel:) Initiales Einrichten von Threat Detection and Response im WatchGuard KundenPortal
2. Konfiguration von Threat Detection and Response auf der WatchGuard Firebox und Installation der Host Sensoren
3. Konfiguration von Threat Detection and Response im TDR Kundenportal
4. Weitere Hinweise zu TDR, Tipps und Tricks
5. Best Practices

Teil 1 (Initiales Einrichten von Threat Detection and Response im WatchGuard KundenPortal) Weiterlesen »

Einrichten von Threat Detection and Response – Teil 2

4 Comments

In dieser Artikel-Serie (bestehend aus 5 Teilen) wird das Setup von WatchGuard Threat Detection and Response beschrieben:

1. Initiales Einrichten von Threat Detection and Response im WatchGuard KundenPortal
2. (Dieser Artikel:) Konfiguration von Threat Detection and Response auf der WatchGuard Firebox und Installation der Host Sensoren
3. Konfiguration von Threat Detection and Response im TDR Kundenportal
4. Weitere Hinweise zu TDR, Tipps und Tricks
5. Best Practices

Teil 2 (Konfiguration von Threat Detection and Response auf der WatchGuard Firebox und Installation der Host Sensoren) Weiterlesen »

Einrichten von Threat Detection and Response – Teil 3

3 Comments

In dieser Artikel-Serie (bestehend aus 5 Teilen) wird das Setup von WatchGuard Threat Detection and Response beschrieben:

1. Initiales Einrichten von Threat Detection and Response im WatchGuard KundenPortal
2. Konfiguration von Threat Detection and Response auf der WatchGuard Firebox und Installation der Host Sensoren
3. (Dieser Artikel:) Konfiguration von Threat Detection and Response im TDR Kundenportal
4. Weitere Hinweise zu TDR, Tipps und Tricks
5. Best Practices

Teil 3 (Konfiguration von Threat Detection and Response im TDR Kundenportal) Weiterlesen »

Einrichten von Threat Detection and Response – Teil 4

4 Comments

In dieser Artikel-Serie (bestehend aus 5 Teilen) wird das Setup von WatchGuard Threat Detection and Response beschrieben:

1. Initiales Einrichten von Threat Detection and Response im WatchGuard KundenPortal
2. Konfiguration von Threat Detection and Response auf der WatchGuard Firebox und Installation der Host Sensoren
3. Konfiguration von Threat Detection and Response im TDR Kundenportal 
4. (Dieser Artikel:) Weitere Hinweise zu TDR, Tipps und Tricks
5. Best Practices

Teil 4 (Weitere Hinweise zu TDR, Tipps und Tricks) Weiterlesen »

GAV Probleme beim Update der Virenscanner-Patterns auf XTM2-Series

1 Comment

Manchmal kommt es vor, dass keine aktuellen Gateway Antivirus Pattern heruntergeladen werden können. Siehe hierzu auch unseren Blog-Artikel “Crash Report kann AV-Update verhindern”.

Neben diesen “Crash Reports” kann es – je nach Größe des vorhandenen Flash-Speichers in einer WatchGuard XTM/Firebox (vom Modell vorgegeben) – auch zu Problemen mit der Aktualisierung der Antivirus-Pattern kommen, wenn auf der Firebox die Firmware-Images von WatchGuard Access Points gespeichert sind/werden. Dies ist bei älteren Softwareversionen auch standardmäßig der Fall, selbst wenn beim Kunden überhaupt keine WatchGuard Access Points im Einsatz sind. Bekannt ist derzeit ist ein Fall auf der XTM2-Serie (XTM25, XTM25-W, XTM26, XTM26-W), bei dem diese AP Firmware-Images nötigen Speicherplatz blockiert haben, so dass die AV-Updates nicht heruntergeladen bzw. gespeichert werden können. Abhilfe schafft hier das manuelle Löschen der AP Firmware-Images von der XTM/Firebox. Ab der Softwareversion Fireware 11.12.4 sind die AP Firmware-Images auch gar nicht mehr im eigentlichen Firebox-Betriebssystem enthalten und müss(t)en ohnehin einzeln auf die Firebox heruntergeladen werden.

Trifft dieses Szenario zu, sieht die Fehlermeldung bei einem GAV-Update wie folgt aus:

2017-04-14 11:04:12 sigd Manual GAV update is currently running Debug 
2017-04-14 11:04:18 sigd Decompression failed for '/sigs//tmp/incavi.avm' Debug 
2017-04-14 11:04:18 sigd Curl returned error: Failed writing body (4294967295 != 16384) Debug 
2017-04-14 11:04:18 sigd unable to download files for GAV Debug

Web-UI:

  1. Ggfs. Einschalten des Gateway Wireless Controller unter Network => Gateway Wireless Controller => [x] enable the Gateway Wireless Controller (danach muss eine Passphrase vergeben werden)
  2. Danach unter Dashboard > Gateway Wireless Controller (der Punkt existiert sonst nämlich nicht) unter Manage Firmware => Remove all Firmware
  3. Ggfs. Ausschalten des Gateway Wireless Controller unter Network => Gateway Wireless Controller => [_] enable the Gateway Wireless Controller

WatchGuard System Manager

  1. Im Policy Manager nötigenfalls den Gateway Wireless Controller aktivieren: Network => Gateway Wireless Controller => [x] enable the Gateway Wireless Controller
  2. Save to Firebox
  3. Firebox System Manager starten
  4. Im Tab Gateway Wireless Controller => Manage Firmware => Remove all Firmware
  5. Nötigenfalls den Gateway Wireless Controller wieder abschalten: Network => Gateway Wireless Controller => [_] enable the Gateway Wireless Controller

Anbindung Polycom Group 500 an BlueJeans Video Conferencing Cloud

Comment

Um ein Video Konferenz Terminal vom Typ Polycom Group 500 an BlueJeans anzubinden (eine Cloudlösung für Group Video Conferences), sind netterweise nur outgoing Ports in der WatchGuard Firewall freizuschalten. Das BlueJeans System ist so gestrickt, dass sich alle Clients über eine ausgehende Verbindung zu dem BlueJeans Cloud-Server verbinden und ihren Video-Stream von dort geliefert bekommen.

Die Dokumentation von BlueJeans in deren Support-Bereich ist eine wahre Freude für Firewall-Administratoren:

Verwendete Ziel-Adressen:

  • 199.48.152.0/22
  • 31.171.208.0/21
  • 103.20.59.0/24
  • 103.255.54.0/24
  • 8.10.12.0/24
  • 165.254.117.0/24

Je nach Protokoll werden folgende Ports verwendet:

BlueJeans Desktop App & Mobile App, BlueJeans Huddle and Chrome WebRTC:

  • Outbound TCP Port 443, 5061 or 5000 – Call Setup Signaling
  • Media Outbound UDP Ports 5000-5999 – RTP Media

H.323 based Room System:

  • Outbound TCP Port 1720 – H.225 Signaling for H.323
  • Outbound TCP Ports 5000-5999 – H.245 Call Control for H.323
  • Outbound UDP Ports 5000-5999 – RTP Media

SIP based Room System:

  • Outbound TCP Port 5060 – SIP Signaling
  • Outbound TCP Port 5061 – SIPS (TLS) Signaling
  • Outbound UDP Ports 5000-5999 – RTP Media

Microsoft Lync/ Skype For Business client:

  • Outbound & Inbound TCP Port 5061 – Lync Federation and SIP/TLS connection.
  • Outbound & Inbound UDP Ports 50000-59999 – RTP Media
  • Outbound & Inbound TCP Ports 50000-59999 – RTP Media

Fazit:

Dies ist eine sehr freundliche Lösung im Hinblick auf die notwendigen Freigaben in der Firewall.

HTTP Response Error Code 413 – Policy Manager – 11.12.2U1

Comment

Bei den Modellen M400 / M440 / M500 kommt es gelegentlich nach einem Update auf 11.12.2 Update 1 beim Speichern der XML mit dem Policymanager zu folgendem Fehler:

Error communicating with Firebox <ip.address>
INTERNAL_ERROR: Failed to create input stream: Server returned HTTP response code: 413 for URL: https://<ip.address>:4117/agent/rpc

Abhilfe: die Box muß einmal durchgebootet werden – Beim Upgrade von 11.11.x auf die Version 11.12.2 U 1 ist ein weiterer Reboot notwendig. Diese Info fehlt leider in den Release-Notes.