Category Archives: Technischer Blog

XTM: Mobile User verlieren Routing in das lokale Netzwerk

1 Comment

In einem Support Incident hatte ich in den letzten Wochen mit dem Problem zu kämpfen, dass Mobile User, die sich per MUVPN (NCP IPSec Client) oder WatchGuard SSL-VPN-Client einwählen, zwar eine augenscheinlich stabile VPN-Verbindung stehen haben – aber trotzdem nicht auf Resourcen im lokalen Netzwerk zugreifen können.
Die Besonderheit hierbei war jedoch, dass der Zugriff unmittelbar nach der Einwahl möglich war (z.B. Test per “ping -t”) – nach ein paar Sekunden jedoch plötzlich nicht mehr. Ein Vergleich der Routing Table des Einwahl-PCs (“route print”) sofort nach der Einwahl und später nach dem Auftreten des Problems zeigt, dass die Einwahl-Routen in das lokale Netzwerk plötzlich verschwinden, wodurch natürlich nicht mehr auf die internen Resourcen zugegriffen werden kann… Umfangreiche Fehlersuche zeigte auf, dass das beschriebene Problem nur in Kombination aus bestimmten Faktoren auftritt. Reproduzierbar war das Problem insbesondere, wenn auf dem betroffenen Client-PC:

  • Windows XP läuft als Betriebssystem
  • eine Broadcom-Netzwerkkarte eingebaut ist, die IEEE 802.1X Authentication unterstützt (oder ein anderer Hersteller)
  • eventuell begünstigt auch das Vorhandensein des “Novell-Client” auf dem gleichen PC das Problem.

Der Workaround, der das Problem bei dem betreffenden Kunden zunächst umschifft hat (ohne dabei jedoch das eigentliche Problem zu beheben) basiert darauf, unter Systemsteuerung > Netzwerkverbindungen in dem virtuellen Netzwerkadapter, der von dem MUVPN-IPSec-Client (NCP) erzeugt wird, auf dem Tab “Authentication” das Häkchen entfernen bei Enable IEEE 802.1X Authentication:

Das o.g. Häkchen scheint auch bei virtuellen Adaptern automatisch aktiviert zu sein (wie dem IPSec MUVPN-Client und dem WatchGuard SSLVPN-Client), wenn der darunter liegende physikalische Netzwerk-Adapter diese Funktion unterstützt. Nachdem die VPN-Software die Verbindung hergestellt hat, greift offenbar die 802.1X Authentication ein und unterbricht für kurze Zeit die Netzwerkverbindung. Anschließend kommt offenbar zwar die Netzwerkverbindung zurück, aber die Routen sind aus der Routingtabelle verschwunden…

XTM: Ankündigung 11.4 – neue Funktionen

Comment

Im November oder Dezember 2010 wird WatchGuard die neue Version Fireware XTM 11.4 herausbringen. In der neuen Version der XTM Software stecken etliche neue Funktionen:

  • Application Control
  • neue Intrusion Prevention Service (IPS) Engine
  • Terminal Service Authentication
  • Authentication Enhancements
  • Rogue Wireless Access Point detection
  • Multi-Box und Logging Reporting Erweiterungen

Die größte Neuerung ist Application Control. Mit diesem neuen Bestandteil des Security Service Bundles erkennt eine WatchGuard XTM Appliance (Achtung: nur die aktuellen XTM 2, XTM 5, XTM 8 und XTM 1050 Appliances werden diese Funktion unterstützen!) über 1500 Web-Anwendungen innerhalb des üblichen HTTP- und HTTPS-Verkehrs und bietet die Möglichkeit, den Zugriff darauf auf User-Basis, Gruppenmitgliedschaften und der Tageszeit zu steuern (Block oder Allow) und auch entsprechende Reports darüber zu erzeugen.
Das Beta-Programm für die Version 11.4 wird in wenigen Tagen anlaufen, zudem bietet WatchGuard aktuell eine Reihe von Webinaren an, in denen die neuen Funktionen in Live Sessions vorgestellt werden.

XTM: SSO Exceptions jetzt auch als Host Range und Network IP

Comment

Bei einer WatchGuard Firebox oder XTM hat Single Sign On (SSO) in Verbindung mit Active Directory die Aufgabe, automatisch zu erkennen, welcher Windows-User an einem PC angemeldet ist und dies an die WatchGuard Firebox zu melden, damit Firewall-Regeln angewendet werden, die auf einer Gruppenmitgliedschaft oder einem Usernamen basieren. Wie beim händischen Ausfüllen der Authentication Page (Port 4100) lernt die WatchGuard mit Hilfe des SSO Agent (und des optionalen SSO Client) dabei, welcher User sich hinter einer bestimmten IP “verbirgt” und in welchen Active Directory Gruppen dieser User Mitglied ist.

Die automatische Erkennung per SSO macht jedoch nur Sinn bei Standalone-PCs, die Mitglied einer Windows-AD-Domäne sind – und an denen jeweils nur ein User gleichzeitig angemeldet ist. In der Regel ist es empfehlenswert, Maschinen, die kein AD-Domänenmitglied sind oder kein Windows-Betriebssystem haben (z.B. Apple Mac, Linux oder Windows Mobile Clients) sowie Windows-Server von der automatischen User-Erkennung per SSO auszuschließen.

Bislang konnte die Liste der so genannten “SSO Exceptions” nur relativ umständlich befüllt werden. Jede dementsprechende IP-Adresse musste einzeln eingetippt werden. Mit dem aktuellen WatchGuard System Manager (WSM) und Fireware XTM 11.3.2 lassen sich nun auch die von normalen Firewall-Regeln her bekannten Auswahlen Host Range, Network IP und Host Name (DNS lookup) verwenden, was das Befüllen der SSO Exception List in vielen Umgebungen sicher deutlich vereinfachen wird:

Gross-/Kleinschreibung bei Active Directory Authentication

Comment

Wenn Firewall-Regeln auf Basis einer Active Directory Gruppenmitgliedschaft oder eines Active Directory Username geschrieben werden, muss der Name der Gruppe oder des Users auf der WatchGuard zuerst einmal “bekannt gemacht” werden: Setup > Authentication > Authorized Users/Groups. Als “Name” MUSS genau die gleiche Schreibweise bezüglich Groß-/Kleinschreibung verwendet werden mit der die Gruppe bzw. der User im Active Directory angelegt ist (sAMAccountName):


Anderenfalls ist zwar unter Umständen die User Authentication an für sich erfolgreich, jedoch werden dabei nicht die passenden Gruppenmitgliedschaften ausgelesen – entsprechende Firewall-Regeln laufen daher ins Leere. Im Traffic Monitor wird der Traffic zwar als dem User zugehörig angezeigt, aber u.U. eben trotzdem als Unhandled Packet und daher als denied.

Installations-Problem bei WSM 11.3.2

Comment

Mir ist mittlerweile in ein paar Update-Installationen des WatchGuard System Manager (WSM) 11.3.2 aufgefallen, dass der Installer mit einer Fehlermeldung an ein paar Stellen hängengeblieben ist, die etwas mit den Dateien C:ProgrammeGemeinsame DateienWatchGuardwsm11libnlsen_US logging_res.loc und C:ProgrammeWatchGuardwsm11postgresqllib pgevent.dll zu tun hatten. Wenn die Dateien im Hintergrund z.B. im Windows Explorer umbenannt oder gelöscht werden, kann der Installer anschließend fortgesetzt werden…

Active/Passive HA Failover Problem

Comment

In einem Kundenprojekt (zwei XTM 505 in Active/Passive HA) wurde berichtet, dass nach einem Failover von der Primary auf die Secondary Firebox die Systeme in einer DMZ nicht mehr erreichbar wären. Die Systeme untereinander könnten kommunizieren, auch die Systeme im eigentlichen Trusted Network arbeiten korrekt.
Das Problem scheint sich auf einen bereits bekannten Bug zurückführen zu lassen, der dafür sorgt, dass sich nach einem Failover die neue MAC-Adresse des WatchGuard Clusters nicht in die ARP Table der angeschlossenen Client-PCs einträgt (BUG45223). Das Problem soll in einer der kommenden Software-Releases behoben sein.

XCS: DNS-Problem behindert Reputation Authority und DNSBL

3 Comments

Am heutigen Montag, 06.09.2010, trat gegen 10 Uhr ein Problem in der DNS-Zone “borderware.com” auf, weswegen die IP-Adressen der WatchGuard Reputation Authority und der von Borderware und der WatchGuard XCS verwendeten DNSBL-Server nicht mehr aufgelöst werden konnten. Das Problem war zwar kurze Zeit später bereits wieder behoben, wegen des weltweiten Abgleichs der DNS-Resolver kommt es jedoch auch jetzt (19 Uhr) noch zu Problemen, da u.a. auch die bekannten Telekom-Server 194.25.0.52, 194.25.0.60, 194.25.0.68, 194.25.2.129 z.B. den Hostname “www.reputationauthority.org” noch immer nicht auflösen können.

Auf der WatchGuard XCS tritt das Problem unter anderem so in Erscheinung, dass eingehende E-Mails bereits auf dem Connection Layer abgelehnt werden:
connect to mail.xxx.de[xxx.xxx.xxx.xxx]: server refused to talk to me: 550 Client host rejected: [not accepting mail from this ip]

Ich habe das Problem heute auf drei WatchGuard XCS Installationen kurzerhand und vorübergehend so gelöst, indem ich die Überprüfungen anhand der Reputation Authority und DNSBL ausgeschaltet, sowie den internen DNS Cache der XCS disabled habe. Diese Einstellungen werde ich in 1-2 Tagen wieder rückgängig machen, wenn die DNS-Auflösung aller Systeme wieder korrekt funktioniert. Dadurch wird zwar die Spam-Quote in den nächsten 1-2 Tagen geringfügig höher sein, jedoch können jetzt natürlich auch die ganzen legitimen E-Mails wieder zugestellt werden.

Security > Connection Control:
   Reject on Reputation *AUS*,
   Reject on infection *AUS*,
   Reject on DNSBL *AUS*
Activity > Status&Utility > Flush DNS Cache > Flush
Configuration > Interfaces:
   Enable DNS Cache *AUS*

Fireware XTM: HA Cluster Probleme mit MTU Size im BOVPN Tunnel

1 Comment

Ich habe aktuell einige offene Support-Fälle, die folgende Gemeinsamkeiten aufweisen: Active/Passive Cluster unter Fireware XTM v11.3.x, Branch Office IPSec VPN Tunnel zu festen Außenstellen, Kommunikationsprobleme innerhalb des/der BOVPN Tunnel.
In allen Fällen scheinen die Probleme mit fehlerhafter Fragmentierung von IPSec-Paketen zu tun zu haben. Ich konnte etwas ausführlicher debuggen und feststellen, dass bisweilen (also nur zeitweise!) IP-Pakete größer als 1394 Bytes im VPN-Tunnel nicht korrekt fragmentiert, sondern komplett verworfen werden. WatchGuard hat das Szenario im TestLab nachgestellt, konnte jedoch die Fehlerursache bis jetzt noch nicht weiter eingrenzen.
Zur schnellen Dokumentation des Problems verwende ich von einem PC in einer Außenstelle eine MSDOS-Eingabeaufforderung mit dem Befehl

ping [IP] -l 2000 -t

wobei [IP] eine IP-Adresse am anderen Ende eines BOVPN-Tunnels (in der Zentrale) ist. Der Befehl erzeugt Ping-Pakete mit einer Größe von 2000 Byte, die also beim Transport über das Internet zwingend fragmentiert werden müssen, da die maximale MTU Size auf Internet-Routern in der Regel 1500 Bytes beträgt. Erhalte ich korrekte ICMP-Antworten, weiss ich, dass die Fragmentierung korrekt funktioniert. Wenn nicht, liegt ein Problem vor. Durch Verkleinern der Paketlänge kann man sich iterativ an den kritischen Wert herantasten. Im vorliegenden Problemfall werden Pings mit 1394 Bytes korrekt übertragen, Pings mit 1395 Bytes und mehr jedoch NICHT:

Das Problem scheint zudem nur auf dem Rückweg von dem angepingten Host aufzutreten. Offenbar erreichen im Problemfall auch größere Datenpakete den Zielhost, der auch korrekt antwortet – jedoch scheint die WatchGuard Firebox ein Problem mit dem “Rücktransport” der Antwortpakete zu haben, wie sich am Vergleich der folgenden, im Abstand von ein paar Minuten aufgenommenen Screenshots erkennen lässt. Die mit grünen Streifen markierten Werte zählen im Laufe der Zeit korrekt hoch, während der eine rot markierte Wert (RCVD zurück auf dem ursprünglich sendenden System) sich nicht ändert…:

In allen meinen Support-Fällen konnte ich das Problem zunächst durch einen Workaround umgehen: auf dem Cluster Reduktion der MTU Size auf den Interfaces, die an BOVPN-Tunneln beteiligt sind, von 1500 auf 1380 Bytes:

WatchGuard muss jedoch das eigentliche Problem finden und beheben, denn durch den Workaround wird die Gesamtleistung der WatchGuard Firebox etwas ausgebremst.

Fireware XTM: Reihenfolge der Anmelde-Domänen auf der Anmeldeseite

1 Comment

In Verbindung mit User Authentication wird meist die manuelle Anmeldeseite der WatchGuard Firewall Appliance verwendet:
https://[IP-der-Firebox]:4100.
Die Authentication kann entweder gegenüber der lokalen Benutzer-Datenbank der Firebox selbst erfolgen (Firebox-DB), alternativ gegenüber externen Benutzer-Datenbanken unter Verwendung von RADIUS, SecureID/VASCO, LDAP oder Active Directory. Selbst wenn in der Firebox-DB gar keine lokalen User vorhanden sind, weil z.B. generell mit Active Directory gearbeitet wird, sieht die Anmeldeseite BEIM ERSTEN AUFRUF erst einmal so aus, d.h. standardmäßig wird “Firebox-DB” als Anmelde-Domäne angezeigt:

Die User müssen also in diesem Fall nicht nur geschult werden, dort ihren Windows-Benutzernamen und ihr Windows-Kennwort einzugeben, sondern auch noch in dem Pulldown-Menü darunter MANUELL von “Firebox-DB” auf “Active Directory” umzustellen. Das gestaltet sich manchmal etwas schwierig……… Besser wäre es natürlich, wenn die Anmeldeseite auch schon beim ersten Aufruf standardmäßig “Active Directory” als Anmelde-Domäne zeigen würde:

Die Reihenfolge der Anmelde-Domänen in dem Pulldown-Menü lässt sich durch einen manuellen Eingriff in die XML-Konfigurationsdatei beinflussen.
Erzeugen Sie als Backup zunächst eine Kopie Ihrer aktuellen XML-Konfigurationsdatei. Öffnen Sie die XML-Datei dann mit einem entsprechenden Editor. WordPad reicht schon. Suchen Sie nach dem Tag “auth-domain-list”. Sie werden erkennen, dass dort die von Ihnen verwendeten Anmelde-Domänen als “auth-domain” aufgelistet sind. An erster Stelle werden Sie “Firebox-DB” finden. Sie können nun die Anzeige-Reihenfolge festlegen, indem sie die jeweils vollständigen “auth-domain”-Tags per Cut&Paste in der gewünschten Reihenfolge anordnen. Speichern Sie die geänderte XML-Datei, öffnen Sie diese über den Policy Manager und laden Sie sie per “Save to Firebox” auf die WatchGuard hoch.
ACHTUNG: Wie immer ist in einem solchen Fall natürlich sehr sorgfältiges Vorgehen angesagt!!!

Fireware XTM: Öffentliches Zertifikat für Anmeldeseite (Port 4100 tcp) verwenden

2 Comments

Wenn auf der WatchGuard Firebox oder WatchGuard XTM mit User Authentication gearbeitet wird – also Firewall-Regeln verwendet werden, die auf User-Basis greifen und nicht auf Maschinen-Basis – kommt häufig die Anmeldeseite der Firewall ins Spiel, die über
https://[IP-der-Firebox]:4100
aufgerufen wird. Die Anmeldeseite verwendet SSL-Verschlüsselung. Hierfür wird standardmäßig ein von WatchGuard selbst generiertes Zertifikat verwendet, das aber nicht von einer öffentlichen Zertifizierungsstelle rückbestätigt ist, weswegen beim Aufruf die allseits bekannte Warnmeldung des Browsers erscheint. Folgende Zertifikate sind ab Werk auf einer WatchGuard Appliance unter Fireware XTM 11.3.x vorhanden:


Das SSL Zertifikat von WatchGuard kann durch ein offizielles, von einer allgemein bekannten Zertifizierungsstelle rückbestätigtes SSL Zertifikat ersetzt werden. Hier reicht schon ein einfaches Zertifikat z.B. von RapidSSL aus, das bereits für 10,95 USD pro Jahr erhältlich ist. Alternativ kann (mit den bekannten Einschränkungen) auch ein von einer firmeninternen, privaten Zertifizierungsstelle erstelltes Zertifikat verwendet werden. Es empfiehlt sich, das Zertifikat für einen griffigen Hostname ausstellen zu lassen (firewall.kundenname.de, watchguard.kundenname.de, fw.kundenname.de etc.) und diesen über DNS korrekt bekannt zu machen. Zur allgemeinen Vorgehensweise:
WatchGuard System Manager (WSM) > Connect to Firebox > Firebox System Manager > View > Certificates > Create Request.
Der abschließend erzeugte CSR (Certificate Signing Request) wird an die Zertifizierungsstelle geschickt, für die man sich entschieden hat. Wenn das von dort ausgestellte Zertifikat vorliegt, kann es über “Import Certificate / CRL” auf die Firebox importiert werden. Wenn das Root-Zertifikat der CA nicht in der Liste der defaultmäßig enthaltenen CA Certificates enthalten ist (http://www.watchguard.com/help/docs/wsm/11/en-US/Content/en-US/certificates/cert_auto_trusted_list_c.html), muss es VOR dem Import des eigentlichen Zertifikats auf die gleiche Weise importiert werden, da sonst ein Fehler generiert wird: “Error: Error occurred while performing ‘import certificate’: certificate add error msg=”Failed to import a certificate!! 6_982: certificate validation fail” add certificate”. Das Root-CA Zertifikat von RapidSSL findet sich übrigens hier: http://www.geotrust.com/resources/root_certificates/certificates/Equifax_Secure_Certificate_Authority.cer. Wählen Sie für den Import jeweils die Option “IPSec, Web Server, Other”. Der erfolgreiche Import wird angezeigt:

Nun ist/sind die offiziellen Zertifikat(e) zwar schon auf der Firebox vorhanden, müssen aber noch für den Einsatz auf der Authentication Webpage der Firebox ausgewählt werden:
Policy Manager > Setup > Authentication > Web Server Certificate… > Third Party Certificate auswählen > OK > Save to Firebox.
Abschließend muss die Firebox einmal durchgebootet werden, damit diese Änderung auch tatsächlich aktiv wird: