{"id":2172,"date":"2010-05-11T19:34:00","date_gmt":"2010-05-11T17:34:00","guid":{"rendered":"https:\/\/www.boc.de\/watchguard-info-portal\/1-to-1-nat-probleme-bei-11-2-3-ha-activepassive-cluster\/"},"modified":"2016-08-23T15:53:23","modified_gmt":"2016-08-23T13:53:23","slug":"1-to-1-nat-probleme-bei-11-2-3-ha-activepassive-cluster","status":"publish","type":"post","link":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/2010\/05\/1-to-1-nat-probleme-bei-11-2-3-ha-activepassive-cluster\/","title":{"rendered":"1-to-1 NAT Probleme bei 11.2.3 HA Active\/Passive Cluster"},"content":{"rendered":"

In der Softwareversion Fireware XTM 11.2.3 ist offenbar ein Bug zur\u00fcck, der vor ein paar Sub-Releases bereits gefixt war. Im Rahmen eines PCI Compliance Projekts durfte ich letzte Woche einen WatchGuard XTM 1050 Active\/Passive Cluster<\/strong> von 11.1 auf 11.2.3 updaten. Nach dem Update mussten wir bei Tests feststellen, dass sich nach einem Failover<\/strong> das EXTERNE Interface<\/strong> nicht sauber initialisieren konnte. Alle anderen Optional und Trusted Interfaces arbeiteten korrekt. Das Problem trat nicht auf, wenn nur EIN<\/strong> Cluster-Knoten eingeschaltet war (zweite Box aus).
Bei der folgenden Analyse stellte sich heraus, dass die in der Konfigurationsdatei hinterlegten 1-to-1 NAT Eintr\u00e4ge<\/strong> zusammen mit der aktuellen Softwareversion 11.2.3 das Problem in einer Cluster-Konstellation hervorrufen. Dieses Verhalten wurde von WatchGuard als Bug klassifiziert (BUG44667: 11.2.3 FireCluster A\/P connections failing for 1-1-NAT entries). Da dieser Fehler bereits einmal behoben war, rechne ich damit, dass ein Bugfix sehr kurzfristig zur Verf\u00fcgung stehen wird. In diesem Kundenprojekt wurde jedoch entschieden, dass das NATting k\u00fcnftig bereits auf dem vorgelagerten Router stattfindet, so dass der XTM1050-Cluster nur noch sauber routen braucht.<\/p>\n