Tag Archives: Policy Manager

Webinterface nun auch bei X Core und X Peak

Comment

Eine der wesentlichen Neuerungen bei der Fireware XTM (Version 11) ist, dass sich nun auch die größeren Modelle der X Core und X Peak Geräteserien über ein Webinterface (auch “WebUI” genannt)administrieren lassen. Von “innen” ist das Webinterface erreichbar über https://IP-der-Firebox:8080. Die Anmeldeseite kennt zwei vordefinierte Usernamen: status und admin. Zu dem User “status” gehört die Status Passphrase (das lesende Kennwort), zu dem User “admin” die Configuration Passphrase (das schreibende Kennwort). Wenn Sie vorhaben, Änderungen am Regelwerk vorzunehmen, müssen Sie sich als User “admin” anmelden! Die Fireware XTM lässt aber zu einem Zeitpunkt nur genau EINE admin-Sitzung zu! Wenn Sie die Firebox über das Internet, sprich von “außen” administrieren wollen, müssen Sie die entsprechende automatisch hinzugekommene Regel für Port 8080 auch für externe IP-Adressen öffnen – hierbei sollte allerdings eher nicht einfach “Any-External” mit in das From-Feld aufgenommen werden, sondern besser nur einzelne, feste IP-Adressen, von denen aus die Administration gestattet werden soll.
Das Webinterface (WebUI) der Fireware XTM unterstützt jedoch nicht alle Funktionen, die über den Policy Manager des WSM nutzbar sind. WatchGuard hat hierzu eine Liste der nicht unterstützten Funktionen in den Release Notes der Fireware XTM (Version 11) bereitgestellt:

The Fireware XTM Web UI does not support the configuration of some features. These features include:

  • FireCluster
  • Full proxy configuration options
  • The editing of static NAT rules
  • Manual policy precedence
  • Certificate export
  • You cannot enable diagnostic logging or change diagnostic log levels
  • You cannot turn on or off notification of BOVPN events
  • You cannot add or remove static ARP entries to the device ARP table
  • You cannot save a device configuration file to your local computer
  • You cannot get the encrypted Mobile VPN with IPSec end-user configuration profile, known as the .wgx file. The Web UI generates only a plain-text version of the end-user configuration profile, with file extension .ini.
  • You cannot edit the name of a policy, use a custom address in a policy, or use Host Name (DNS lookup) to add an IP address to a policy.
  • You cannot use the Web UI to configure a DNS server for the DHCP settings of a wireless guest account. You must use Policy Manager or the CLI to add the DNS server. [39980]
  • If you configure a policy in the Web UI with a status of Disabled, then open Policy Manager and make a change to the same policy, the action assigned to the policy when it denies packets is changed to Send TCP RST. [34118]
  • If you use the Web UI to edit an existing proxy policy that has alarm settings enabled, the alarm settings may be disabled when you save your configuration. [38585]
  • You cannot create read-only Mobile VPN with IPSec configuration files with the Web UI. [39176]

E-Mails ohne Datum und Uhrzeit (POP3-proxy)

Comment

Gelegentlich kommt es vor, dass der POP3-proxy zur Abholung von E-Mails bei einem externen Provider eingesetzt wird. In Verbindung mit den UTM Services Gateway Antivirus und spamBlocker macht das natürlich Sinn. spamBlocker kann bei POP3 jedoch nur mit der Option “Tagging” verwendet werden, also das Schreiben eines Zusatzes in die Betreffzeile, z.B. [SPAM?]. “Deny” macht technisch keinen Sinn, da die E-Mails ja bereits auf dem zuständigen Mailserver beim Provider stehen und dort auch abgeholt werden müssen. “Quarantine” wäre technisch zwar denkbar, steht bei POP3 aber leider auch nicht zur Verfügung.

Wenn der POP3-proxy mit seinen Default-Einstellungen verwendet wird, führt dies mitunter dazu, dass die abgeholten E-Mails ohne Sende-Datum/Uhrzeit im Mailclient (z.B. Outlook) angezeigt werden (“Keine Angabe”). Dies liegt dann vermutlich daran, dass der diesbezügliche Header vom POP3-proxy entfernt wurde, weil er nicht auf der Allow-Liste steht. Fügen Sie in diesem Fall einmal den Wert Date:* in die Liste der erlaubten Header ein.

Sollten Sie ein ähnliches Problem haben – irgendetwas geht bei Verwendung des POP3-proxy nicht mehr, das aber vorher mit einem POP3 Paketfilter geklappt hat – dann ist es sicher eine gute Idee, das Häkchen bei “Log” neben der “Strip” Action zu setzen und im Traffic Monitor mitzuverfolgen, welche eventuell doch benötigten Header noch auf der Strecke bleiben. Diese können dann in die Allow-Liste eingepflegt werden. Auch ein Blick in die “Header”-Sektion des SMTP-proxy (!) und ein entsprechender Vergleich lohnt sich gegebenenfalls…

Lock / Unlock bei SMTP E-Mails

3 Comments

Der SMTP-proxy verfügt im Bereich Attachments sowohl bei Content Types als auch bei Filenames über die Optionen Allow, Lock, AV Scan, Strip, Drop und Block im Pull-Down-Menü Actions to take. Wurde zur Steuerung von unerwünschten E-Mail-Anhängen vom Default Strip (Herausschneiden und Löschen) abgewichen und die Option Lock gewählt, werden Dateianhänge, auf die ausgewählten Kriterien passen, von der WatchGuard Firewall “ge-locked”.

Im Detail passiert folgendes: die Datei wird binärtechnisch leicht verändert, es werden ein paar Byte vor und hinter die Datei gehängt. Außerdem wird der Dateiname um die Endung .clk ergänzt (cloaked). Die Datei hängt aber nach wie vor an der eigentlichen E-Mail dran und erreicht auch das Postfach des Empfängers. Versucht nun der Empfänger, die Datei mit Doppelklick zu öffnen, schlägt dies fehl. Dies ist auch so beabsichtigt! An die E-Mail wird eine zusätzliche Textdatei angehängt, die die bei Deny Message definierte Fehlermeldung beinhaltet. Der Standardtext lautet: “The WatchGuard Firebox that protects your network has detected a message that may not be safe. […] Your network administrator can unlock this attachment.” Außerdem finden sich nähere Angaben über die Datei und den Grund.

Die Option Lock gibt es schon seit über zehn Jahren bei WatchGuard-Produkten. Die theoretische Denke dahinter ist auch genau so alt: der Empfänger speichere die ge-lockte Datei z.B. auf ein transportables Speichermedium (Diskette, USB-Stick) und gehe damit zu seinem Systemadministrator. Dieser starte in einer MSDOS-Eingabeaufforderung auf einem – separat vom lokalen Netzwerk stehenden und mit einer aktuellen lokalen Antivirus-Software ausgestatteten – PC das kleine Hilsprogramm unlock.exe, das sich im Verzeichnis C:ProgrammeWatchGuardwsm10.2bin befindet und entpackt dadurch die .clk-Datei in den Urzustand, woraufhin sie mit der Antivirus-Software untersucht und bei Unbedenklichkeit an den eigentlichen Empfänger ausgehändigt werden kann. Abwandlungen in der einen oder anderen Form gestattet… 🙂

Auch das Gateway Antivirus-Subsystem kann die Option Lock nutzen, entweder wenn bereits tatsächlich ein Virus in der Datei gefunden wurde – oder wenn ein Scan Error aufgetreten ist, also die AV Engine die Datei nicht scannen konnte. Das ist übrigens auch dann der Fall, wenn die Datei verschlüsselt ist – und sei es nur eine ZIP-Datei, die mit einem Kennwort versehen wurde. Klar – eine verschlüsselte Datei kann erst dann auf Viren gescannt werden, wenn sie korrekt entschlüsselt wurde. In einem solchen Fall kann man natürlich der lokalen Antivirus-Software auf dem PC des Empfängers vertrauen und anstelle von Lock die Option Allow wählen – oder man nutzt die Option Lock und überläßt zumindest das Entpacken dem Administrator…

E-Mail-Sicherheit mit dem SMTP-proxy (1)

Comment

Der Application Proxy für SMTP steht in allen WatchGuard Firebox Software-Versionen zur Verfügung – in der normalen Fireware, in der Fireware Pro und auch in den älteren Versionen des WFS v7.x. Heute möchte ich auf ein paar Aspekte des Themas “E-Mail-Sicherheit” eingehen, die schon mit den Bordmitteln der WatchGuard Firebox möglich sind:

1. Einschränkung der erlaubten (Ziel-)E-Mail-Domains

Spam-Versender versuchen häufig, schlecht abgesicherte Mailserver im Internet für Massenversendungen zu missbrauchen. Sie suchen so genannte “Open Mail Relays”. Das sind Mailserver, die erst einmal ALLE E-Mails annehmen – egal an welche Empfänger-Adresse sie gerichtet sind – und sich dann im nächsten Schritt um die korrekte Zustellung kümmern. Stellen Sie sich vor: IHR hauseigener Mailserver bekommt eine E-Mail zugeschickt, die an die Adresse blabla@blabla-domain.de gerichtet ist. Nun, diese Adresse kennt er nicht, weil Ihre eigene Domain eben anders heißt 🙂 Wenn Ihr Mailserver schlecht konfiguriert ist, nimmt er die E-Mail an und versucht dann unter “eigenem Namen” (!) die E-Mail an die tatsächliche Empfänger-Domain “blabla-domain.de” zuzustellen. Damit tritt jedoch IHR Mailserver als Spam-Versender in Erscheinung – nicht mehr der eigentliche Spam-Absender. Die Folge wird sein, dass IHR Mailserver auf einer Blacklist von Anti-Spam-Organisationen auftauchen wird. Viele andere Mailserver WELTWEIT werden dann künftig auch LEGITIME E-Mails von Ihnen ABLEHNEN oder im schlimmsten Fall ungesehen verwerfen werden!

Die beste Gegenmaßnahme ist natürlich: Sorgen Sie dafür, dass Ihr Mailserver korrekt konfiguriert ist – also nur E-Mails an genau die Domain(s) annimmt, für die er auch zuständig ist! Alternativ (oder besser: ergänzend dazu) können Sie auch den SMTP-Proxy der WatchGuard Firebox einsetzen. In den Properties gibt es das Untermenü “Address” und dort “Rcpt To”. Dort steht standardmäßig ein Stern * als allgemeine Wildcard für Allow. Wenn Sie den Stern durch Wildcards mit den Domain-Namen ersetzen, für die Ihr Mailserver die Mails annehmen soll – Beispiel: *meinefirma.de, *meinefirma.com – wird die WatchGuard Firebox auch nur noch derartige E-Mails zu Ihrem Mailserver durchlassen – ein wirksames Gegenmittel gegen ungewollten Missbrauch als Open Mail Relay.

(Fortsetzung folgt…)

IKE Keep Alive und Dead Peer Detection (DPD)

1 Comment

Die Kernaussage vorweg: Steigern Sie die Stabilität Ihrer BOVPN Tunnel, indem Sie IKE Keep Alive –ODER– Dead Peer Detection (DPD) verwenden – aber nicht beides zusammen!

Branch Office VPN Tunnel sind im Regelfall darauf ausgerichtet, möglichst 24 Stunden am Tag voll verfügbar zu sein (always on). Brechen Tunnel weg, liegt es meist an:

  • Ein oder beide Endpunkte haben eine instabile Internet-Anbindung, hohe Latenzzeiten oder Paketverluste. In meinem Artikel Verbindungsprobleme wegen Ethernet Collisions bin ich darauf bereits einmal eingegangen.

  • Veraltete Software-Stände oder Kompatibilitäts-Probleme (möglichst immer die aktuelle Software-Version einsetzen, sowohl auf WatchGuard Firebox Produkten als auch auf VPN Devices von Fremdherstellern).

  • Kein Traffic im VPN-Tunnel. Tunnel ohne Traffic tendieren dazu, instabil zu werden.

Die WatchGuard Fireboxen kennen mehrere Verfahren, die zur Stabilität von VPN-Tunneln beitragen: IKE Keep Alive, Dead Peer Detection – und bei der X Edge Serie zusätzlich noch VPN Keep Alive.

IKE Keep Alive sollte nur eingesetzt werden, wenn auf beiden Enden des VPN-Tunnels WatchGuard Produkte stehen!
Dead Peer Detection (DPD) hingegen ist ein Industriestandard (RFC3706), der von den meisten IPSec Devices unterstützt wird. Die aktuellen Default Einstellungen sollten auch verwendet werden: NAT-Traversal (aktiv), 20 Sekunden. Bei Nutzung von IKE Keep Alive: 30 Sekunden, max. 5 Failures. Bei Nutzung von DPD: 20 Sekunden, max. 5 Versuche. Verwenden Sie IKE Keep Alive und DPD NICHT GLEICHZEITIG, dies bewirkt genau das Gegenteil: Wenn beide Verfahren aktiviert sind und ein Verfahren eine Phase 1 Renegotiation auslöst, erkennt das andere Verfahren den Tunnel als down und startet seinerseits eine zweite Phase 1. So entsteht ein Konflikt mit der gerade zuvor ausgehandelten Phase 1…

Auf der X Edge gibt es alternativ noch VPN Keep Alive (VPN > VPN Keep Alive). Hier kann pro Tunnel eine IP-Adresse eines Hosts auf der anderen Seite des Tunnels eingetragen werden, der 24/7 läuft und auf ping antwortet (z.B. ein Server, ein managebarer Switch oder ersatzweise die IP-Adresse des Trusted Interface der dortigen Firewall bzw. VPN-Komponente):

Es wird empfohlen, sich jedoch nur auf EIN Verfahren zu beschränken!

Funktionsweise des WatchGuard Firebox Regelwerks

4 Comments

Die WatchGuard Firewall prüft jede neu anstehende Verbindung von einem Host auf der einen Seite der Firewall zu einem Host auf der anderen Seite der Firewall. Dabei werden zunächst die Header der IP-Pakete untersucht: Quell-IP-Adresse, Ziel-IP-Adresse, Quell-Port, Ziel-Port, verwendetes Protokoll (TCP, UDP, ICMP etc.). Die Firewall durchforstet nun das Regelwerk sequentiell “von oben nach unten” (wenn man sich in der Standard-Listenansicht des Policy Managers befindet).
Nacheinander wird jede einzelne Regel geprüft, ob sie die o.g. Kriterien erfüllt – so lange bis der erste “Treffer” gefunden wird. Nur diese Regel wird auch ausgeführt. Gibt es “weiter hinten” im Regelwerk eine andere Regel, auf die ebenfalls die o.g. Kriterien zutreffen, wird diese niemals erreicht/ausgeführt. Wird eine passende Regel gefunden, wird die Verbindung authentisiert und (bei TCP) in die TCP Session Table der Firewall eingetragen. Nachfolgende Pakete in der gleichen TCP-Verbindung werden dann automatisch von der Firewall durchgelassen und nicht noch einmal aufs Neue authentisiert (anders bei Application Proxy Regeln, die eine zusätzliche Kontrolle des Inhalts vornehmen).

Ganz am Ende des Regelwerks steht eine unsichtbare Deny Regel. Jeder Datenverkehr, der nicht ausdrücklich durch eine Firewall-Regel zugelassen wird, wird von dieser Default Deny-Regel ABGELEHNT. Je nachdem, ob der Verbindungsaufbau von innen oder von außen erfolgen sollte, erscheint im Traffic Monitor und im Logfile ein Unhandled Internal Packet oder ein Unhandled External Packet.

Warum werden die Unhandled Packets angezeigt?

Weil im Policy Manager bei Setup > Default Threat Protection > Deafult Packet Handling > Logging das Häkchen “Send Log message” bei den Kategorien “Unhandled Internal Packet” und “Unhandled External Packet” gesetzt ist. Das Logging könnte zwar durch Entfernen des Häkchens ausgeschaltet werden – das ist aber keine gute Idee (bessere Idee weiter unten :-). Der Traffic Monitor und die Unhandled Packets sind ein extrem wichtiges und hochinteressantes Tool, um Fehlverhalten von Maschinen bzw. Fehlkonfigurationen im lokalen Netzwerk aufzudecken und abzustellen! Die Anzeige der Denied Packets kann der Administrator auch sehr gut nutzen, um den Bedarf für neue Regeln zu erkennen und wie diese auszusehen haben.

Das Default Regelwerk und die globale Outgoing-Regel

Der Quick Setup Wizard erzeugt bei der Ersteinrichtung der WatchGuard Firebox ein kleines Default Regelwerk, das im Prinzip sämtlichen TCP- und UDP-Verkehr sowie Ping in ausgehende Richtung (outgoing) zulässt – und sämtlichen eingehenden Verkehr (incoming) verbietet.
Gewissenhafte Administratoren wollen jedoch genau definieren, welcher ausgehende Datenverkehr zulässig ist und diesen auf Maschinen- und/oder User-Ebene auf das absolute Minimum beschränken. Neue Firewall-Regeln werden ins Regelwerk aufgenommen und so weit wie möglich einschränkt. Ein gutes Firewall-Regelwerk wächst dadurch auf 20-30 Regeln, teilweise aber auch auf 80-100 Regeln an. Das schöne feingliedrige Regelwerk wird aber nur dann wie beabsichtigt funktionieren, wenn die defaultmäßig vorhandene Outgoing-Regel auf disabled gesetzt oder ganz gelöscht wird. Denn: das Regelwerk wird “von oben nach unten” abgearbeitet, der erste Treffer zählt. Solange “unten” die globale Outgoing-Regel steht, nützen die Einschränkungen weiter “oben” nichts. Der Verkehr würde trotzdem über die Outgoing-Regel rausgehen, also weg damit!

Anzeige von bestimmten Unhandled Packets unterdrücken

Bisweilen ärgert man sich doch über die Anzeige von Unhandled Packets. Eventuell kann man die Ursache dafür einfach nicht abstellen usw. Bei der Lösung hilft nun das bisher Gesagte: das unzulässige Paket erzeugt eben ein Unhandled Packet, weil es eben keine explizite Regel für diesen Verkehr gibt. Das Paket bleibt an der unsichtbaren Deny Regel ganz am Ende des Regelwerks hängen.
Der Trick besteht nun einfach darin, eine explizite Firewall-Regel zu bauen, die den Verkehr genau beschreibt (siehe oben: Quell-IP, Ziel-IP, Quell-Port, Ziel-Port, Protokoll), aber verbietet (“Denied”) – und das Logging ausschaltet. Der lästige Verkehr taucht künftig nicht mehr im Traffic Monitor und im Logfile auf. Im Regelwerk werden Deny-Regeln mit einem roten X angezeigt:

Konfigurationsbeispiel: HostWatch Namensauflösung (Port 137/udp) unterdrücken

Properties > Logging

Eine Denied-Regel verankert sich im Regelwerk automatisch OBERHALB einer Allow-Regel für den gleichen Port bzw. das gleiche Protokoll, wird also zeitlich gesehen früher geprüft. Das kennen wir: ein explizites Verbot ist mächtiger als eine nicht erfolgte Erlaubnis. Ich nutze die Kombinationsmöglichkeit aus Denied- und Allow-Regeln auch ganz gerne so: Ping.Allow von Any nach Any -und- Ping.Denied von Any-External nach Firebox. Damit kann innerhalb des lokalen Netzwerks/VPN fröhlich hin- und hergepingt werden – auf Pings aus dem Internet reagiert unsere Firebox jedoch nicht. Wenn’s stört, kann für die Denied-Regel natürlich auch das Logging ausgeschaltet werden…

Feature Key vor Software Update aktualisieren

Comment

Heute stand bei einem Kunden das Upgrade einer X500, auf der noch die alte Fireware 8.3 lief, auf die aktuelle Fireware 10.2.6 an. Generell muss bei Software Upgrades VOR dem Start sichergestellt sein, dass auf der Firebox ein aktueller Feature Key (Lizenzdatei) installiert ist, der dies überhaupt zulässt. Ist nämlich die Live Security abgelaufen, verweigert sich die Firebox mit einer Fehlermeldung! Ob bzw. wie lange die Live Security noch gültig ist, sieht man u.a. im WSM > Policy Manager unter Setup > Feature Keys…:

Steht dort “Expired”, braucht man gar nicht versuchen, die Arbeiten fortzusetzen. Stattdessen muss zunächst dafür gesorgt werden, dass wieder ein Feature Key mit gültiger Live Security vorhanden ist. Die erforderlichen Lizenzverlängerungen (Renewals) kauft man bei dem WatchGuard-Partner seines Vertrauens, gerne hier. Liegt der neue Feature Key vor, muss dieser UNBEDINGT mit der ALTEN Softwareversion (im vorliegenden Fall mit dem WSM 8.3) importiert und auf die Firebox hochgeladen werden.
Erst danach sollten die alten Software-Versionen von der Windows Management-Station entfernt, dann die aktuellen Versionen (derzeit 10.2.6) von Fireware und WSM installiert und erst dann über den Policy Manager (File > Upgrade…) der reguläre Update-Prozess gestartet werden!

BOVPN Notification einschalten

1 Comment

Wenn die Firebox an einen Logging Server angeschlossen und dieser korrekt konfiguriert ist, können für viele unterschiedliche Ereignisse auf der Firewall Notifications (Benachrichtigungen) erzeugt und per E-Mail an den Firewall-Administrator oder einen Support-Alias verschickt werden. Wichtig: Der Versand der Notification E-Mails erfolgt vom Logging Server aus – die Firewall liefert über das Logging lediglich das Triggersignal dazu!

Ein solches Ereignis kann die Unterbrechung eines BOVPN-Tunnels sein. Die Benachrichtigungs-Option hierfür ist noch relativ neu. Sie kann nur global für alle BOVPN-Tunnel ein- bzw. ausgeschaltet werden: Policy Manager > VPN > VPN Settings > BOVPN Notification:

Kernel Crash bei Fireware 10.2.x

Comment

Im Zusammenhang mit meinem Posting “Upper Port Problem bald gelöst” vom 08.01.09 kam folgende Frage auf: “Wie kann man feststellen, ob/wann überhaupt ein Kernel Crash aufgetreten ist?” Hier die Antwort: Starten Sie den WatchGuard System Manager (WSM), verbinden Sie sich mit Ihrer Firebox und rufen Sie über Rechtsklick den Firebox System Manager auf. Gehen Sie dort auf die Registerkarte “Status Report” und scrollen Sie bis ganz unten. Endet die Anzeige mit

** Routing Protocol (BGP)
**
bgp is not enabled

liegt kein unmittelbarer Kernel Crash vor. Gibt es darunter jedoch noch ein paar Zeilen zum Thema VM Dump, dann sind ein oder mehrere Kernel Crashes aufgetreten:

**
** VM Dump
**
Found kernel crash, time of crash was Sun Jan 11 21:14:26 2009
Crash dump data recovered on Sun Jan 11 21:15:08 CET 2009
Crash dump data saved in /var/log/vmdump/vmdump.3.

In diesem Beispiel bedeutet die Ziffer 3 ganz zum Schluss, dass aktuell sogar vier Kernel Crashes in den internen Support Logfiles der WatchGuard Firebox protokolliert sind. Ein Kernel Crash löst anschließend einen Reboot der Firebox aus.

“Wie kann ich die internen Support Logfiles auslesen?”

Antwort: Ganz rechts unten in der Ecke des Status Reports (vgl. auch den o.g. Screenshot) findet sich ein Button “Support…”:

Mit Klick auf “Retrieve” kann man alle internen Logfiles in einer gemeinsamen Datei namens support.tgz auf die Windows Management-Station herunterladen. Dort kann sie z.B. mit Hilfe von WinZip oder WinRAR ausgepackt werden. Im Unterverzeichnis varlogvmdump finden sich im aktuellen Beispiel die Dateien vmdump.0, vmdump.1, vmdump.2 und vmdump.3 – jeweils mit Datum und Uhrzeit des tatsächlichen Kernel Crashes:

Da alle Uhrzeiten recht ähnlich sind, liegt ein Vergleich mit den Uhrzeiten der 24-stündigen T-DSL Zwangstrennung durch die Telekom nahe (adsl.log). Und siehe da: ja, passt. Im vorliegenden Beispiel steht die T-DSL-Zwangstrennung im direkten Zusammenhang mit den Kernel Crashes… 🙁

Dynamic NAT und Nicht-RFC-1918-Adressen

Comment

Im Rahmen meiner heutigen WatchGuard-Schulung kam auch das Thema “Dynamic NAT” zur Sprache. Insofern kurzer Hinweis auf folgende Besonderheit: Per Default geht der WatchGuard Policy Manager davon aus, dass Sie in Ihren LOKALEN Netzwerken (Trusted oder Optional) entweder RFC-konforme Private IP-Adressen nach RFC 1918 verwenden – also ein beliebiges Subnet innerhalb der Bereiche 10.0.0.0/8, 172.16.0.0/12 oder 192.168.0.0/16 – oder korrekt geroutete öffentliche IP-Adressen! Nur dann funktioniert der “Internet-Zugriff” auf Anhieb!
Verwenden Sie jedoch – meist aus “historischen Gründen” – in Ihrem lokalen Netzwerk “verbogene” öffentliche IP-Adressen (also zum Beispiel: 192.1.1.0/24) – müssen Sie folgende Einstellung im Policy Manager bearbeiten, damit die reguläre Internet-Nutzung überhaupt erst möglich wird: Network > NAT.

Fügen Sie dort Ihren “verbogenen” lokalen IP-Bereich hinzu:

Technischer Hintergrund: Nur wenn die Quell-IP-Adresse in den Headern von ausgehenden IP-Paketen in den hier definierten Bereichen liegt, wendet die WatchGuard Firebox beim Durchfluss der Datenpakete Richtung Internet auch die erforderlichen NAT-Regeln an, ersetzt also die eigentliche Quell-IP-Adresse (des Client-PC) durch die korrekte öffentliche IP-Adresse der Firewall. Nur dann können die Daten aus dem Internet auch den korrekten Weg zu unserem lokalen Netzwerk zurück finden! – OHNE die NAT-Regel würde der angesprochene Server im Internet unsere Anfrage zwar erhalten – und sogar darauf antworten (!) – allerdings würden die Router im Internet die Antwort wegen ihrer Routing Tables sonstwohin schicken (Südamerika, Australien, Timbuktu…) – nur nicht zu uns, da die Router gar nicht wissen KÖNNEN, dass “wir” diese IP-Adressen “illegalerweise” in unserem lokalen Netzwerk in Hintertupfingen verwenden… 🙂
Fazit: o.g. NAT-Regel anpassen – oder dafür sorgen, dass in Ihrem lokalen Netzwerk endlich KORREKTE private IP-Adressen nach RFC 1918 verwendet werden…