{"id":2199,"date":"2009-10-13T00:11:00","date_gmt":"2009-10-12T22:11:00","guid":{"rendered":"https:\/\/www.boc.de\/watchguard-info-portal\/achtung-bei-migration-auf-fireware-xtm-routing-table-abarbeitung-aendert-sich\/"},"modified":"2016-08-23T15:16:16","modified_gmt":"2016-08-23T13:16:16","slug":"achtung-bei-migration-auf-fireware-xtm-routing-table-abarbeitung-aendert-sich","status":"publish","type":"post","link":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/2009\/10\/achtung-bei-migration-auf-fireware-xtm-routing-table-abarbeitung-aendert-sich\/","title":{"rendered":"Achtung bei Migration auf Fireware XTM: Routing Table &#8211; Abarbeitung \u00e4ndert sich"},"content":{"rendered":"<p>Momentan habe ich wenig Zeit f\u00fcr meinen Blog, weil jeden Tag neue Support-Anforderungen bei mir eingehen. Admins migrieren ihre WatchGuard Firebox mit bestem Wissen und Gewissen auf Fireware XTM (Version 11) &#8211; und erleiden bisweilen Schiffbruch. In den allermeisten F\u00e4llen lassen sich die Probleme darauf zur\u00fcckf\u00fchren, dass bei Fireware XTM (Version 11) die interne Routing Table der Firebox in einer anderen Reihenfolge abgearbeitet wird als bei der bisherigen Fireware 10.2.x.<\/p>\n<p>Generell gilt bei XTM: <strong>VPN hat Vorrang!<\/strong><\/p>\n<p>Welche Probleme k\u00f6nnen daraus entstehen und welche L\u00f6sungsans\u00e4tze gibt es:<\/p>\n<ul>\n<li>1. Mobile User VPN. W\u00e4hrend noch bei der Version WFS 7.x empfohlen wurde, den IP-Pool f\u00fcr die Einwahl der mobilen User INNERHALB des lokalen LAN-Subnetzes zu definieren (Beispiel: LAN = 192.168.0.0\/24, mobile User (egal ob PPTP oder IPSec) bekommen 192.168.0.200 bis 220 zugewiesen), ist dies bei Fireware XTM (Version 11) grunds\u00e4tzlich ein Problem und f\u00fchrt zu gravierendem Fehlverhalten.\n<p>Verwenden Sie grunds\u00e4tzlich f\u00fcr die Einwahl von mobilen Usern IP-Bereiche, die in dieser Form an keiner anderen Stelle Ihrer (verteilten) IP-Infrastruktur verwendet werden. Ich pers\u00f6nlich verwende gerne f\u00fcr PPTP den Bereich 172.31.254.1 bis 50, f\u00fcr IPSec 172.31.255.1 bis x (je nach Lizenz) und f\u00fcr SSL-VPN 172.31.253.0\/24. Diese Bereiche werden in aller Regel noch nicht f\u00fcr andere Zwecke verwendet &#8211; und haben eben den Vorteil, dass die WatchGuard Firebox zu diesen Bereichen ein sauberes Routing fahren kann.<\/li>\n<p><\/p>\n<li>2. Network > Routes. Das Problem hier l\u00e4sst sich anhand von folgendem Support Fall verdeutlichen: als <strong>eth1<\/strong> (=Trusted) war bei einem Kunden definiert: 192.168.0.1\/30, d.h. au\u00dfer der Firebox gibt es in diesem Subnetz nur noch genau einen weiteren Host, 192.168.0.2. Dies ist ein Standleitungs-Router, der eine Leitung zu einem 10-er IP-Netz am Hauptstandort des Unternehmens bedient, an dem sich auch die AD-Dom\u00e4nencontroller des Unternehmens befinden, \u00fcber die u.a. auch die Einwahl der mobilen User gegen\u00fcber Active Directory authentifiziert wurde (Eintrag unter <em>Setup > Authentication > Authentication Servers > Active Directory<\/em>). Dummerweise gab es in dieser Konfiguration auch noch einen BOVPN-Tunnel (sprich eine feste Au\u00dfenstelle), der auf der Gegenseite das IP-Netz 192.168.0.0\/24 bedient hat. W\u00e4hrend unter der Software-Version Fireware 10.2.x das auf eth1 definierte lokale Netzwerk 192.168.0.0\/30 Vorrang hatte und daher die DCs in dem 10-er Netz per Routing erreichbar waren, verh\u00e4lt sich die WatchGuard Firebox unter Fireware XTM (Version 11) nun anders und schickt den Traffic zu dem Standleitungs-Router 192.168.0.2 nun nicht mehr zum lokalen Interface eth1 raus &#8211; sondern packt ihn in den Tunnel in die Au\u00dfenstelle x ein, wo er im Nirwana landet&#8230; Problematik klar? In diesem Fall am einfachsten die Konfiguration von eth1 und die IP-Adresse und das Routing des\/zum Standleitungs-Router so ab\u00e4ndern, dass das verwendete IP-Subnetz an keiner anderen Stelle der Unternehmens-IP-Infrastruktur verwendet wird&#8230;<\/li>\n<p><\/p>\n<li>3. Problematik: vermaschte IP-Netze. Unter einem &#8220;vermaschten IP-Netz&#8221; verstehe ich hier ein verteiltes Netzwerk mit mehreren Standorten, die auf TCP\/IP-Basis miteinander kommunizieren k\u00f6nnen, wobei das Routing jedoch nicht direkt von Au\u00dfenstelle zu Au\u00dfenstelle gef\u00fchrt wird, sondern \u00fcber einen gemeinsamen, zentralen Punkt (i.d.R. ein Rechenzentrum). Auch ich habe in der Vergangenheit Netze gebaut, die in einer Au\u00dfenstelle z.B. ein IP-Netz \u00e0 la 10.0.23.0\/24 verwendet haben &#8211; und einen BOVPN-Tunnel zu 10.0.0.0\/8 hinter einem zentralen Gateway angesteuert haben. Dort befand sich eine WatchGuard Firebox X Core oder X Peak, die den Traffic angenommen hat &#8211; und auch tats\u00e4chlich wieder korrekt in die ebenfalls dort terminierten BOVPN-Tunnel zu den anderen Au\u00dfenstellen eingepackt hat. Damit lie\u00dfen sich auch schon in der Vergangenheit zentralisierte VoIP-L\u00f6sungen (z.B. Asterisk, Siemens HiPath, Avaya) abbilden. Ein Problem entsteht unter Fireware XTM insbesondere dann, wenn auch das zentrale Netzwerk in einem IP-Subnetz des o.g. vermaschten Netzwerks betrieben wird. Die zentralen Server sind dann aus den Au\u00dfenstellen heraus nicht mehr korrekt erreichbar. Trifft dieses Szenario auf Sie zu, sprechen Sie mich bitte direkt an, um eine L\u00f6sung gemeinsam zu erarbeiten.<\/li>\n<p><\/p>\n<li>4. Allgemein gilt: sofern Ihre IP-Infrastruktur *KLAR* definiert ist und es zwischen den verwendeten IP-Bereichen keine Konflikte\/\u00dcberschneidungen gibt, wird ein Update auf die aktuelle Version WSM 11.x und Fireware XTM v11.x relativ einfach und \u00fcberschaubar \u00fcber die Runden gehen.<\/ul>\n<\/li>\n","protected":false},"excerpt":{"rendered":"<p>Momentan habe ich wenig Zeit f\u00fcr meinen Blog, weil jeden Tag neue Support-Anforderungen bei mir eingehen. Admins migrieren ihre WatchGuard Firebox mit bestem Wissen und Gewissen auf Fireware XTM (Version 11) &#8211; und erleiden bisweilen Schiffbruch. In den allermeisten F\u00e4llen lassen sich die Probleme darauf zur\u00fcckf\u00fchren, dass bei Fireware XTM (Version 11) die interne Routing Table der Firebox in einer anderen Reihenfolge abgearbeitet wird als &hellip; <a href=\"https:\/\/wordpress.boc.de\/watchguard-info-portal\/2009\/10\/achtung-bei-migration-auf-fireware-xtm-routing-table-abarbeitung-aendert-sich\/\" class=\"more-link\">Weiterlesen <span class=\"screen-reader-text\">Achtung bei Migration auf Fireware XTM: Routing Table &#8211; Abarbeitung \u00e4ndert sich<\/span> <span class=\"meta-nav\">&raquo;<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[278,283,296,338,309,41,140,325,313,304,137,312,339,273,340],"class_list":["post-2199","post","type-post","status-publish","format-standard","hentry","category-watchguard-technischer-blog","tag-fireware-pro","tag-fireware-xtm","tag-ipsec-vpn","tag-live-security","tag-muvpn","tag-notification","tag-policy-manager","tag-pptp-vpn","tag-single-sign-on","tag-ssl-vpn","tag-update","tag-user-authentication","tag-voip","tag-vpn","tag-vpn-any"],"_links":{"self":[{"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/posts\/2199"}],"collection":[{"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/comments?post=2199"}],"version-history":[{"count":1,"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/posts\/2199\/revisions"}],"predecessor-version":[{"id":2334,"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/posts\/2199\/revisions\/2334"}],"wp:attachment":[{"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/media?parent=2199"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/categories?post=2199"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/tags?post=2199"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}