{"id":2953,"date":"2017-07-12T15:47:55","date_gmt":"2017-07-12T13:47:55","guid":{"rendered":"https:\/\/www.boc.de\/watchguard-info-portal\/?p=2953"},"modified":"2017-08-12T22:47:46","modified_gmt":"2017-08-12T20:47:46","slug":"vpn-probleme-aufgrund-teilweisem-leitungsausfall-im-backbone-des-providers","status":"publish","type":"post","link":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/2017\/07\/vpn-probleme-aufgrund-teilweisem-leitungsausfall-im-backbone-des-providers\/","title":{"rendered":"VPN-Probleme aufgrund teilweisem Leitungsausfall im Backbone des Providers"},"content":{"rendered":"<p><i>Konfuzius spricht: &#8220;Nicht immer ist die Firewall des Kunden schuld, wenn ein VPN nicht (mehr) funktioniert und der Kunde sagt, er habe nichts ge\u00e4ndert. Das kann auch wirklich mal den Tatsachen entsprechen.&#8221;<\/i> \ud83d\ude42<\/p>\n<p>Die hier erlebte Ausgangs-Situation f\u00fcr den Support Call war \u00e4u\u00dferst seltsam: Der Internetanschluss funktioniert, nur die Verbindung zwischen zwei BOVPN-Standorten zeigte extrem un\u00fcbliche Verhaltensweisen &#8211; Kommunikation auf einer IP eines Standorts funktionierte, eine weitere IP funktionierte nicht, ICMP Pakete kamen in eine Richtung an, in die andere nicht, aber dann auch wieder abh\u00e4ngig von der Ziel-IP.<\/p>\n<h4>Ist-Zustand: VPN zwischen zwei Standorten funktioniert nicht:<\/h4>\n<ul>\n<li>BOVPN wird aufgebaut.<\/li>\n<li>Daten flie\u00dfen aber nur in eine Richtung (received-packets auf der anderen Seite: 0, zu sehen im Firebox System Manager bei Aufbl\u00e4ttern des VPNs).<\/li>\n<li>Ping von Standort 1 zu Standort 2 geht nicht.<\/li>\n<li>Ping von Standort 2 zu Standort 1 geht nicht &#8211; tcpdump zeigt aber, dass icmp request ankommt und icmp reply gesendet wird.<\/li>\n<li>Ping von Standort 2 zu Standort 1 sekund\u00e4re IP geht<\/li>\n<li>Ping von Standort 1 sekund\u00e4re IP zu Standort 2 geht nicht<\/li>\n<li>Beide Standorte k\u00f6nnen problemlos im Internet arbeiten, empfangen E-Mail und k\u00f6nnen von einem <u>dritten<\/u> Standort per WatchGuard System Manager administriert werden.<\/li>\n<li>WSM nur eben nicht vom jeweiligen anderen Standort aus.<\/li>\n<li>Teamviewer-Sitzungen sind stabil.<\/li>\n<\/ul>\n<p>Nach langer Suche und mehreren Telefonkonferenzen mit dem Internet Provider stellt sich heraus:<\/p>\n<ul>\n<li>Eine Strecke zwischen zwei Routern im Backbone des Providers hat zwei 10G Interfaces zum n\u00e4chsten Router<\/li>\n<li>Diese sind mittels Link Aggregation zusammengeschaltet (also 1 logische Leitung, 2 physikalische Strecken)<\/li>\n<li>Aufgrund dessen wird \u00fcber die Pakete offenbar \u00fcber (src-dest-type-port) ein Hash zusammengebaut, anhand dessen bestimmt wird, ob das Paket \u00fcber die eine oder die andere physikalische Leitung geht.<\/li>\n<li>Demzufolge geht Ping mal oder mal nicht (abh\u00e4ngig von der Ziel IP-Adresse), ein traceroute geht mal und mal nicht, und VPN baut sich auf oder auch nicht (udp\/tcp) und\/oder kann in eine Richtung keine Daten senden, empf\u00e4ngt aber aus der anderen Richtung, (weil diese Strecke mit Typ IPSec und den jeweiligen Ziel-IPs mal in die eine Richtung auf der richtigen und in die andere Richtung auf der falschen Leitung landet).<\/li>\n<\/ul>\n<p>Nach Abschalten des 10G-Interfaces der defekten Strecke war sofort Traffic auf dem VPN sichtbar und ping \/ traceroute verrichteten wieder v\u00f6llig normal ihren Dienst.<br \/>\n<strong>Trotz der anf\u00e4nglichen Behauptung des Providers, es liege an der Firewall des Kunden, konnte gezeigt werden, dass die WatchGuard unschuldig war<\/strong> \ud83d\ude42<\/p>\n<h4>Wie findet man so etwas?<\/h4>\n<ul>\n<li>Binden aller verf\u00fcgbaren externen IPs als Secondary IP<\/li>\n<li>Pr\u00fcfen, welche IPs auf Ping antworten<\/li>\n<li>Pingen aller Router im Traceroute<\/li>\n<li>Pingen der Zwischeninterfaces aus dem Traceroute (Router Eingangs-IP, Router Ausgangs-IP aus dem Transfernetz, Auslesen\/Zuordnen per traceroutes in beide Richtungen)<\/li>\n<li>Unabdingbar: ein technisch kompetenter Ansprechpartner auf Seiten des Providers \ud83d\ude42<\/li>\n<li>Die richtige Eingebung zum richtigen Zeitpunkt beim richtigen Router nach Link Aggregation zu fragen \ud83d\ude42<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>Konfuzius spricht: &#8220;Nicht immer ist die Firewall des Kunden schuld, wenn ein VPN nicht (mehr) funktioniert und der Kunde sagt, er habe nichts ge\u00e4ndert. Das kann auch wirklich mal den Tatsachen entsprechen.&#8221; \ud83d\ude42 Die hier erlebte Ausgangs-Situation f\u00fcr den Support Call war \u00e4u\u00dferst seltsam: Der Internetanschluss funktioniert, nur die Verbindung zwischen zwei BOVPN-Standorten zeigte extrem un\u00fcbliche Verhaltensweisen &#8211; Kommunikation auf einer IP eines Standorts funktionierte, &hellip; <a href=\"https:\/\/wordpress.boc.de\/watchguard-info-portal\/2017\/07\/vpn-probleme-aufgrund-teilweisem-leitungsausfall-im-backbone-des-providers\/\" class=\"more-link\">Weiterlesen <span class=\"screen-reader-text\">VPN-Probleme aufgrund teilweisem Leitungsausfall im Backbone des Providers<\/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":[3],"tags":[376,377,79,379,378,273],"class_list":["post-2953","post","type-post","status-publish","format-standard","hentry","category-watchguard-technischer-blog","tag-eine-richtung","tag-link-aggregation","tag-ping","tag-tcpdump","tag-tracerout","tag-vpn"],"_links":{"self":[{"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/posts\/2953"}],"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=2953"}],"version-history":[{"count":11,"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/posts\/2953\/revisions"}],"predecessor-version":[{"id":3166,"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/posts\/2953\/revisions\/3166"}],"wp:attachment":[{"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/media?parent=2953"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/categories?post=2953"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/tags?post=2953"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}