{"id":2179,"date":"2010-03-11T19:07:00","date_gmt":"2010-03-11T18:07:00","guid":{"rendered":"https:\/\/www.boc.de\/watchguard-info-portal\/management-ip-der-passiven-box-in-einem-11-2-1-activepassive-ha-cluster-nicht-erreichbar\/"},"modified":"2016-08-23T15:54:03","modified_gmt":"2016-08-23T13:54:03","slug":"management-ip-der-passiven-box-in-einem-11-2-1-activepassive-ha-cluster-nicht-erreichbar","status":"publish","type":"post","link":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/2010\/03\/management-ip-der-passiven-box-in-einem-11-2-1-activepassive-ha-cluster-nicht-erreichbar\/","title":{"rendered":"Management IP der passiven Box in einem 11.2.1 Active\/Passive HA Cluster nicht erreichbar"},"content":{"rendered":"

In einem Active\/Passive HA Cluster<\/strong> unter Fireware XTM v11.x<\/strong> haben beide Firewalls zus\u00e4tzlich zu der gemeinsamen Traffic IP<\/strong> auch noch jeweils eine eigene Management IP-Adresse<\/strong>. Bei der Einrichtung des Clusters wird gefragt, \u00fcber welches Interface der Management-Zugriff erfolgen soll. In vielen F\u00e4llen wird man das regul\u00e4re Trusted Interface w\u00e4hlen, wodurch die Management IP als Secondary IP (z.B. eth1:1) mit auf das Trusted Interface gebunden wird. Die Management IP hat u.a. den Vorteil, dass man nun auch die passive Box in einem Cluster “ansprechen” kann, was vorher nicht ging.<\/p>\n

Wenn ein Netzwerk-Monitoring-System<\/strong> im Einsatz ist (z.B. Nagios), wird man daher auch die Management IP Adressen – auch die der passiven Box – \u00fcberwachen (oder zumindest anpingen) wollen. In einem aktuellen Projekt hat das jedoch nicht funktioniert. Die n\u00e4here Untersuchung hat ein Verhalten aufgezeigt, das bei WatchGuard bereits als Bug bekannt ist:
Im passiven Zustand werden alle IP-Adressen von den Interfaces entfernt, bis auf die Management IP (und die Cluster IP auf dem dedizierten HA Interface). Die Subnetzmaske<\/strong> auf dem Interface der Management IP wird jedoch fest auf \/24 (255.255.255.0) eingestellt:<\/p>\n

\"\"id=\"BLOGGER_PHOTO_ID_5447430477146790050\"<\/a><\/p>\n

– unabh\u00e4ngig davon, welche Subnetzmaske im aktiven Zustand auf diesem Interface eingestellt ist (!):<\/p>\n

\"\"id=\"BLOGGER_PHOTO_ID_5447430492713167698\"<\/a><\/p>\n

Zudem enth\u00e4lt die Routing Table<\/strong> der passiven Box kein Default Gateway<\/strong>:<\/p>\n

\"\"id=\"BLOGGER_PHOTO_ID_5447430487446366882\"<\/a><\/p>\n

Dies f\u00fchrt dazu, dass die Management IP der passiven Box dem Monitoring-System nicht antworten kann, es sei denn, dass die ersten drei Oktets der IP-Adresse zuf\u00e4lligerweise identisch sind und das Netz gr\u00f6\u00dfer gleich \/24 ist…<\/p>\n","protected":false},"excerpt":{"rendered":"

In einem Active\/Passive HA Cluster unter Fireware XTM v11.x haben beide Firewalls zus\u00e4tzlich zu der gemeinsamen Traffic IP auch noch jeweils eine eigene Management IP-Adresse. Bei der Einrichtung des Clusters wird gefragt, \u00fcber welches Interface der Management-Zugriff erfolgen soll. In vielen F\u00e4llen wird man das regul\u00e4re Trusted Interface w\u00e4hlen, wodurch die Management IP als Secondary IP (z.B. eth1:1) mit auf das Trusted Interface gebunden wird. … Weiterlesen Management IP der passiven Box in einem 11.2.1 Active\/Passive HA Cluster nicht erreichbar<\/span> »<\/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":[86,282,278,283,129],"class_list":["post-2179","post","type-post","status-publish","format-standard","hentry","category-watchguard-technischer-blog","tag-cluster","tag-fireware-11","tag-fireware-pro","tag-fireware-xtm","tag-high-availability"],"_links":{"self":[{"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/posts\/2179"}],"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=2179"}],"version-history":[{"count":1,"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/posts\/2179\/revisions"}],"predecessor-version":[{"id":2403,"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/posts\/2179\/revisions\/2403"}],"wp:attachment":[{"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/media?parent=2179"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/categories?post=2179"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/tags?post=2179"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}