Category Archives: Technischer Blog

L2TP-VPN Watchguard <=> Windows, Tipps und Tricks

Comment

L2TP Routing

Unter Windows wird nativ das L2TP VPN unterstützt. Allerdings gibt es hierbei ein paar Dnge zu beachten:

  • L2TP verwendet Port 1701/UDP. Wenn man in einem Hotel sitzt, ist dieser Port möglicherweise nicht freigeschaltet. Dann hilft leider nur SSLVPN oder normales IPSec VPN oder eine UMTS/LTE Karte im Laptop bzw. der Hotspot im Handy.
  • L2TP verwendet normalerweise eine default route (0.0.0.0) durch den Tunnel. Damit geht der komplette Traffic einmal durch den Tunnel, was gewünscht sein kann, aber nicht muß

Dieser Artikel beschreibt Tipps und Tricks im Umgang mit L2TP VPN unter Windows 2008 und Windows 10.

Weiterlesen »

Ersetzen eines Webserver-Zertifikates auf der Firebox im Fully Managed Mode

Comment

Kürzlich ist folgender Fall aufgetreten:

  • SSL-Zertifkate werden typischerweise auf der Firebox über den Firebox System Manager erledigt. Dort konnte das Zertifikat auch hochgeladen werden.
  • Das Zertifikat muß anschließend aber über den Policy Manager unter Setup => Authentication => Web Server Certificate ausgewählt werden.
  • Das geht aber nicht, weil das Zertifikat dort nicht erscheint.

Hintergrund: im fully managed mode liegt die komplette Verwaltung der XML-Konfiguration auf dem Management-Server. Da das Zertifikat dann auch in der XML-Konfiguration stehen muß, zumindest mit der ID, unter der es angesprochen werden soll, fehlt die ID des neu auf die Box importierten Zertifikates. Im Policy Manager gibt es keine Möglichkeit, dieses Zertifikat aufzunehmen.

Workaraound:

  • Zertifikat mittels Firebox System Manager wie üblich auf der Box installieren
  • Box kurzfristig vom fully managed mode in den basic managed mode schalten.
  • Box danach sofort wieder vom basic managed mode in den fully managed mode zurückschalten
  • Policy Manager öffnen und das Zertifikat entsprechend Setup => Authentication => Web Server Certificate  unter auswählen.

Was passiert hier?

  • beim Wechsel vom fully managed mode in den basic managed mode wird auf der Box nur der “managed mode” geändert.
  • beim Wechsel vom basic managed mode in den fully managed mode wird die komplette policy neu von der Box geladen und in den Management Server geschrieben.
  • dabei werden wohl auch die vorhandenen IDs aller Zertifikate mitübernommen, d.h. das neu importierte Zertifikat ist nun in der Drop-Down-Box verfügbar.

 

 

Trennung der SSLVPN- und Authentication Login-Seiten

Comment

WatchGuard hat mit Fireware 11.12.2 das Authentication Portal (üblicherweise auf Port 4100) noch weiter vom SSLVPN-Portal abgetrennt. Bei älteren Fireware Releases war es möglich, über https://[IP-der-Firebox]/sslvpn_logon.shtml die SSLVPN-Login-Seite aufzurufen und über https://[IP-der-Firebox]/logon.shtml die Login-Seite für die normale User Authentifizierung an der Firewall – unabhängig davon, welcher Port (4100/Authentification oder 443/SSLVPN bzw. anderer eingestellter Port) aufgerufen wurde. Die saubere Trennung der beiden Dienste führt nun einerseits zu einer erhöhten Sicherheit, ist aber möglicherweise für den einen oder anderen etwas hinderlich. Beispielsweise wenn jemand, der die Authentifizierung von External nutzen soll, an seinem aktuellen Internet-Zugang nicht über Port 4100 ins Internet hinaus darf. Hier war es extrem praktisch, die Authentifizierung eben auch auf dem üblicherweise in ausgehende Richtung offenen Port 443 ansprechen zu können.

Folgende Workarounds können nun eingerichtet werden:

  • Falls der Port 443 noch gar nicht verwendet wird: Einrichten eines SNAT von Any-External an IP:443 mit Weiterleitung an die interne IP der Firewall auf Port 4100!
  • Falls der Port 443 bereits für SSLVPN verwendet wird: Sekundäre IP für den o.g. SNAT verwenden, sofern vom Provider mehrere externe IPs zur Verfügung gestellt werden
  • Evtl. SSLVPN auf einem anderen Port als 443 betreiben, um den Port 443 für User Authentication freizuschalten. Hier verlagert man das Problem aber nur, denn wenn SSLVPN z.B. auf Port 444 umkonfiguriert wird, dann müssen eben mögliche SSLVPN-Nutzer an deren Standort eben auch über diesen Port 444 ins Internet hinaus können…

Falls der externe Port 443 bereits für Microsoft Outlook Web Access (OWA) oder einen anderen Dienst (interner Webserver mit HTTPS) für die Weiterleitung nach innen benutzt wird, hilft hierbei künftig eventuell ein für Fireware 12.x angekündigtes neues Feature: Host Header Redirection. Mit diesem Feature soll es möglich werden, auf der WatchGuard Firewall ein Multidomain/SAN-Zertifikat zu installieren und dann abhängig vom jeweiligen Hostnamen auf unterschiedliche interne IPs weiterzuleiten. Leider wird hier nach meinem Kenntnisstand SSLVPN außen vor bleiben.

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 »