Tag Archives: Konfiguration

X Core und X Peak e-series nicht direkt von v10.x auf v11.3.3 oder v11.3.4 updaten!

1 Comment

Mit diesem Blog-Beitrag hatte ich bereits auf das Problem eines möglichen Verlusts der Konfiguration beim direkten Umstieg von Fireware v10.x auf Fireware XTM v11.3.3 und v11.3.4 hingewiesen. Der Hinweistext “Note: If you are upgrading from Fireware XTM OS v10.x, you must upgrade to Fireware XTM OS v11.3.2 before you upgrade to v11.3.4” im Software-Portal bestätigt nun also dieses Problem. Wenn Sie also auf einer X Core e-series (X550e, X750e, X1250e) oder einer X Peak e-series (X5500e, X6500e, X8500e, X8500e-F) die Migration von v10 auf v11 vorhaben, sollten Sie tunlichst den Zwischenschritt auf v11.3.2 mit in Ihren Upgrade-Pfad einbauen!

Secondary IP nicht auf VLANs

Comment

Ich musste aktuell in einem Projekt feststellen, dass Secondary IPs nur auf physikalischen Interfaces konfiguriert werden können, nicht aber auf VLANs. Ich konfiguriere Secondary IPs z.B. sehr gerne auf External Interfaces, um damit mehrere (oder alle) vom Provider zugewiesenen externen IP-Adressen auf einem externem Interface verfügbar zu machen, so dass diese für eingehenden Datenverkehr als Basis für einen SNAT-Eintrag (Statisches NAT oder Server Load Balancing) verwendet werden können.
In dem angesprochenen Projekt musste das neu hinzu kommende externe Interface aber auf einem VLAN-Interface konfiguriert werden. Hier konnte ich die weiteren IPs nur auf dem Weg über 1-to-1-NAT Einträge nachträglich verfügbar machen, was aber natürlich deutlich weniger flexibel ist wie die typischen SNAT-Einträge, die z.B. nur einen bestimmten Port einer IP-Adresse zu einem bestimmten internen Server weiterleiten…

Maximal vier physikalische External Interfaces

Comment

Aus früheren Zeiten hat auch die aktuelleste Fireware XTM 11.4.2 noch die Beschränkung, dass maximal vier physikalische Interfaces konfiguriert werden können. Wenn aber doch einmal MEHR als vier externe Interfaces konfiguriert werden sollen, bleibt noch der Weg über VLANs. Hierbei wird z.B. ein physikalisches Interface der WatchGuard als VLAN-Interface eingerichtet – und die ganzen externen Anschlüsse dann eben als Tagged VLAN mit unterschiedlichen VLAN-IDs. Zwischen der WatchGuard und den externen Leitungen sitzt dann ein VLAN-fähiger Switch, auf dem die gleichen VLAN-IDs konfiguriert sind. Die verschiedenen ISP-Router sind dann jeweils an einem Untagged Port angeschlossen, der dem passenden VLAN zugeordnet ist. Der Switch-Port, an dem die WatchGuard angeschlossen wird, muss als Trunk Port eingerichtet werden (Tagged).

Auf diese Weise kann man natürlich auch physikalische Ports auf der WatchGuard einsparen, wenn es in komplexen Umgebungen einmal eng wird. Statt z.B. mehrere Trusted oder Optional Networks direkt als physikalische Interfaces auf der WatchGuard einzurichten, können diese auch als VLANs auf einem VLAN-Switch abgebildet werden, der nur über ein einzelnes Kabel an der WatchGuard angeschlossen ist…

WatchGuard System Manager vs. WatchGuard Management Server

Comment

Begriffsbestimmung “WatchGuard System Manager”: Dieser wird auch im internen WatchGuard-Sprachgebrauch etwas uneindeutig verwendet.

Zum einen taucht er auf bei den Software Downloads und steht dort für die Software-Komponenten, die für die Installation auf einem Windows-basierten “WatchGuard Management Computer” gedacht sind. Der Dateiname für die aktuelle Version 11.4.2 lautet z.B.: WSM11_4_2s.exe (s steht hierbei für Strong Encryption) oder WSM11_4_2b.exe (b für Base Encryption – wenn z.B. beim Anlegen Ihres WatchGuard Accounts etwas schief gelaufen ist und Sie versehentlich in einem Land angesiedelt wurden, das unter US-Export-Beschränkungen steht 😉 Einen solchen Fehler sollten Sie schleunigst über einen Support Incident bei WatchGuard beheben lassen…)

Zum anderen wird der Begriff WatchGuard System Manager auch etwas irreführend für den Server Service “WatchGuard Management Server” verwendet. Das ist der Nachfolger des früheren “VPN Manager”, also die Möglichkeit, mehrere WatchGuard Fireboxen zentral zu verwalten und Branch Office VPN Tunnel zwischen den angeschlossenen Standorten per Mausklick einzurichten… Der “WatchGuard Management Server” ist ein optionales Kaufprodukt, das in 5-er Schritten (auch 25, 50, 100) zusätzlich erworben werden kann (taucht in den Preislisten lustigerweise auch wieder als “WatchGuard System Manager” auf…). Wenn Sie mindestens eine X750e oder eine XTM 505 in Ihrem Account haben, hat WatchGuard Ihnen bereits kostenfrei eine Lizenz für 4 Standorte bereitgestellt. Diese finden Sie bei Ihren “Activated Products”: Die Lizenznummern beginnen mit WSMMGR-1-xxx, WSMMGR-4-xxx, WSMUPGRADE-5-xxx o.ä. Nun ja, zumindest fanden Sie dort die Lizenznummern, bevor WatchGuard am 02.07.2011 das Customer Portal umgestellt hat… 😉 Sie werden irgendwann dort auch einmal wieder erscheinen. Vorher hilft nur ein Support Call, mit der Bitte, die entsprechende(n) Lizenznummer(n) telefonisch oder per E-Mail oder im Support Incident bekannt zu geben…

Hinweis: es kann immer nur eine WSMMGR- (Basislizenz) verwendet werden. Die Anzahl der lizensierten Standorte lässt sich dann nur durch WSMUPGRADE- (Erweiterungslizenzen) erhöhen.

Den Installer WSM11_4_2s.exe können Sie auch ohne diese Lizenznummer(n) vollständig durchklicken und je nach Bedarf sowohl die Client Komponenten als auch die Server Services “Management Server”, “WebBlocker Server”, “Logging Server”, “Quarantine Server” und “Report Server” erfolgreich installieren.

Wenn Sie jedoch anschließend die Server Services über das WatchGuard Server Center konfigurieren (und bei der Installation den “Management Server” angeklickt haben), werden Sie zur Eingabe der Lizenznummer(n) aufgefordert. Dies können Sie zwar überspringen, jedoch wird der Management Server erst dann funktionstüchtig sein, wenn Sie die Lizenznummer(n) nachträglich über das WatchGuard Server Center eingetragen haben.

Hinweis: Wenn Sie überhaupt nur eine einzelne WatchGuard Firebox besitzen, bringt Ihnen der Management Server auch gar nichts. Sie sollten dann beim Durchklicken des WSM11_4_2s.exe Installers das Häkchen beim Management Server einfach weg lassen.

Verwirrt? Na ja, kommt wie gesagt auch in den besten Kreisen vor… 🙂

Multi-WAN Konflikt mit zwei redundanten Cisco HSRP Router-Paaren

Comment

Das Debugging einer problembehafteten HA Umgebung aus zwei X750e mit Fireware XTM 11.3.2 (ich betrachte diese Version derzeit für Cluster aus X Core / Peak e-series am stabilsten) hat heute einen netten Sonderfall aufgezeigt, der für die Störungen sicher mitverantwortlich war:

Der Kunde betreibt schon seit vielen Jahren ein WatchGuard VPN mit ca. 40 Außenstellen. Wie so oft hat in der Vergangenheit dafür eine einzelne Company Connect Anbindung der Telekom mit 2 Mbit/s gereicht. Diese Leitung war mit redundanten Cisco-Routern und zudem einer Zweiwegeführung ausgestattet. Der Kunde hatte nun bei der Telekom eine weitere Company Connect Anbindung beauftragt, mit 34 Mbit/s und ebenfalls redundanten Cisco-Routern und Zweiwegeführung. Auf der WatchGuard waren diese beiden Anbindungen als Multi-WAN konfiguriert – im Failover-Modus.

Bei einem Routine-Check des “Status Report” im Firebox System Manager ist mir in der ARP Table der WatchGuard aufgefallen, dass dort beide vorgelagerten Router-Paare (2 Mbit an eth0 und 34 Mbit an eth1) mit der gleichen Hardware MAC Adresse 00:00:0C:07:AC:01 aufgeführt waren.

Recherche hat ergeben, dass dies eine virtuelle MAC-Adresse ist, die von redundanten Cisco-Routern im HSRP Modus verwendet wird – und zwar dann, wenn auf den Routern die HSRP Group ID = 1 eingestellt ist. Offenbar hat der ISP also beide Router-Paare (da verschiedene Einzelaufträge) per Default mit der gleichen HSRP Group versehen… Das wird auch erst dann zum Problem, wenn beide Leitungen wie im vorliegenden Fall an das gleiche System angeschlossen werden. Die Auswirkungen kann man sich ausmalen.

Ein Support Call bei der Telekom hat dazu geführt, dass ein Router-Paar auf die HSRP Group ID = 2 eingestellt wurde, wodurch sich die virtuelle MAC-Adresse auf 00:00:0C:07:AC:02 geändert hat und nunmehr aus Sicht der WatchGuard die Interfaces sauber konfiguriert sind:


Policy Based Routing

2 Comments

Die Voraussetzung für die Nutzung von Policy Based Routing ist die Fireware Pro bzw. XTM Pro Zusatzoption und die korrekte Konfiguration von mehr als einem externem Interface für den Multi-WAN-Betrieb (vgl. z.B. http://de.watchguard-blog.com/2011/08/multi-wan-und-policy-based-routing.html).
Anschließend erweitert sich das Erscheinungsbild jeder einzelnen Firewall-Policy – und über die dort erscheinenden, eigentlich selbsterklärenden erweiterten Einstellungen lässt sich das gewünschte Verhalten im Multi-WAN-Umfeld bestimmen:

Sinn macht an dieser Stelle natürlich – speziell für ausgehende HTTP und HTTPS Policies – hier das vom Multi-WAN-Default abweichende Interface auszuwählen (im Beispiel das Interface “VDSL50” anstelle der defaultmäßigen “STANDLEITUNG”). Das hat zur Folge, dass eben der durch ausgehende HTTP/HTTPS-Verbindungen (also auch Downloads!) verursachte Traffic über das “zweite” externe Interface geführt wird (VDSL50) – und somit die STANDLEITUNG von eben diesem Traffic entlastet wird, so dass die dortige Bandbreite für die unternehmenskritischeren Anwendungen wie VPN, E-Mail etc. genutzt werden kann.

Multi-WAN und Policy Based Routing

1 Comment

Wenn auf einer WatchGuard die Zusatz-Option “Fireware Pro” bzw. “XTM Pro” aktiviert ist, können bis zu vier Interfaces als External Interface konfiguriert werden. Hier können jeweils unterschiedliche Internet-Anschlüsse angebunden werden. Ein typisches Anwendungs-Szenario sieht so aus: Kunde x hat eine Standleitung mit x Mbit Bandbreite, die bisweilen überlastet ist, weil “zu viel” HTTP/HTTPS-Traffic (Eigennutzung, sprich Surfen und Downloads) die Leitung “dicht” macht und zu wenig Bandbreite für VPN-Anbindungen, E-Mail und andere unternehmenskritische Anwendungen übrig bleibt…
Statt einfach die Bandbreite der Standleitung für teuer Geld beim Provider hochsetzen zu lassen, kann auch darüber nachgedacht werden, einen – deutlich billigeren – ADSL, VDSL oder Kabel-TV-Anschluss als zweiten Internet-Anschluss an die gleiche WatchGuard anzubinden und über das Firewall-Regelwerk festzulegen, dass der typische HTTP und HTTPS Traffic über eben diese billigere DSL-Leitung geführt wird (Policy Based Routing, PBR). Damit wird die (teure) Standleitung von eben diesem Traffic ENTLASTET.

Die unternehmenskritischen Services können so evtl. auch auf längere Sicht auf dem bisherigen Stand zu deutlich geringeren laufenden Kosten versorgt werden.

Wenn nun mindestens ein zweites Interface der WatchGuard als “External” konfiguriert wird, sind zusätzliche Einstellungen erforderlich, ohne die das gewünschte Verhalten eventuell nicht zum Tragen kommt! Insbesondere muss im Policy Manager unter Network > Configuration die Registerkarte Multi-WAN beachtet werden, die bei Verwendung nur eines einzelnen externen Interfaces “ausgegraut” war.
Hier wähle ich in der Regel als Default-Verhalten im Multi-WAN-Betrieb anstelle des voreingestellten Verfahrens “Routing Table” das Verfahren “Failover” aus und aktiviere hinter dem Button “Configure” die am typischen Multi-WAN-Betrieb beteiligten externen Interfaces (die Zahlen in Klammern entsprechen der Interface-Nummer auf der WatchGuard: z.B. 0=eth0, 6=eth6):

Die angezeigte Reihenfolge der Interfaces entspricht auch dem tatsächlichen Verhalten der WatchGuard Firebox für ausgehende Verbindungen: sofern keine PBR-Regel ein anderes Verhalten vorschreibt, werden die Interfaces gemäß dieser Liste von oben nach unten bedient. Will heißen: Wenn das ganz oben aufgeführte Interface “ACTIVE” ist, dann wird auch genau dieses per Default bedient, ansonsten wird das nächste Interface in der Liste verwendet…

Wie erkennt nun die WatchGuard, ob ein Interface “ACTIVE” ist oder nicht? Auch dies wird über die Registerkarte Multi-WAN gesteuert:

Für jedes der am Multi-WAN Verhalten beteiligten Interfaces muss nun definiert werden, woran die WatchGuard die Verfügbarkeit des Interfaces festmachen soll. Das Default-Verhalten ist in der roten Markierung und den darunter aufgeführten Settings beschrieben. Demzufolge pingt die Firebox alle 15 Sekunden eine IP-Adresse an (standardmäßig das Default Gateway des jeweiligen Interfaces). Wenn die angepingte IP-Adresse (3+1) = 4 x 15 => 60 Sekunden) nicht antwortet, wird das Interface auf “INACTIVE” gesetzt. Kommen wieder drei aufeinanderfolgende Antworten im Abstand von 15 Sekunden, wird das Interface wieder auf “ACTIVE” gesetzt und nimmt am Multi-WAN-Verfahren teil.

Daraus ergeben sich zwei Problematiken:

  • Problem 1 (Szenario Standleitung) => “Wo befindet sich das Default Gateway einer Standleitung?” Antwort: “Das ist der Übergaberouter des ISP, der sich in der Regel beim Kunden vor Ort befindet und per Kabel direkt an der WatchGuard angeschlossen ist”. Wenn nun eben dieser Router auf “ping” antwortet: Ist das eine zuverlässige Aussage darüber, ob nun die eigentliche Internet-Anbindung durch diesen Router hindurch funktioniert? Antwort: “Nein”. Typischerweise sollte also hier eine EXPLIZITE IP-ADRESSE konfiguriert werden, die irgendwo tatsächlich im Internet liegt.

  • Problem 2 (Szenario PPPoE oder DHCP-Einwahl) => Das Default Gateway des Interfaces wird dem Interface vom Provider erst bei der Einwahl zugewiesen. In vielen Fällen (providerabhängig!) antwortet aber genau diese als Default Gateway zugewiesene IP-Adresse nicht auf ping. Was ist also das Resultat im Default-Zustand? Das Interface arbeitet zunächst (3+1) x 15 => 60 Sekunden ordnungsgemäß, wird dann jedoch von der WatchGuard als “INACTIVE” eingestuft und aus dem Multi-WAN-Verfahren herausgenommen… Insbesondere in diesem Fall sollte also UNBEDINGT eine tatsächliche IP-Adresse im Internet als ping-Ziel definiert werden…

Es ist nun also erkennbar, dass man sich im Multi-WAN-Umfeld von der Verfügbarkeit von externen Systemen abhängig macht, auf die man selbst keinen Einfluss hat! Ich verwende hier meist “bekannte” IP-Adressen, die in sich oft hochverfügbar ausgelegt sind: 8.8.8.8, 4.2.2.3, 141.1.1.1 oder die typischen DNS-Server der Telekom 194.25.0.60, 194.25.0.68, 194.25.0.52, 194.25.2.129 etc. Providerunabhängig lautet meine Empfehlung generell: Verwenden Sie hier nach Rücksprache mit Ihrem Leitungs-Provider eine IP-Adresse im Backbone Ihres Providers, die nachweislich hochverfügbar ausgelegt ist – und die sich nicht in absehbarer Zeit ändern wird!

(Mit der 141.1.1.1 hatte ich letzte Woche z.B. Probleme, weil die Betreiber wohl irgendwelche Wartungsarbeiten auf dem System durchgeführt haben, und die IP eine Zeitlang nicht erreichbar war – mit den Konsequenzen, die man sich sicher gemäß o.g. ausmalen kann… War zum Glück an einem Wochenende…)

Nachdem nun die Voraussetzungen für das korrekte Funktionieren von mehreren Interfaces im Multi-WAN-Umfeld gegeben sind, kann man an das Konfigurieren der tatsächlichen PBR (Policy Based Routing) Firewall-Regeln herangehen. Mehr dazu später heute Abend, wenn ich vom Strand zurück bin. Schließlich bin ich nun mal diese Woche im Urlaub… 🙂

Trade-Up / Migration von X Core e-series X550e, X750e, X1250e auf XTM 5

18 Comments

Viele Kunden steigen derzeit von einer WatchGuard X Core e-series X550e, X750e, X1250e auf ein entsprechendes Nachfolge-Modell XTM 505, XTM 510, XTM 520 und XTM 530 um (respektive von X Peak e-series auf XTM8). Fast immer taucht die Frage auf, ob die bestehende Konfiguration des “alten” Geräts auf das “neue” Gerät übertragen werden kann. Ja, sie kann. Es gilt aber ein paar kleine Hürden zu überwinden.

Zunächst muss natürlich die neue Box über die WatchGuard Website registriert und der neue Feature Key (Lizenzdatei) heruntergeladen werden. Auf dem Konfigurations-PC/Notebook haben Sie den aktuellen WSM 11.4.2 und die entsprechende Fireware XTM 11.4.2 für Ihre Geräte-Familie installiert, und auch das Adobe Flash Plugin für Ihren Browser ist vorhanden. Über https://10.0.1.1:8080 melden Sie sich mit dem User “admin” und dem Factory Default Kennwort “readwrite” an. Sie klicken den Setup Wizard mit den Default-Werten durch, importieren dabei auch den Feature Key und vergeben am Schluss Ihre eigenen Firewall-Kennwörter. Nach der erneuten Anmeldung mit Ihrem eigenen “admin”-Kennwort installieren Sie über System > Upgrade OS die neueste Fireware XTM 11.4.2 auf der Box, die daraufhin einmal durchbooten wird. Auf Ihrem Konfigurations-PC/Notebook starten Sie dann den WSM 11.4.2 und machen ein “Connect to Device” zu Ihrer neuen XTM-Box. Anschließend öffnen Sie den Policy Manager, der Ihnen die praktisch “leere” XML-Konfigurationsdatei der neuen XTM-Box anzeigt.

So weit, so gut. Erst jetzt wird es interessant:

Im Policy Manager laden Sie über File > Open > Configuration File die letzte XML-Konfigurationsdatei Ihrer “alten” WatchGuard. Auf die Frage “Do you want to save this new configuration to a file?” antworten Sie mit NEIN.

Sie sehen daraufhin die Konfigurationsdatei Ihrer “alten” WatchGuard. Falls Sie bisher eine X750e/X1250e im Einsatz hatten, bei der das Interface ganz rechts außen (eth7) im Einsatz war, sollten Sie sich die Network > Configuration Einstellungen für dieses Interface auf Papier notieren und prüfen, ob das Interface irgendwo namentlich in Firewall-Regel(n) auftaucht und auch diese entsprechend dokumentieren! Über Setup > System > Model wählen Sie Ihr neues Hardware-Modell aus. Es folgt eine Warnmeldung, die auf die veränderte Anzahl der Ethernet-Schnittstellen hinweist (eine XTM5 hat jetzt 7 Interfaces, eine alte X550e hatte 4, eine X750e/X1250e 8 Interfaces). Anschließend müssen Sie noch bei Setup > Feature Keys den Feature Key der alten Box removen und den Feature Key der neuen Box importieren. Beachten Sie bitte, dass im Policy Manager ganz unten rechts noch der Hinweis steht, dass es sich um eine Konfigurationsdatei des Typs “Fireware XTM v11.0-v11.3.x” handelt:

Auch bis hierhin alles planmäßig.

Anschließend starten Sie ein “Save to Firebox”. Die eventuelle Warnmeldung “The specified IP address does not match any of the interfaces specified in this config file. Are you sure you want to save to this Firebox?” (…ist klar, weil Ihre alte Konfigurationsdatei höchstwahrscheinlich eben nicht die 10.0.1.1 für eth1 enthält…) bestätigen Sie mit JA.

und erhalten dann eine zweite Warnmeldung: “The configuration file must be upgraded before it can be saved to the v11.4.2 device. Would you like to upgrade the configuration now?”. Auch die bestätigen Sie mit JA.

Anschließend folgt überraschend: “Error communicating with Firebox [IP]. INTERNAL_ERROR: The configuration is invalid, missing application action object”, die Sie nur mit OK bestätigen können.

=> Brechen Sie den Vorgang dann mit CANCEL ab und schließen Sie den Policy Manager.

Öffnen Sie den Policy Manager erneut, und öffnen Sie über File > Open > Configuration File die NEUESTE Version der Konfigurationsdatei, die im Zuge des vorigen “Save to Firebox” gespeichert wurde (ist nur wenige Minuten alt…). Bestätigen/ignorieren Sie die weiter oben bereits beschriebenen Warnmeldungen und starten Sie dann erneut den Vorgang “Save to Firebox”. Beachten Sie in diesem Zusammenhang, dass nun im Policy Manager ganz unten rechts für die Konfigurationsdatei der Typ “Fireware XTM v11.4.2” angezeigt wird:

=> Jetzt – beim zweiten Mal – sollte das Hochladen der Konfigurationsdatei funktionieren:


Danach sollten Sie die neue Box dann auch über die “alten” TCP/IP-Einstellungen auf den entsprechenden Interfaces ansprechen können! [Hinweis: die Firewall-Kennwörter sind nicht Bestandteil der Konfigurationsdatei, sondern hardwarespezifisch! D.h. die neue Firebox hat nicht automatisch die Kennwörter der alten Firebox, sondern die, die Sie ihr über den Setup Wizard verpasst haben!]

Verlust der Konfigurationsdatei beim Update von v10 auf v11.3.4

2 Comments

Mir ist es in den letzten Wochen selbst zweimal passiert, und auch ein Kunde hat übereinstimmend berichtet, dass beim Software-Update einer bestehenden X Core e-series (X550e, X750e, X1250e) von Softwareversion 10.2.x direkt auf Version 11.3.4 die Firebox anschließend eine “leere” Konfigurationsdatei hatte – genau so wie sie aus dem Setup Wizard mit durchbestätigten Default-Einstellungen heraus kommen würde.
Das Dumme dabei ist, dass sich auch die TCP/IP-Einstellungen der Interfaces auf Default zurückgesetzt haben: eth0=10.0.0.1/24, eth1=10.0.1.1/24 usw.!! Dadurch war die Firebox natürlich nicht mehr direkt “ansprechbar”, weder vom Trusted Network noch remote über das Internet!
Zum Glück war bisher in allen meinen Fällen kompetentes IT-Personal vor Ort zur Stelle, das nach telefonischer Anleitung den lokalen Zugriff und den Remote-Zugriff wieder herstellen konnte:

  • Auf eth1 lag 10.0.1.1/24, also musste zunächst irgendwie dafür gesorgt werden, dass ein PC/Notebook mit einer anderen fest konfigurierten IP-Adresse aus dem Subnetz 10.0.1.0/24 auf eth1 zugreifen kann.
  • Auf dem PC/Notebook muss bereits ein funktionsfähiges Adobe Flash Plugin vorhanden sein!
  • https://10.0.1.1:8080 ruft den WatchGuard Setup Wizard auf.
  • Die Passwörter waren jedoch NICHT die Factory Defaults readonly bzw. readwrite, sondern immer noch die bisherigen tatsächlichen Kennwörter der Firebox! (Auch der Feature Key war auf dem Gerät noch vorhanden und aktiv!)
  • Durchklicken des Setup Wizard, wobei jedoch die TCP/IP-Einstellungen für das TRUSTED Interface (und bei Remote Administration die Einstellungen für das EXTERNAL Interface) passend wiederhergestellt werden müssen!! Diese Angaben sollten also bei Durchführung eines Software-Updates grundsätzlich immer irgendwie “schwarz auf weiß” zugänglich sein… 🙂
  • Bei Remote Administration muss noch die “WatchGuard” Firewall Policy kurzfristig so erweitert werden, dass der Alias “Any-External” im From-Feld zu stehen kommt.
  • Nun kann die letzte existierende XML-Konfigurationsdatei wieder auf die Firebox hochgeladen werden – und alles sollte wie vorher sein, nur dass jetzt eben die 11-er Software darunter liegt…

Dieses Verhalten ist bei WatchGuard (noch) nicht als Problem bekannt, aber man weiß ja nie… Drei unabhängige Fälle lassen ja schon vermuten, dass da womöglich momentan ein Bug sein Unwesen treibt… Kleiner Tipp: eventuell hat das Problem ja auch etwas mit den berühmten Sonderzeichen zu tun. Sollten Sie also Firewall-Kennwörter verwenden, die nicht ausschliesslich aus A-Z, a-z und 0-9 bestehen, sollten Sie diese eventuell VOR dem Software-Update kurzfristig entsprechend ändern… 🙂

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!!!