{"id":2992,"date":"2017-08-11T14:57:16","date_gmt":"2017-08-11T12:57:16","guid":{"rendered":"https:\/\/www.boc.de\/watchguard-info-portal\/?p=2992"},"modified":"2017-08-12T21:55:22","modified_gmt":"2017-08-12T19:55:22","slug":"external-failed-multi-wan-checks-194-25-0-60-antwortet-derzeit-nicht-auf-ping","status":"publish","type":"post","link":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/2017\/08\/external-failed-multi-wan-checks-194-25-0-60-antwortet-derzeit-nicht-auf-ping\/","title":{"rendered":"External failed. Multi-WAN checks: 194.25.0.60 antwortet derzeit nicht auf PING"},"content":{"rendered":"<p>Der von vielen Kunden als Ping zur Leitungs\u00fcberwachung genutzte DNS-Server <strong>194.25.0.60<\/strong> der Telekom antwortet heute (11.08.2017) nicht auf Ping <i>(Anm.: seit dem Abend geht es wieder)<\/i>.<\/p>\n<p>Problematik: Multi-WAN bei WatchGuard ben\u00f6tigt eine Ziel-IP f\u00fcr einen Ping-Check (Network > Configuration > Multi-WAN). Hier wird h\u00e4ufig ein g\u00e4ngiger DNS-Server des zust\u00e4ndigen Internet-Providers eingetragen, weil dieser in der Regel hoch performant und hochverf\u00fcgbar ausgelegt ist. Wenn die an dieser Stelle eingetragene IP-Adresse jedoch nicht mehr auf Ping reagiert, &#8220;denkt&#8221; die WatchGuard, dass die Leitung nicht mehr verf\u00fcgbar ist und schaltet das Interface in den Status &#8220;External:Failed&#8221; und damit logisch auf DOWN. Das bedeutet, dass das Interface f\u00fcr ausgehenden Verkehr nicht mehr verf\u00fcgbar ist &#8211; obwohl die Leitung selbst technisch v\u00f6llig in Ordnung ist.<\/p>\n<p><strong>Best Practice:<\/strong><br \/>\nWir k\u00f6nnen hier keine allgemein gl\u00fccklich machende Antwort geben. Wir schlagen vor, beim <strong>zust\u00e4ndigen Leitungsprovider<\/strong> (es k\u00f6nnen ja auch mal mehrere Leitungen von verschiedenen Providern an einer WatchGuard angeschlossen sein&#8230;) eine oder mehrere IP-Adresse(n) aus dessen Backbone zu erfragen und zu verwenden, die<\/p>\n<ul>\n<li>auf Ping reagieren<\/li>\n<li>hochverf\u00fcgbar ausgelegt sind<\/li>\n<li>sich nicht \u00e4ndern<\/li>\n<\/ul>\n<p>Verwenden Sie <strong>NICHT<\/strong> IP-Adressen eines anderen Providers (Sie wollen ja die Anbindung an den eigenen Provider testen und nicht das weitere Routing\/Peering zu einem anderen Provider. Daher sind auch die allseits bekannten \u00f6ffentlichen DNS-Server von Google (8.8.8.8 und 8.8.4.4) keine besonders guten Ideen.<br \/>\nVerwenden Sie <strong>NICHT<\/strong> die gleiche Test-IP-Adresse f\u00fcr <strong>mehrere<\/strong> External Interfaces. Sollte genau diese IP-Adresse tats\u00e4chlich einmal nicht erreichbar sein, wie jetzt im Falle des Telekom DNS-Servers 194.25.0.60 geschehen, gehen im Extremfall gleichzeitig ALLE Leitungen auf DOWN und Sie bewirken damit das genaue Gegenteil des eigentlichen Redundanz-Gedankens.<br \/>\nNutzen Sie in der Multi-WAN Konfiguration <strong>auf jeden Fall<\/strong> die M\u00f6glichkeit, <strong>explizite<\/strong> Test-IP-Adressen einzutragen. Wenn Sie n\u00e4mlich den System Default belassen = KEINE explizite Test-IP eintragen, dann wird standardm\u00e4\u00dfig das Default Gateway der jeweiligen Leitung \u00fcberwacht\/angepingt. Bei <strong>Static IP<\/strong>, also einer Standleitung mit einem vom Provider bereitgestellten Router mit einem \u00f6ffentlichen IP-Subnetz ist das Default Gateway aber eben genau dieser Router. Weil sich dieser Router aber (i.d.R.) in Ihrem eigenen Hause befindet und immer antworten wird, liefert er also keine sinnvolle Aussage, ob die Internet-Leitung funktioniert oder nicht.<br \/>\nBei <strong>DSL-Anschl\u00fcssen der Deutschen Telekom<\/strong> kommt sogar noch eine weitere Problematik dazu. Das <strong>Default Gateway<\/strong> einer DSL-Leitung wird erst nach erfolgreicher Einwahl dynamisch zugewiesen. Leider haben bei der Telekom aber genau diese Systeme die unangenehme Eigenschaft, dass sie <strong>\u00fcberhaupt nicht auf Ping antworten!<\/strong> Wenn also keine explizite Test-IP eingetragen ist, wird eine solche Leitung im Multi-WAN-Betrieb immer als External:Failed angezeigt werden und steht daher auch nicht f\u00fcr WAN Failover Szenarios zur Verf\u00fcgung&#8230;<br \/>\nJedem selbst \u00fcberlassen bleibt auch die Einsch\u00e4tzung, ob es statt Ping (oder zus\u00e4tzlich zu Ping) sinnvoll ist, die Alternative zu nutzen, n\u00e4mlich per <strong>TCP Connect<\/strong> z.B. den Port 80 eines hochverf\u00fcgbaren Webservers zu pr\u00fcfen. Bedenken Sie dabei aber bitte auch, wenn Sie hier mit einem Hostnamen arbeiten z.B. www.google.de, dass in diesem Fall die WatchGuard diesen Namen vorher auch noch per DNS aufl\u00f6sen k\u00f6nnen muss. Besser w\u00e4re allemal, auch hier mit einer IP-Adresse statt eines Hostnamens zu arbeiten&#8230;<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Der von vielen Kunden als Ping zur Leitungs\u00fcberwachung genutzte DNS-Server 194.25.0.60 der Telekom antwortet heute (11.08.2017) nicht auf Ping (Anm.: seit dem Abend geht es wieder). Problematik: Multi-WAN bei WatchGuard ben\u00f6tigt eine Ziel-IP f\u00fcr einen Ping-Check (Network > Configuration > Multi-WAN). Hier wird h\u00e4ufig ein g\u00e4ngiger DNS-Server des zust\u00e4ndigen Internet-Providers eingetragen, weil dieser in der Regel hoch performant und hochverf\u00fcgbar ausgelegt ist. Wenn die an &hellip; <a href=\"https:\/\/wordpress.boc.de\/watchguard-info-portal\/2017\/08\/external-failed-multi-wan-checks-194-25-0-60-antwortet-derzeit-nicht-auf-ping\/\" class=\"more-link\">Weiterlesen <span class=\"screen-reader-text\">External failed. Multi-WAN checks: 194.25.0.60 antwortet derzeit nicht auf PING<\/span> <span class=\"meta-nav\">&raquo;<\/span><\/a><\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[363,74],"class_list":["post-2992","post","type-post","status-publish","format-standard","hentry","category-watchguard-allgemeine-informationen","tag-best-practices","tag-multi-wan"],"_links":{"self":[{"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/posts\/2992"}],"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\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/comments?post=2992"}],"version-history":[{"count":7,"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/posts\/2992\/revisions"}],"predecessor-version":[{"id":3145,"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/posts\/2992\/revisions\/3145"}],"wp:attachment":[{"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/media?parent=2992"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/categories?post=2992"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/tags?post=2992"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}