Category Archives: Technischer Blog

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:


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