Eine Default WatchGuard Konfigurationsdatei, die per Setup Wizard erstellt wurde, geht davon aus, dass in einem LOKALEN Netzwerk (Trusted oder Optional) entweder RFC-konforme Private IP-Adressen nach RFC 1918 verwendet werden – 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 > Dynamic NAT.
Fügen Sie dort Ihren “verbogenen” lokalen IP-Bereich hinzu. Hierbei kann auch eine bestimmte Quell-IP festgelegt werden. Wird nichts definiert, wird die Primary IP des Interfaces verwendet, über das das Datenpaket gemäß Routing Table die WatchGuard verlässt:

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 KORREKTE private IP-Adressen nach RFC 1918 verwendet werden…

Dieser Artikel wurde erstmals am 11.12.2008 im “Technischen WatchGuard-Blog von Bernd Och” veröffentlicht. Hierher verschoben und aktualisiert in 2016.