Tag Archives: VPN

HOWTO: Branch Office VPN over TLS

Comment

Seit Fireware 12.1 bietet WatchGuard die Möglichkeit, eine Standortvernetzung bequem über TLS umzusetzen. Das Server-Client Modell spielt seine Stärken besonders dann aus, wenn keine statischen IP-Adressen vorhanden oder IP-SEC durch vorgelagerte Router nicht möglich ist. Sie können also eine vorkonfigurierte Firewall an einen entsprechenden Außenstandort liefern lassen und unabhängig vom ISP benötigt das Remote-Device nur eine WAN Verbindung via Port 443. Weiterlesen »

Best Practices – MFA für Mobile User VPN

Comment

Inhalt:

Der Zugriff von Mitarbeitern im Außendienst auf interne Ressourcen wird oft über VPN Technologien ermöglicht. Eine Anmeldung nur mit Benutzername und Kennwort stellt hierbei ein erhöhtes Risiko dar. Dank Multifaktor-Authentifizierung mit WatchGuard Authpoint kann schnell und einfach die Sicherheit erhöht werden.

Ziel dieser technischen Webinar-Reihe ist es, Ihnen umfassende Hintergrundinformationen zu vermitteln.
Anhand von Konfigurationsbeispielen wird dargestellt, wie Sie die Security-Lösungen von WatchGuard optimal und effektiv einsetzen können.

 

Webinaraufzeichnung jetzt ansehen

HOWTO: Mobile IKEv2 VPN – Client-Anbindung mit Windows 10 Boardmitteln

4 Comments

Das IKEv2 Mobile VPN lässt Windows 10 Geräte eine stark verschlüsselte und performante Verbindung zu Ihrer WatchGuard aufbauen und benötigt hierfür keine 3rd Party Software auf dem Client-Device. Es lassen sich selbstverständlich auch andere Clients wie Mac OS, Android,… über IKEv2 mit der WatchGuard verbinden, was aber den Rahmen des Blog-Artikels sprengen würde.

Bei der IKEv2 Implementierung handelt es sich um einen Full-Tunnel, daher wird jeglicher Traffic über die WatchGuard geroutet!

Weiterlesen »

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 »

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.

IKE (IPSec) Subsystem einzeln neu starten

2 Comments

Wie man die Neu-Aushandlung von BOVPN Tunneln (einzeln oder alle) über den Firebox System Manager erzwingen kann, dürfte allgemein bekannt sein (FSM > Front Panel > Branch Office VPN Tunnels und dann Rechtsklick auf dieser Zeile oder einem der darunter angezeigten Gateway-Einträge: “Rekey All BOVPN Tunnels” bzw. “Rekey Selected BOVPN Tunnel”). Manchmal reicht dies aber nicht aus und man möchte gerne das komplette IKE/IPSec Subsystem auf der WatchGuard neu starten, um auf diese Weise eventuell auch “quer sitzende” SA-Fragmente los zu werden, die ein einfaches Re-Keying eines BOVPN Tunnels verhindern. Natürlich kann man dazu einfach die komplette WatchGuard neu booten – das geht aber im Produktiveinsatz nicht immer ohne weiteres. Über den Kommandozeilenmodus / Command Line Interface (CLI) gibt es die Möglichkeit, nur den IKE Prozess einzeln neu zu starten und dadurch alle SAs und Fragmente restlos zurückzusetzen:

* Als “admin” per Putty/SSH an der WatchGuard anmelden
* Befehl diagnose vpn “/ike/restart” absetzen
* Mit exit wieder abmelden

Ob der iked Prozess korrekt neu gestartet hat, kann man im FSM auf der Registerkarte “Status Report” sehen. In der Prozessliste sollte für iked nun das aktualisierte Datum/Uhrzeit zu sehen sein.

Korruptes Zertifikat entfernen

1 Comment

Vor ein paar Tagen hatte ich mit einer X750e (Softwareversion Fireware XTM 11.3.4) zu tun, die im Basic Managed Mode als Außenstelle an einem WatchGuard Management Server lief (Softwareversion WSM 11.5.3). Die BOVPN-Tunnel waren als Managed VPN Tunnels über den Management Server eingerichtet. Die BOVPN-Tunnel kamen nicht mehr hoch und die X750e ließ über WSM / Policy Manager auch keine Änderungen an der Konfiguration zu – auch dann nicht, wenn man mit einem lokalen WSM direkt mit der Box verbunden war. Fehlermeldung beim Schreiben einer Konfiguration: “An error occured while retrieving all certificates from the Firebox [IP]). Unable to send request to module”. Ein Neustart der Box brachte keine Änderung.

Die Fehlersuche zeigte Probleme mit den Zertifikaten auf der X750e. “View… Certificates” aus dem Firebox System Manager konnte die Zertifikate nicht anzeigen (leeres Feld und darüber eine leere Fehlermeldung).

Auch im CLI Modus brachte der Befehl “show certificates” nur eine Fehlermeldung. Der certd daemon lief auch nicht. Ich hatte einen ähnlichen Fall bereits vor ein paar Monaten. Damals waren auch Zertifikate kaputt, die Box ließ sich jedoch noch über WSM / Policy Manager administrieren. Damals konnte ich das Problem durch ein Software-Update auf eine neuere Fireware XTM Version beheben. Vermutlich hätte auch das Aufspielen der gleichen Version geholfen. Da jetzt aber WSM / Policy Manager nicht mehr funktionierten, habe ich dieses Mal über das Web-Interface gearbeitet (System > Upgrade OS) und auf diesem Weg die 11.3.4er sysa-dl Datei erneut hochgeladen. Nach dem Reboot war certd wieder da und die Zertifikate waren wieder sichtbar. Anschließend konnte die Box auch wieder an den zentralen Management Server angebunden werden, jedoch kamen die Managed VPN Tunnel immer noch nicht hoch. Als nächstes habe ich den zentralen WSM / Management Server näher untersucht. Beim Versuch, die Managed VPN Tunnel neu anzulegen, stürzte der WSM jedes Mal mit einer Fehlermeldung der AppMngr.exe ab. Ein Neustart des Dienstes half nicht, auch nicht der Reboot der kompletten Windows Server 2008 Maschine.

Als temporären Workaround wollte ich nun den BOVPN Tunnel zwischen der Außenstelle und dem zentralen System (ein XTM 810 Active/Passive Cluster mit Fireware XTM 11.5.3) manuell anlegen, damit die User zumindest erst einmal wieder arbeiten konnten. In der XML Konfigurationsdatei des zentralen XTM810 Clusters ist mir dann aufgefallen, dass dort noch die DVCP-basierte Gateway- und Tunnel-Definition der alten “Managed VPN” Verbindung angezeigt wurde, obwohl diese eigentlich gar nicht mehr vorhanden sein sollte. Durch ein Cluster Failover verschwanden diese Fragmente dann aus der zentralen Firewall-Konfiguration, woraufhin auch der WSM / Management Server nicht mehr abschmierte und schlussendlich der BOVPN Tunnel doch wieder regulär als “Managed VPN” Tunnel erfolgreich eingerichtet werden konnte…