Category Archives: Technischer Blog

SSL 100: Öffentliches Zertifikat verwenden

2 Comments

Ab Werk wird auf einer WatchGuard SSL 100 ein von WatchGuard selbst generiertes Zertifikat verwendet, das nicht gegenüber einer allgemein bekannten, offiziellen Zertifizierungsstelle rückbestätigt ist. Das Zertifikat heißt “TestCert” und ist auf den imaginären Domainnamen “my.company.my” ausgestellt. Beim Aufruf der Anmeldeseite der SSL 100 erscheint also zunächst die allgemein bekannte Warnmeldung des Browsers. Natürlich kann das Zertifikat akzeptiert werden und das weitere Arbeiten mit der SSL 100 erfolgt trotzdem gesichert auf der Basis von SSL.
Wenn die SSL 100 jedoch nicht nur für den Remote Zugriff von eigenen Mitarbeitern verwendet wird, denen man die o.g. Vorgehensweise natürlich per Hausmitteilung bekannt machen kann – sondern auch zur Anbindung von externen Mitarbeitern, Lieferanten oder Kunden, ist es natürlich ein professionelles Vorgehen, das TestCert durch ein offiziell rückbestätigtes Zertifikat zu ersetzen. Je nachdem, welche Sicherheitsstufe angebracht erscheint, kann mit einfachen SSL-Zertifikaten für weniger als 10 Euro pro Jahr gearbeitet werden oder mit entsprechend teureren Zertifkaten, bei denen z.B. dann auch die Browserzeile nicht weiß, sondern grün hinterlegt wird…
Die Vorgehensweise ist in jedem Fall identisch, erscheint jedoch etwas kompliziert: Zunächst muss manuell ein CSR (Certificate Signing Request), eine Zertifikatsanforderung, erstellt werden – auf der Basis eines ebenfalls manuell erzeugten privaten Schlüssels. Hierzu muss auf einem Computer die Software “OpenSSL” installiert werden. Download im Internet, Einstieg über http://www.openssl.org. Der Installer für Windows findet sich unter http://www.slproweb.com/products/Win32OpenSSL.html. Sofern auf dem Windows-PC noch nicht die “Visual C++ 2008 Redistributables” installiert sind, müssen diese ebenfalls installiert werden (Download-Link direkt darunter oder Suche nach vcredist_x86.exe im Microsoft Download-Bereich).
Nach der Installation von OpenSSL mit den Default Einstellungen wird eine MSDOS-Eingabeaufforderung geöffnet und im Programmverzeichnisbin werden folgende Befehle ausgeführt:
openssl genrsa -out wgnet.key 1024
openssl req -new -key wgnet.key -out wgnet.csr
openssl pkcs8 -topk8 -in wgnet.key -out wgnet.pk8

Der erste Befehl erzeugt den privaten Schlüssel, der im zweiten Befehl zur Erzeugung der Zertifikatsanforderung verwendet wird. Dort startet auch ein Dialog, bei dem entsprechende Kundendaten abgefragt werden, unter anderem auch den Common Name (CN), auf den das Zertifikat ausgestellt werden soll, also z.B. “sslvpn.kundenname.de”. Der dritte Befehl konvertiert den privaten Schlüssel in das PKCS8-Format, das zum Import in die WatchGuard SSL 100 benötigt wird. Hier wird auch nach einem Encryption Password gefragt, das ebenfalls für den Import benötigt wird.
Die mit dem zweiten Befehl erzeugte Datei “wgnet.csr” wird nun an die Zertifizierungsstelle geschickt, für die man sich entschieden hat. Ein möglicher, sehr preiswerter Anbieter ist RapidSSL, der einfache SSL-Zertifikate bereits für 10,95 USD pro Jahr anbietet. Nach Beantragung und Legitimation erhält man innerhalb von 24 Stunden dann per E-Mail sein Zertifikat zugestellt.

Nach der Anmeldung an der Admin-Oberfläche der SSL 100 werden Zertifikat und privater Schlüssel importiert: Manage System > Certificates > Add Server Certificate (sslvpn.kundenname.de) > Publish; Manage System > Administration Service > Server Certificate (sslvpn.kundenname.de) > Publish und Restart Service; Manage System > Device Settings > General Settings (sslvpn.kundenname.de) > Publish. Nun wird beim Zugriff auf die SSL 100 das eigene Zertifikat verwendet und die Warnmeldung des Browsers unterbleibt. Anstelle einer öffentlichen Zertifizierungsstelle kann der CSR auch an eine firmeninterne (z.B. Active Directory integrierte) Zertifizierungsstelle geschickt werden. Die Warnmeldung unterbleibt dann jedoch nur auf den PCs, die z.B. als Domänenmitglied das Stammzertifikat “gelernt” haben.
WICHTIG: Die mit OpenSSL erzeugten Dateien, die verwendeten Kennwörter, die Zugangsdaten zu dem Accout der Zertifizierungsstelle und das Zertifikat sind auf jeden Fall SICHER auzubewahren und vor Zugriff von Dritten zu schützen!

SSL 100: One Time Password per SMS

1 Comment

Die einfachste Form der User Authentication an einer WatchGuard SSL 100 ist die Kombination aus Benutzername und Kennwort, WatchGuard SSL Password. Die User und Kennwörter können auf der SSL100 selbst gepflegt werden oder es erfolgt ein Mapping zu einer externen Benutzerdatenbank, z.B. einem Active Directory. Damit nicht die unbefugte Weitergabe der Zugangsdaten an Dritte die Sicherheit der internen Daten und Programme gefährdet, kann eine zweite Komponente die Sicherheit erhöhen: eine Two-Factor Authentication, also die Kombination aus Wissen und Besitz oder Biometrie). Neben der Kenntnis von Benutzername und Kennwort ist auch noch eine zweite Komponente erforderlich, z.B. ein OTP Token als Schlüsselanhänger, der zeitgesteuert z.B. alle 60 Sekunden eine neue 6-stellige Zahl anzeigt, die bei der Anmeldung zusätzlich abgefragt wird. Hersteller sind u.a. RSA und VASCO. Alternativ ist es auch möglich, das Einmal-Kennwort per E-Mail (z.B. an BlackBerry Handhelds, iPhone oder andere Mobile E-Mail Devices) zu versenden – oder per SMS auf ein beliebiges Mobiltelefon.
Wenn das One Time Password (OTP) per SMS versendet werden soll, bedient man sich in der Regel eines SMS-Providers, bei dem man ein gewisses Kontingent an SMS einkauft. Ein möglicher Anbieter ist Clickatell. Nach der Aktivierung eines Accounts und dem Kauf eines SMS-Kontingents (hier 400 SMS für 17,60 EUR = 4,4 ct pro SMS) bekommt man von Clickatell drei Zugangsinformationen zugewiesen: USERNAME, PASSWORD und API_ID. Diese drei Angaben ersetzen die Platzhalter in folgender URL: https://api.clickatell.com/http/sendmsg?user=USER&password=PASSWORD&api_id=API&to=[$user-mobile]&text=[$message].
In der Konfiguration der WatchGuard SSL100 wird diese URL an folgender Stelle eingetragen: Manage System > Notification Settings > SMS Channel > Add SMS Channel > Plugin = HTTP-Plugin > URL > Save > Save (!!!) > Publish (!!!)
Außerdem muss sichergestellt sein, dass WatchGuard SSL Mobile Text generell als Authentication Methode enabled ist und auch in den entsprechenden Userkonten, die dieses Verfahren nutzen sollen. Dort muss ebenfalls die Mobilfunknummer eingetragen werden, an die die SMS geschickt werden soll (hier im Format 49171xxxxxxx). Die Nutzung des SMS-OTP macht natürlich nur dann Sinn, wenn in den betreffenden User-Accounts die Anmeldemethode WatchGuard SSL Password disabled wird, denn sonst wäre ja nach wie vor die einfache Anmeldung nur mit Benutzername und Kennwort möglich. Beim Aufruf der Anmeldeseite wählt der User also WatchGuard SSL Mobile Text aus und meldet sich zunächst mit seinem regulären Benutzernamen und Kennwort an:

Dadurch wird die Erzeugung des SMS-OTP angestoßen und wenige Sekunden später kommt eine SMS an. Als Absender der SMS tritt bei Clickatell eine +44 Nummer in Erscheinung, da das Gateway wohl in Großbritannien betrieben wird. Der Standard-Text der SMS lautet: Your OTP is xxxxxx. Enter it to login with Mobile Text. Anschließend steht die gewohnte Portaloberfläche mit den freigegebenen Icons zur Verfügung.

Abkündigung der Firebox X e-series zum 31.12.2010

Comment

WatchGuard wird den Verkauf der Firebox X e-Series am 31.12.2010 einstellen. Bereits seit einigen Monaten empfehle ich allen meinen Kunden, statt einer Firebox X e-series ein Produkt aus den neuen Gerätefamilien XTM 2, XTM 5, XTM 8 oder XTM 1050 zu kaufen. Die Nachfolgeserien verfügen jeweils über doppelt so viel Hauptspeicher und schnellere CPUs als die vergleichbare X e-series und sind daher auch vom Investitionsschutz-Gedanken her für eine längere Einsatzdauer geeignet.
Dennoch brauchen Kunden mit einer Firebox X e-series nicht befürchten, ab dem nächsten Jahr im Regen zu stehen. Das End-Of-Life Datum ist erst in 5 Jahren, am 31.12.2015. Bis zu diesem Endtermin können Live Security und UTM Services verlängert werden. Auch Software-Updates werden bereit gestellt, wobei neue Funktionen jedoch teilweise nur für die neuen XTM Geräte-Generationen freigeschaltet werden können – wie bereits jetzt im Fall des neuen Features “RED” (Reputation Enabled Defense).
Ich hatte die WatchGuard End-of-Life Policy bereits hier einmal ausführlicher beschrieben: http://de.watchguard-blog.com/2009/07/end-of-life-datum-25102009.html.

Command Line Interface (CLI) auf Port 4118 tcp

1 Comment

WatchGuard Firebox e-series und XTM Systeme mit Software 10.x oder 11.x bieten auch die Möglichkeit der Administration und Programmierung im Kommandozeilenmodus (CLI). Ausnahme: X Edge e-series mit v10.x. Hierzu läuft auf der WatchGuard ein SSH-Daemon, der auf Port 4118 tcp hört. Dieser Port ist Bestandteil der standardmäßig im Regelwerk enthaltenen Firewall-Regel “WatchGuard”, die ebenfalls standardmäßig den Zugriff auf die “Firebox” von “Any-Trusted” und “Any-Optional” ermöglicht. Das From-Feld dieser Regel kann natürlich auch so erweitert werden, dass der Zugriff über das Internet oder für mobile User möglich wird (Sicherheitsüberlegungen berücksichtigen!).
Das CLI kennt wie das WebUI zwei User: status und admin. Zu status gehört immer das lesende Kennwort der Firebox (status passphrase). Zu admin gehört immer das schreibende Kennwort der Firebox (configuration passphrase).
Wenn Sie nun über einen SSH-Client (z.B. PuTTY) eine SSH-Verbindung zu Port 4118 öffnen und sich als admin an der Firebox anmelden, können Sie dort zunächst durch die Eingabe eines Fragezeichens (?) eine Übersicht der verfügbaren Befehle anzeigen lassen:

Hier findet sich unter anderem auch der Befehl “reboot”, über den die Firebox durchgebootet werden kann. Gerade bei Fireboxen mit v10.x ist dieser Einstieg manchmal “der letzte Rettungsanker”, wenn durch Memory Leak Effekte der Hauptspeicher auf der Firebox zugelaufen ist und die Firebox in Folge den Daemon abgeschaltet hat, über den sich der WSM mit der Firebox verbindet…
Ebenfalls sehr hilfreich ist der CLI-Befehl “ping”, der es ermöglicht, pings direkt von der Firebox aus zu verschicken.
Theoretisch kann über das CLI auch eine weitgehende Administration des Gesamtsystems erfolgen, also auch Konfigurationsänderungen etc., jedoch kommt dies in der Praxis eher selten vor. WatchGuard bietet hierfür unter http://www.watchguard.com/help/documentation/xtm.asp eine umfangreiche PDF: die Command Line Interface Reference.

Fireware Pro wird unter Manage Products nicht korrekt angezeigt

Comment

Bei registrierten WatchGuard X Edge, X Core und X Peak e-series Produkten wird momentan bei “Your Activated Products” in der Anicht unter Manage Products das Vorhandensein der Fireware Pro Option nicht korrekt angezeigt. Der Screenshot zeigt, dass die Fireware Pro angeblich “not activated” ist:

Im Feature Key ist aber ersichtlich, dass die Fireware Pro trotzdem korrekt aktiviert ist:

Serial Number: 908660xxxxxxx
License ID: 908660xxxxxxx
Name: Created Aug-27-2010 13:33
Model: X550e
Version: 1
Feature: AV@Mar-09-2012
Feature: AV_UPDATE@Mar-09-2012
Feature: IPS@Mar-09-2012
Feature: IPS_UPDATE@Mar-09-2012
Feature: WEBBLOCKER@Mar-09-2012
Feature: SPAMBLOCKER@Mar-09-2012;UC17Q63WEU2Q2Uxxxxxx
Feature: 3DES
Feature: INTERFACE#4
Feature: AV_SPEED#10
Feature: SESSION#25000
Feature: AUTHENTICATED_USER#250
Feature: AUTH_DOMAIN#5
Feature: FW_RULE#0
Feature: FW_PRO   <==== WICHTIG! Fireware Pro ist lizensiert!
Feature: FIREWARE
Feature: FW_SPEED#0
Feature: VPN_SPEED#35
Feature: BOVPN_TUNNEL#35
Feature: MUVPN_USER#25
Feature: LIVESECURITY@Mar-09-2012
Feature: MODEL#550e
Expiration: never
Signature: 4ebf-d8bc-xxxx-xxxx

X Core und Peak out-of-the-box auf 11.3.1 updaten

1 Comment

WatchGuard X Core und X Peak e-series Modelle werden auch heute noch ab Werk mit der Software-Version 10.2 ausgeliefert. Ich führe derzeit folgende Schritte aus, wenn ich die Produkte out-of-the-box auf die aktuelle Version Fireware XTM 11.3.1 updaten möchte (Voraussetzung: Dual-Install eines WSM 10.2.x und WSM 11.3.1 auf dem Installations-PC vorhanden, feste IP de PC z.B. 10.0.1.100/24, verbunden mit eth1 der Firebox):

  • Registrierung der Firebox im Live Security Account auf der WatchGuard Website (vorab).
  • Feature Key (Lizenzdatei) herunterladen und in einer Textdatei speichern (vorab).
  • Starten der Firebox in den Recovery Mode (Up-Arrow-Button gedrückt).
  • Ausführen des “Quick Setup Wizard” der WSM 10.2.x Installation und Befüllen mit Dummy-Werten (IP-Adresse des Trusted Interface jedoch nach wie vor auf 10.0.1.1/24 setzen, Feature Key importieren).
  • Nach dem Reboot der Firebox WSM 11.3.1 starten und “Connect to Device” (10.0.1.1).
  • Policy Manager der 11.3.1 starten
  • File > Upgrade; Configuration Passphrase eingeben und aktuelle utm_core_peak.sysa-dl auswählen (11.3.1); Meldungen durchbestätigen, kein Backup-Image speichern.

Ich habe festgestellt, dass ein direkter Update-Versuch einer Factory Default 10.2 Firebox über den “Quick Setup Wizard” des WSM 11.3.1 scheitert, weil der Installer nach ca. 2-3 Minuten an folgender Stelle hängenbleibt:

Danach geht es auch nach 10-15 Minuten nicht weiter und der Quick Setup Wizard 11.3.1 muss mit einer Fehlermeldung abgebrochen werden. Zum Erfolg führte dann in der Regel das weiter oben beschriebene Verfahren in einer Dual-Install-Umgebung.

WatchGuard WSM und Fireware XTM 11.3.1

1 Comment

Dies ist die Bugfix-Liste für die aktuellen Versionen WatchGuard System Manager (WSM) und Fireware XTM 11.3.1, die im Download-Bereich der WatchGuard-Webseite zur Verfügung stehen:

General

  • This release resolves an issue that caused the logging process on a Firebox or XTM device to crash. [55676]
  • This release resolves an issue that caused the Firebox or XTM device to crash when used with PPPoE. [43811]
  • Notification for blocked sites now works correctly. [45148]
  • The unlock.exe program now supports non-ASCII characters in the file name. [42599]
  • This release resolves an issue that caused authentication to fail with the log message: wgcgi timeout after prcs msg error. [44887]
  • Traffic and management connections no longer stop when you retrieve a support.tgz file from a Firebox or XTM device running under a heavy connection load. [44956]

Fireware v10.x to Fireware XTM v11.x Upgrade Issues

  • A problem that caused the error message “INTERNAL_ERROR: The element ‘backup-firebox-ip’ has a length of 19” to appear when you upgrade from Fireware v10.x to Fireware XTM v11.x has been resolved. [42653]
  • When you upgrade a centrally managed Firebox X Edge from v10.x to Fireware XTM v11.x, the traffic control, WebBlocker custom profiles, and the Allow all traffic trusted<->optional settings are now correctly preserved during the upgrade. [43712]
  • When you upgrade a Firebox X Edge from v10.x to v11.x, IKE Keep-Alive is no longer enabled during the upgrade if it was not previously enabled in your v10.x configuration. [44219]
  • A problem that caused a Management Server upgrade from Fireware v10.x to Fireware XTM v11.x to fail because of long managed alias names has been resolved. [44232]

Fireware XTM Web UI

  • You can now successfully open and use Bandwidth Meter from the Web UI with no syntax errors. [41911]
  • You can now successfully add WebBlocker exceptions from the Fireware XTM Web UI with no “Code 8: Error 9” error message. [43744]
  • The Fireware XTM Web UI login window now appears correctly when you use Safari on Mac OS X “Snow Leopard” without the need to refresh the browser. [42791]

WatchGuard System Manager

  • You can now successfully install WatchGuard System Manager when Microsoft SQL Server 2008 Management Studio is running on your computer. [44981]

WatchGuard Servers

  • Email released from the Quarantine Server is now correctly delivered to all recipients, instead of just the first recipient in the list. [43875]
  • The Quarantine Server can now handle the apostrophe character (‘) in email addresses. [56221]
  • The Quarantine Server can now handle the dash character (-) in email addresses. [45267]
  • The Quarantine Server automatic scheduled user notification no longer stops after 2-3 days with a pyadapter exception error. [56109]
  • A problem that caused the Report Server to occasionally fail to complete reports has been resolved. [45486]
  • The default log level for WatchGuard System Manager server applications has been set back to “Warning” instead of “Debug” to keep unnecessary log messages from accumulating. [56290]
  • The Reporting Web UI now works correctly after you upgrade WatchGuard Server Center from v11.2.x to v11.3.x [55879]
  • We have resolved an issue that caused Report Server instability when you generate the Denied Packet by Client report for a large set of log messages. [56344]
  • A problem that caused the WatchGuard Server Center restore function to sometimes fail to restore a backup file with an exception error has been resolved. [55984]
  • You can now use the Reporting Web UI to access archived reports when the report generation time on the Report Server is set to a time later than 12:00 pm. [56286]
  • The installation of WatchGuard Server components no longer fails with the error: “Management server failed during -unconfig mode 1”. [44238]
  • The Management Server no longer fails to start after you restore a backup file on a computer on which the log directory specified in the WatchGuard Server Center configuration does not exist. If the log directory path does not exist, the default directory path will be used. [44380]
  • The Log Server backup process no longer fails when you use a non-English OS and the default Log Server configuration settings. [44563]
  • The Management Server no longer fails after you restore a backup file created with WatchGuard Server Center v10.2.x to a v11.x Management Server. [43201]

Policy Manager

  • You can now successfully configure a bridge interface with a user-defined name. [55827]
  • You can now connect to and make configuration changes to a Firebox or XTM device running Fireware XTM v11.1 from a management computer running WSM v11.3.x. [55834]
  • The FTP proxy setting to restrict the maximum number of failed logins per connection now operates correctly. [55721]

Authentication

  • Web Server certificates are now correctly imported and displayed in Firebox System Manager. [55758]

Firecluster

  • The stability of an active/active FireCluster running under a heavy connection load has been improved. [55728]
  • The passive device in an active/passive FireCluster no longer becomes unreachable when you change the management IP address of the backup master. [56064]
  • In an active/active FireCluster, the Mobile VPN with SSL “Bridge VPN traffic” option now operates correctly. [40608]

Networking

  • DF settings are now available when your Firebox or XTM device is configured in drop-in or bridge mode, in addition to routed mode. This setting is available on the Advanced tab of an interface configured as External. [44258]
  • On the XTM 2 Series, traffic no longer fails across bridged interfaces when the bridge consists of Ethernet ports eth0-eth2 and eth3-eth5. [55737]
  • You can now configure the Firebox X Edge e-Series and XTM 2 Series devices to forward DNS queries. Note that you can only enable this feature with the CLI; it is not available in Policy Manager or the Web UI. [42709]
  • It is now possible to add up to 200 traffic management objects. [55796]
  • A previously expired connection can no longer be re-opened when traffic matching the expired session is received. [45286]
  • The blocked site limit has been increased from 154 to 1000. [40362]
  • If a WINS server address is not defined in the configuration, the Firebox or XTM device now keeps the WINS server address blank when using DHCP. [41622]
  • When using a dynamic NAT entry from one VLAN to another VLAN, the Source IP address is no longer the primary external IP address of the Firebox. [43838]
  • After a proxy connection is closed, the Firebox or XTM device continues to accept and drop lingering connections from the remote server for a short period of time. This is done to prevent “auto-block packets not handled” from occurring due to a late reply packet from the server for a closed connection. [43866]
  • 1-to-1 NAT now takes precedence when policy-based dynamic NAT is configured to use “Set source IP”. [44257]
  • A Gratuitous ARP is now issued when you change the MAC address in the Network Interface setting to “override MAC address”. [55799]
  • The Firebox or XTM device will now send a Gratuitous ARP (GARP) every hour for interface IP addresses. The GARP is performed each hour to make sure connected devices have correct ARP entries for the Firebox IP addresses. [55811]
  • The Firebox or XTM device now correctly supports the number of allowed authenticated users per model. [56012]
  • NAT loopback will now operate correctly when the connecting client uses a zero route branch office VPN tunnel. [45149]
  • Connection rate limiting now operates correctly for inbound traffic. [43023]

Proxies

  • We no longer support SSL v2 in the HTTPS proxy in order to better comply with PCI scans. [55908]
  • This release resolves an issue that caused attachments sent through proxies to become corrupted. [40829, 55736, 56207]
  • We have improved the stability of our proxy technology. These changes fix problems that caused some proxy processes to crash. [44786, 45209, 55601, 55663,55693,55794, 55813, 45458]
  • This release resolves an issue that caused AV scans to fail after reboot. [56043]
  • When an email is quarantined as spam by the SMTP proxy, a “200 OK” message is now sent to the sending server. [44224]
  • The H.323 ALG media channel timeout no longer causes calls to be dropped after 900 seconds. [44945]
  • The H.323 ALG now correctly deletes expired connections. [44573]

Security Services

  • This release resolves several problems that caused spamBlocker to crash. [43787, 44194, 44518]
  • This release resolves an issue that caused Internet Explorer to display “friendly HTTP error messages” instead of the WebBlocker deny message if the deny message did not have enough characters in it. [44893]
  • The RED daemon no longer crashes on the passive device in an active/passive FireCluster. [56141]
  • The IPS security service no longer adds IP addresses to the blocked sites list when it is configured only to drop traffic. [45281]
  • The WebBlocker Override feature now operates correctly with VLAN interfaces. [43632]

Logging

  • In proxy traffic log messages, the network interface name now appears correctly as the name you assign the interface and not as a network alias. [56243]
  • A Firebox or XTM device now generates a log message when the maximum number of concurrent packet filter connections has been reached. [41801]

Kein DYNDNS-Update bei VPN-Tunnel Routing 0.0.0.0/0

Comment

In manchen VPN-Projekten kommt es vor, dass nicht nur der netzinterne Verkehr von Außenstellen durch einen VPN-Tunnel zur Zentrale geroutet wird, sondern auch der gesamte Internet-Traffic. Dann können nämlich z.B. auch die möglicherweise nur in der Zentrale vorhandenen UTM Security Services (WebBlocker, spamBlocker, Gateway Antivirus, Intrusion Prevention Services, Reputation Enabled Defense) auf den Internet-Verkehr der Außenstellen angewendet werden, wo möglicherweise nur WatchGuard Firebox Produkte mit Live Security eingesetzt werden.
Dabei muss natürlich berücksichtigt werden, dass über die Internet-Leitung in der Zentrale eben auch der komplette Internet-Traffic der Außenstelle(n) läuft – und das nicht nur einmal, sondern DOPPELT (aus dem Internet in die Zentrale und weiter über den VPN-Tunnel in die Filiale).
Im Branch Office VPN Tunnel wird dies häufig über die Verwendung der BOVPN Tunnel Route Local Network <-> 0.0.0.0/0 realisiert.
Wenn in der Außenstelle jedoch keine feste IP-Adresse existiert, sondern mit einem DYNDNS-Hostname gearbeitet wird, führt dies gerade in Verbindung mit dem WatchGuard Management Server zu Problemen. Der auf der WatchGuard laufende DYNDNS-Updater meldet eine Adressänderung nämlich per http an einen Webserver von DYNDNS. Dieser http-Verkehr wird jedoch von der Firebox oder XTM Appliance nicht direkt ins Internet hinaus geroutet, sondern durch den 0.0.0.0/0 Tunnel zunächst in die Zentrale geschickt und von dort aus weiter zu DYNDNS. Das hat aber zur Folge, dass die “gemeldete” IP-Adresse nicht zu der Quell-IP-Adresse passt, von der die Meldung bei DYNDNS eingeht. DYNDNS verweigert daher das Update des DNS-Eintrags, und der WatchGuard Management Server und die am VPN-Tunnel beteiligte zentrale Firebox haben ein Problem, die Außenstelle zu “finden”.
In einem solchen Fall sollte die Außenstelle in einen Internet-Tarif wechseln, bei dem eine feste öffentliche IP-Adresse möglich ist.

WatchGuard XTM 2 wird warm

Comment

Die aktuellen WatchGuard XTM 21, XTM 22 und XTM 23 Appliances werden im laufenden Betrieb recht warm. Einige Kunden sorgen sich daher über die dauerhafte Zuverlässigkeit. Ich darf folgendes Original-Zitat des PM wiedergeben:

“The 2 Series enjoys a more powerful set of components than were available at the time of Edge development. These components produce more heat that must be dissipated out the 2 Series case. Part of the design of the case is to use the bottom plate as a heat sink, in order to move the heat away from critical components. As such, the user may sense that the bottom plate, or the case overall, is warm or hot to the touch. This is expected, and even desirable to keep the product running in optimal fashion for the entire product life. It is within specifications for this device, and a similar heat output to many laptop computers and power supplies sold into consumer markets.
There is actually a KB article on the 2-Series wireless ‘heat’. Also in the wireless version, we’ve put more powerful, heat producing components in this design as compared with Edge, and we use the bottom plate as a heat sink, which actually siphons the heat away from the sensitive components and keeps your equipment running properly. You know it’s doing its job if it’s warm. Also, it’s been tested many times and is within engineering tolerance.”

Laut WatchGuard ist die Wärmeentwicklung also kein Grund zur Besorgnis. Ich empfehle jedoch darauf zu achten, dass die Wärmeabfuhr über die Unterseite des Geräts nicht behindert wird: Stellen Sie die XTM 2 NICHT oben auf ein anderes Gerät, das ebenfalls warm wird wie z.B. ein DSL-Modem oder einen DSL-Router. Wenn die XTM 2 in einem sehr kleinen abgeschlossenen Gehäuse oder Schrank betrieben werden soll, prüfen Sie bitte ob auch die Wärmeabfuhr aus diesem Schrank heraus gewährleistet wird. Und schützen Sie das Gerät vor direkter Sonneneinstrahlung, die das Gerät nur zusätzlich aufheizen würde…

Logging Datenbank unter 11.3 hat jetzt feste Größe

Comment

Nach einem Auslandsprojekt und etwas Urlaub nun neuer Input: Wer sich gewundert hat, warum im WatchGuard Server Center 11.3 unter “Logging Server” nicht mehr die bisher üblichen Angaben zu finden sind, nach wie vielen Tagen die alten Daten gelöscht werden sollen bzw. nach Erreichen von wieviel Prozent der maximalen Datenbank-Größe eine Notification E-Mail an den Administrator zu senden ist, sei beruhigt: in der Version 11.3 ist die Angabe “Database Size” tatsächlich die Maximalgröße der Datenbank. Bei Erreichen von 95% dieser Größe werden ältere Daten automatisch gelöscht. Es gibt keine Notifications mehr. Wenn also aufgrund von Unternehmensrichtlinien eine entsprechende Anzahl von vorzuhaltenden Tagen verbindlich ist, müsste dies im Rahmen der Datenbankgröße und des anzuwendenden Backup-Konzepts aufeinander abgeglichen werden. Hier bietet sich das freie Tool “pgadmin” an, mit dem u.a. auch zeitgesteuerte Datenbank-Dumps geplant werden können.