Tag Archives: SSL VPN

XTM 330 soll HA (Cluster) fähig werden

Comment

Die Watchguard XTM 330 wird ab Werk bereits mit dem XTM Pro Upgrade und den damit verbundenen Funktionserweiterungen wie Multi-WAN, Policy Based Routing, Dynamic Routing, QoS und der Maximalzahl der vorgesehenen 55 SSLVPN-User ausgeliefert. Bei den größeren Modellen ab XTM 5 aufwärts ist bei XTM Pro auch die Cluster-Fähigkeit (HA) in den Versionen Active/Active und Active/Passive enthalten.
Derzeit wird jedoch bei der XTM 330 kein HA (Cluster) unterstützt!
In einer der künftigen Softwareversionen soll jedoch die Clusterfähigkeit auch für die XTM 330 freigeschaltet werden!

RSA SecurID Appliance verweigert User Authentication wegen falscher Systemzeit

Comment

Vor ein paar Wochen hatte ich den Fall, dass ein Kunde eine RSA SecurID Appliance (v3.0) zur Two-Factor Authentication seiner WatchGuard Mobile User VPN Verbindungen nutzen wollte. Trotz vermeintlich korrekter Konfiguration sowohl der WatchGuard XTM 510 als auch der RSA Appliance wollte es partout nicht klappen. Die eigentliche Ursache kam erst fast zufällig in einem Support Call mit RSA ans Tageslicht: weil NTP (Network Time Protocol), also der automatische Zeitabgleich mit Zeitservern im Internet auf der RSA Appliance fehlerhaft konfiguriert war, hatte die RSA Appliance eine um etwa 12 Stunden falsche Systemzeit, was eben zur Ablehnung der Usereinwahlen geführt hat… Mit korrekter Systemzeit auf der RSA Appliance war dann “alles gut”…

Begrenzter Zeichensatz bei Active Directory Authentication

Comment

Puuuuh, nach mehr als einem halben Jahr komme ich endlich mal wieder dazu, hier einen Beitrag zu schreiben. Ich will nicht klagen, es waren einfach sehr viele und anspruchsvolle Projekte in den letzten Monaten. In den nächsten Wochen hoffe ich nun, hier wieder einige hilfreiche Postings schreiben zu können.

Ich fange mit einem “alten Schuh” an, allerdings in einer etwas anderen Ausprägung. Ich habe bereits ja empfohlen, sich in der WatchGuard XML Konfigurationsdatei, und insbesondere bei Passwörtern, Pre-Shared Keys etc. auf den Zeichensatz US-ASCII 7 zu beschränken, d.h. also insbesondere auf die Verwendung von äöüß und Sonderzeichen zu verzichten. Ich empfehle sogar, Kennwörter etc. gänzlich nur aus den klassischen Buchstaben A-Z, a-z und den Ziffern 0-9 zu bilden. Ganz ohne Sonderzeichen, lieber ein paar Stellen mehr…

Wenn nun User Authentication gegenüber Active Directory im Spiel ist, sollte diese Grundregel auch beherzigt werden, wenn die User ihre AD/Windows-Kennwörter festlegen. Ein Kunde berichtete von MUVPN-Einwahl-Problemen bei einem bestimmten User. Dieser hatte ein €-Zeichen in seinem Windows-Kennwort. Die Einwahl schlug fehl. Nach Änderung des AD/Windows-Kennworts (ohne €-Zeichen) war die Einwahl erfolgreich!

Der Kunde hat mir freundlicherweise eine Liste von Zeichen geschickt, die in einem AD/Windows-Kennwort vorkommen dürfen, damit eine MUVPN-Einwahl / User Authentication erfolgreich ist:

!#$%&()*+,-.0123456789:;<=>@ABCDEFGHIJKLMNOPQRSTUVWXYZ[]_abcdefghijklmnopqrstuvwxyz{} und das “Leerzeichen”…

Diese Einschränkung dürfte dann auch gelten, wenn die Einwahl bzw. Authentication per PPTP-VPN (i.V. mit RADIUS), SSL-VPN (AD oder RADIUS) und auch in Verbindung mit Two-Factor Authentication Systemen wie VASCO oder RSA gegenüber AD erfolgt!

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…

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.

SSL 100 Feature Key wrong

Comment

Bei der Inbetriebnahme einer WatchGuard SSL 100 SSL-VPN Appliance musste ich heute feststellen, dass der nach Produkt-Registrierung auf der WatchGuard Website heruntergeladene Feature Key korrupt war und die SSL 100 sich mit dem Fehler “Wrong Feature Key” verweigerte. Anders als bei den klassischen WatchGuard Produkten steckt in einem SSL 100 Feature Key u.a. auch der Firmenname und die E-Mail-Adresse des Ansprechpartners, so wie sie im betreffenden Account hinterlegt sind. Wurden bei der erstmaligen Erzeugung des Accounts im Firmennamen Sonderzeichen, Umlaute etc. verwendet, kann dies zu diesem Fehlerbild führen. Im vorliegenden Fall war das &-Zeichen der Übeltäter (eine GmbH & Co. KG…)
Leider kann man den Firmennamen im Account NICHT selbst ändern. Hierzu muss ein Support Incident geöffnet werden oder die Customer Care Abteilung in USA anderweitig informiert werden. Diese entfernt dann verdächtige Zeichen aus der Datenbank. Dieses Verhalten ist von WatchGuard als Bug bestätigt, es gibt aber noch keine Aussage, wann dieser Fehler beseitigt wird.

Fireware XTM v11 und Windows 2000 Active Directory User Authentication

3 Comments

Die Release Notes von WSM und Fireware XTM v11 enthalten den lapidaren Satz “We no longer support Microsoft Windows 2000”. Eine damit zusammenhängende Erscheinung hat mir die Tage etwas Kopfzerbrechen beschert: User Authentication gegenüber einer nativen Windows 2000 Domäne. Nach dem Upgrade von WSM/Fireware 10.2.7 auf 11.2.1 funktionierte sowohl die Web Authentication über Port 4100 nicht mehr (“user name or password invalid”) als auch die MUVPN-Einwahl über den IPSec-Client (“admd ADM auth Firewall user [xxxxx@Active Directory] Error, Reason – Generic error id=”1100-0012” bzw. “wgcgi Firewall user xxxxx@Active Directory from [IP] rejected – all other error”).
Das liegt daran, dass eine Firebox mit Fireware XTM v11 “anders” in das Active Directory abfragt als die bisherige Fireware 10. Zum Auslesen von Gruppenmitgliedschaften werden jetzt tokenGroups_get Abfragen ins AD gestellt. Damit kann ein natives Windows 2000 Active Directory aber noch nichts anfangen. Erst ein Windows 2003 Domänencontroller kommt damit zurecht. Natürlich sollte heutzutage die AD-Migration kein Problem mehr sein, will aber natürlich trotzdem gut vorbereitet sein. Für die Übergangszeit kann daher mit einem Trick gearbeitet werden, der zwar nicht offiziell supported wird, aber trotzdem funktioniert: anstelle der direkten Active Directory Authentication auf LDAP umstellen – mit ansonsten identischen Einstellungen:

In der Pulldown-Liste von Login Attribute findet sich bei LDAP jedoch nicht das klassische Windows-Attribut sAMAccountName. Dies kann dort aber händisch über die Tastatur eingegeben werden… Natürlich müssen dann ggfs. noch die in Firewallregeln verwendeten Gruppennamen unter Setup > Authentication > Authorized Users and Groups nachgezogen werden. Und unter VPN > Mobile VPN muss auch an den entsprechenden Stellen von Active Directory auf LDAP umgestellt werden.

SSL VPN Probleme nach Update von 11.1 auf 11.2

1 Comment

In einem aktuellen Supportfall hatte der Kunde seine Firebox X550e von Fireware XTM v11.1 auf 11.2 upgedated. Anschließend konnten die mobilen User über den WatchGuard SSL VPN Client 11.1 keine Verbindung mehr herstellen. Fehlermeldung: “Could not download the configuration file…”.
Ich vermute einen Zusammenhang mit der fehlerhaften Migration der integrierten WatchGuard-eigenen SSL-Zertifikate. Neben den gültigen SSLVPN-Zertifikaten (“Signed”) befinden sich im Zertifikatsspeicher noch weitere Zertifikate im Status “Pending”, die offenbar die gültigen Zertifikate behindern.

Die “Pending” Zertifikate können wie folgt gelöscht werden: Per WSM mit der Firebox verbinden, den Firebox System Manager starten, dort View > Certificates, Pending-Zertifikate anklicken und “Delete”. Anschließend Reboot der Firebox. Handelt es sich um einen Cluster, müssen beide Boxen zur gleichen Zeit ausgeschaltet werden!

SSL-VPN Client 11 läuft nicht in Verbindung mit Fireware 10.x

Comment

Es freut mich sehr, dass mein Blog eine ansehnliche Zahl von WatchGuard-Usern erreicht. Sinn und Zweck dieser Institution ist natürlich auch, meine eigene Expertise in diesem Umfeld darzustellen und auf diese Weise konstruktive Kundenkontakte anzubahnen – unbestritten! Umsonst ist der Tod, und der kostet bekanntlich das Leben! Es entsteht jedoch auch ein interessanter Dialog, wie sich an diesem Beitrag von Michael Schramm zeigt, der mich per E-Mail erreicht hat und den ich hier gerne wiedergeben möchte – ungeprüft, da ich genau die beschriebene Konstellation noch nicht “vor der Flinte” hatte :-). Michael Schramm schreibt:

“Der aktuelle WatchGuard SSLVPN-Client in der Version 11.1 funktioniert nicht mit einer 10er-Fireware. Dies ist leider in den Release Notes nirgends erwähnt – jedenfalls konnte ich keinen entsprechenden Hinweis finden. Öffnet man den Client direkt mit einem passenden Configfile (*.wgssl), erscheint beim Connecten eine irreführende Fehlermeldung: Die Softwareversion auf dem Gerät (1.x) ist kleiner als die Version des Clients (5.x), und man soll auf Yes klicken, um die neue Softwareversion herunterzuladen. Das klappt natürlich nicht und der Client springt dann nach einiger Zeit wieder zurück zur Login-Maske. Der automatische Download des Config-Files funktioniert ebenfalls nicht, da sich in der Fireware XTM 11.x offensichtlich der Pfad zu diesem File geändert hat. Der 11er-Client fragt bei der Firebox nach dem File

https://FIREBOX:4100/?action=sslvpn_download&fw_username=USERNAME&fw_password=PASSWORD&filename=client.wgssl

und bekommt daraufhin von der Firebox “401 unauthorized” zurück (im Logfile des Clients: FAILED, Access denied), während der alte 10er-Client nach diesem File fragt:

https://FIREBOX:4100/?action=sslvpn_download&username=USERNAME&password=PASSWORD&filename=client.wgssl

und dieses dann auch bekommt – man kann es sogar manuell mit einem Browser herunterladen. Das “fw_” vor Username und Password gab es also in der alten Version noch nicht.

Allen Benutzern, die also unter Windows 7 Probleme mit dem 10er-Client haben und deswegen den 11er-Client benutzen wollen, kann von dieser Idee nur abgeraten werden, solange auf der WatchGuard Firebox noch eine Fireware 10.x läuft.

Der 10er-Client funktioniert im übrigen bei mir unter Windows 7, nativ und ohne Kompatibilitätsmodus, einwandfrei! Falls es also mit dem 10er-Client unter Windows 7 zu Problemen kommt, liegt das schätzungsweise eher an etwas anderem. Ich hatte z.B. konkret das Problem, dass sich der Client immer nur sporadisch und völlig ohne erkennbares Muster connecten ließ. Des Rätsels Lösung war ein falsch konfigurierter Switchport für das entsprechende WAN-Interface auf der Secondary Firebox [Anm. BO: in einem Cluster!]. Die Ports auf beiden Fireboxen stehen auf 100FDx, der entsprechende Switchport stand auf Auto und hat sich dann immer auf 100HDx eingependelt. Deswegen konnte ich mich immer dann nicht verbinden, wenn gerade die Secondary Firebox die aktive war…”

Soweit Michael Schramm! Vielen Dank für diesen konstruktiven Beitrag. Ergänzend zum letzten Absatz von mir noch einmal der Hinweis auf einen meiner früheren Beiträge: http://de.watchguard-blog.com/2008/12/verbindungsprobleme-wegen-ethernet.html: Lassen Sie möglichst ALLE Interfaces der WatchGuard Firebox auf “Auto Sensing” – und sorgen Sie NUR bei offensichtlichen Kompatibilitätsproblemen zunächst dafür, dass das direkt an der WatchGuard Firebox angeschlossene Ethernet-Device (Switch/Router) auf einen festen Wert eingestellt wird…

Bugfixes in WatchGuard WSM und Fireware XTM 11.1

Comment

Die Versionen Fireware XTM v11.1 und WSM v11.1 beheben eine Reihe von Bugs und Known Issues früherer Versionen. Diese Aufstellung wurde den aktuellen Release Notes der Version 11.1 entnommen. Obwohl man aufgrund der Vielzahl eventuell auf den Gedanken kommen könnte, dass das Produkt sehr fehlerlastig ist (bzw. war), sehe ich diese offene Kommunikation hingegen sehr positiv. Die meisten anderen Hersteller geben kaum vergleichbare Informationen heraus, sondern werkeln eher im Hintergrund. Zudem zeigt sich, dass das Produkt “lebt” und intensiv weiterentwickelt wird. Auch schon in den Versionen 11.0.1 und 11.0.2 war das Produkt ausreichend stabil, auch wenn ich meinen Kunden anfangs eher zur Zurückhaltung geraten habe!

General

  • The WSM Quick Setup Wizard now allows you to enter a feature key that contains a model upgrade for Edge e-Series. [40405]

  • Fireware XTM v11.1 resolves a cross site scripting vulnerability found in the web server used with the authentication applet. [40332]

  • Fireware XTM v11.1 resolves a cross site scripting vulnerability found in the WatchGuard servers’ Apache HTTP server implementation. [40581]

  • The lighttpd version used by Fireware XTM has been upgraded to v1.4.22 to resolve several reported vulnerabilities. [38808]

  • The ISC DHCP server version has been upgraded to v4.1.0p1 to resolve several reported vulnerabilities. [40032]

  • HostWatch now shows VLAN traffic. [40401]

  • You can now right-click in Firebox System Manager > Traffic Monitor to add an IP address to the blocked sites list. [40488]

  • ServiceWatch now correctly displays bandwidth for auto-generated BOVPN policies created by the WatchGuard Management Server. [40364]

Authentication

  • The Authentication redirect feature now works when you use a wireless guest network on the Firebox X Edge e-Series. [40029]

  • This release resolves an issue that causes Active Directory authentication to fail with the following log message: user=”test1″ domain=TESTQAWIN2K30. [40786]

Proxies

  • You can now enable notification for Application Blocker. [40422]

  • Application Blocker has been enhanced to add support for Winny, a popular peer to peer application used in Japan. [35027]

  • You can now unlock a file with an “&” in the file name with the unlock.exe utility. [40718]

  • This release resolves several reported issues in which certain web applications did not work through the HTTP Proxy. [40293] [38121] [40392]

  • This release resolves an issue that caused FTP proxy traffic to stop after a multi-WAN failover. [37965]

Subscription Services

  • Subscription services now update when you use an internal HTTP proxy server. [40517]

  • WebBlocker override now works on Firebox X e-Series devices configured in Bridge Mode. [39283]

  • The Quarantine Server client now accepts firstname.lastname@domain.com email format. [39743]

Networking

  • You can now use either Policy Manager or the Web UI to add multicast addresses in a policy. [39947, 39948]

  • If you enable a network interface and change the Interface Name (Alias) at the same time you enable the interface, the interface now becomes active without the need for a reboot.[39815]

  • When you use multi-WAN, DNS servers with static IP addresses on WAN 1 are now used even when other external interfaces use DNS servers from an ISP through PPPoE or DHCP. [40322]

  • DHCP relay through a branch office VPN tunnel now works. [40844]

  • You can now change the MTU of an external interface configured with PPPoE. [40705]

  • The DHCP server now works when there are multiple VLANs in the configuration. [40556]

  • Server Load Balancing now works when the internal server IP addresses are on different subnets. [41041]

  • We have made enhancements to the Server Load Balancing server status detection mechanism. [40300] [40519]

  • The Server Load Balancing Stickiness function has been improved to maintain a sticky connection state until the idle timeout is reached. [40297]

  • Static MAC address binding now works when your device is configured in Bridge Mode. [40665]

  • This release resolves an issue that prevented some Windows computers from getting an IP address via DHCP when your device is configured in Drop-In Mode. [40184]

  • The Blocked Ports and Blocked Sites features now apply only to traffic on an external interface. [39918]

Multi-WAN

  • Several multi-WAN issues related to PPPoE and branch office and Mobile VPN have been resolved. [40007]

  • Multi-WAN now works when the source IP address for incoming traffic is on the same network subnet as one of the external interfaces of the Firebox. [41026]

  • This release resolves an issue that caused the external interfaces to become inactive when you used multi-WAN configured in Round-robin mode. [40357]

FireCluster

  • Firebox devices with a model upgrade in the feature key can now join a FireCluster. [39370]

Branch Office VPN

  • The choice of Any has been removed from the Tunnel Route Settings Local and Remote drop-down menu. The Web UI now shows “any (0.0.0.0/0)”. [40409]

  • This release resolves an issue that caused the IKED process to crash and all IPSec tunnels to fail. [40442]

Mobile VPN

  • The Windows SSL VPN client has been updated to support Windows 7 and Windows 64-bit operating systems. [39841]

  • This release resolves an issue that caused SSL VPN to fail to connect after an upgrade from v10.2.x to v11.0.x. When this problem occurred, the SSL VPN client logs showed: sslvpn State: initialization of prerequisites Debug. [40408]

  • This release resolves several reported vulnerabilities in the SSL VPN client for Mac. [40292]

  • Mobile VPN with PPTP and SSL now continue to work when the LiveSecurity subscription is expired in your Firebox feature key. [41045]

  • When you disconnect the Mobile VPN with SSL client from one Firebox and then connect to a different Firebox, the SSL VPN profile is now updated to show the new connection. [41052]

  • The Mobile VPN with IPSec v11.1 client supports Windows 7 (32-bit and 64-bit) and contains additional bug fixes.

Web UI

  • You can now export your device configuration with the Web UI. [35234]

  • The Web UI now prevents the use of custom SSL VPN ports that conflict with ports used by the Firebox. [39382]

Policy Manager

  • The Firebox no longer becomes unresponsive if you use more than 28 characters in a proxy policy name. [40679]

  • The alias “Firebox” is now treated the same as other aliases the Firebox determines policy precedence. [38891]

Management Server

  • When a Firebox is in Full Management Mode and you clear the Enable TCP Syn Checking check box, TCP Syn Checking is now correctly disabled. [40853]

  • When a Firebox is under centralized management, an update from the WatchGuard Management Server no longer overwrites any blocked sites configured manually on the Firebox. [40312]

  • You can now right-click on a device and add that device to a folder. [36077]

  • The ability to schedule a reboot time is now available from the Management Server. [38230]

  • You can now perform a mass update of managed devices to force all selected appliances to check for a configuration update. [36958]

  • The Management Server now sorts the IPSec-action-list and abs-ipsec-action-list for tunnels created by the Management Server. The IPSec actions for Manual BOVPN tunnels are left in the order sorted by the user. Manual tunnels are always placed at the top of the list, followed by the sorted list of the tunnels created by the Management Server.

  • For each firewall policy template in use, there is now a single firewall policy created in the appliance configuration. As an example, if you have three tunnels (to different endpoints) that all use the same firewall policy template, there is a single firewall policy with the attributes set in the template. If there are two firewall policy templates in use, then two firewall policies are created. [38877]

Report Server

  • If you use an IIS server to serve published reports, you no longer get an error about missing files. [39319]

Log Server

  • The performance of the LogViewer Search function has been improved in v11.1. To facilitate the performance improvements, a log database migration will occur when you upgrade from v11.0.x to v11.1. During the migration, all log messages generated for a particular device are not visible until the migration is finished. [38833]

Certificates

  • You can now import a CRL in DER format into Firebox System Manager. [36643]

  • This release resolves a memory leak that occurred when you used 3rd-party certificates on the Firebox and kept WatchGuard System Manager or Firebox System Manager connected. [41008]

  • WatchGuard System Manager and Firebox System Manager no longer display the certificates status as valid even if a certificate is invalid. [40378]