{"id":2145,"date":"2010-08-31T21:53:00","date_gmt":"2010-08-31T19:53:00","guid":{"rendered":"https:\/\/www.boc.de\/watchguard-info-portal\/fireware-xtm-ha-cluster-probleme-mit-mtu-size-im-bovpn-tunnel\/"},"modified":"2016-08-23T15:51:40","modified_gmt":"2016-08-23T13:51:40","slug":"fireware-xtm-ha-cluster-probleme-mit-mtu-size-im-bovpn-tunnel","status":"publish","type":"post","link":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/2010\/08\/fireware-xtm-ha-cluster-probleme-mit-mtu-size-im-bovpn-tunnel\/","title":{"rendered":"Fireware XTM: HA Cluster Probleme mit MTU Size im BOVPN Tunnel"},"content":{"rendered":"<p>Ich habe aktuell einige offene Support-F\u00e4lle, die folgende Gemeinsamkeiten aufweisen: <strong>Active\/Passive Cluster unter Fireware XTM v11.3.x, Branch Office IPSec VPN Tunnel zu festen Au\u00dfenstellen, Kommunikationsprobleme innerhalb des\/der BOVPN Tunnel<\/strong>.<br \/>In allen F\u00e4llen scheinen die Probleme mit <strong>fehlerhafter Fragmentierung von IPSec-Paketen<\/strong> zu tun zu haben. Ich konnte etwas ausf\u00fchrlicher debuggen und feststellen, dass bisweilen (also nur zeitweise!) IP-Pakete gr\u00f6\u00dfer als 1394 Bytes im VPN-Tunnel nicht korrekt fragmentiert, sondern komplett verworfen werden. WatchGuard hat das Szenario im TestLab nachgestellt, konnte jedoch die Fehlerursache bis jetzt noch nicht weiter eingrenzen.<br \/>Zur schnellen Dokumentation des Problems verwende ich von einem PC in einer Au\u00dfenstelle eine MSDOS-Eingabeaufforderung mit dem Befehl<\/p>\n<p>ping [IP] -l 2000 -t<\/p>\n<p>wobei [IP] eine IP-Adresse am anderen Ende eines BOVPN-Tunnels (in der Zentrale) ist. Der Befehl erzeugt Ping-Pakete mit einer Gr\u00f6\u00dfe von 2000 Byte, die also beim Transport \u00fcber das Internet zwingend fragmentiert werden m\u00fcssen, da die maximale MTU Size auf Internet-Routern in der Regel 1500 Bytes betr\u00e4gt. Erhalte ich korrekte ICMP-Antworten, weiss ich, dass die Fragmentierung korrekt funktioniert. Wenn nicht, liegt ein Problem vor. Durch Verkleinern der Paketl\u00e4nge kann man sich iterativ an den kritischen Wert herantasten. Im vorliegenden Problemfall werden Pings mit 1394 Bytes korrekt \u00fcbertragen, Pings mit 1395 Bytes und mehr jedoch NICHT:<\/p>\n<p><a href=\"http:\/\/2.bp.blogspot.com\/_haYpXd-8uFA\/TH1qJEKeZyI\/AAAAAAAAAL0\/l-WMnqbudRg\/s1600\/mtu-1394-problem-3.JPG\"><img decoding=\"async\" style=\"cursor:pointer; cursor:hand;width: 303px; height: 320px;\" src=\"http:\/\/2.bp.blogspot.com\/_haYpXd-8uFA\/TH1qJEKeZyI\/AAAAAAAAAL0\/l-WMnqbudRg\/s320\/mtu-1394-problem-3.JPG\" border=\"0\" alt=\"\"id=\"BLOGGER_PHOTO_ID_5511678222940399394\" \/><\/a><\/p>\n<p>Das Problem scheint zudem nur auf dem <strong>R\u00fcckweg<\/strong> von dem angepingten Host aufzutreten. Offenbar erreichen im Problemfall auch gr\u00f6\u00dfere Datenpakete den Zielhost, der auch korrekt antwortet &#8211; jedoch scheint die WatchGuard Firebox ein Problem mit dem &#8220;R\u00fccktransport&#8221; der Antwortpakete zu haben, wie sich am Vergleich der folgenden, im Abstand von ein paar Minuten aufgenommenen Screenshots erkennen l\u00e4sst. Die mit gr\u00fcnen Streifen markierten Werte z\u00e4hlen im Laufe der Zeit korrekt hoch, w\u00e4hrend der eine rot markierte Wert (RCVD zur\u00fcck auf dem urspr\u00fcnglich sendenden System) sich nicht \u00e4ndert&#8230;:<\/p>\n<p><a href=\"http:\/\/4.bp.blogspot.com\/_haYpXd-8uFA\/TH1p7ENg4ZI\/AAAAAAAAALs\/sKNfcHn9gxg\/s1600\/mtu-1394-problem-1.JPG\"><img decoding=\"async\" style=\"cursor:pointer; cursor:hand;width: 320px; height: 313px;\" src=\"http:\/\/4.bp.blogspot.com\/_haYpXd-8uFA\/TH1p7ENg4ZI\/AAAAAAAAALs\/sKNfcHn9gxg\/s320\/mtu-1394-problem-1.JPG\" border=\"0\" alt=\"\"id=\"BLOGGER_PHOTO_ID_5511677982434976146\" \/><\/a><\/p>\n<p>In allen meinen Support-F\u00e4llen konnte ich das Problem zun\u00e4chst durch einen <strong>Workaround<\/strong> umgehen: <strong><u>auf dem Cluster<\/u> Reduktion der MTU Size auf den Interfaces, die an BOVPN-Tunneln beteiligt sind, von 1500 auf 1380 Bytes<\/strong>:<\/p>\n<p><a href=\"http:\/\/3.bp.blogspot.com\/_haYpXd-8uFA\/TH1lAtRlWII\/AAAAAAAAALk\/F917t1X4TV0\/s1600\/mtu-1394-problem-4.JPG\"><img decoding=\"async\" style=\"cursor:pointer; cursor:hand;width: 320px; height: 178px;\" src=\"http:\/\/3.bp.blogspot.com\/_haYpXd-8uFA\/TH1lAtRlWII\/AAAAAAAAALk\/F917t1X4TV0\/s320\/mtu-1394-problem-4.JPG\" border=\"0\" alt=\"\"id=\"BLOGGER_PHOTO_ID_5511672581799106690\" \/><\/a><\/p>\n<p>WatchGuard muss jedoch das eigentliche Problem finden und beheben, denn durch den Workaround wird die Gesamtleistung der WatchGuard Firebox etwas ausgebremst.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Ich habe aktuell einige offene Support-F\u00e4lle, die folgende Gemeinsamkeiten aufweisen: Active\/Passive Cluster unter Fireware XTM v11.3.x, Branch Office IPSec VPN Tunnel zu festen Au\u00dfenstellen, Kommunikationsprobleme innerhalb des\/der BOVPN Tunnel.In allen F\u00e4llen scheinen die Probleme mit fehlerhafter Fragmentierung von IPSec-Paketen zu tun zu haben. Ich konnte etwas ausf\u00fchrlicher debuggen und feststellen, dass bisweilen (also nur zeitweise!) IP-Pakete gr\u00f6\u00dfer als 1394 Bytes im VPN-Tunnel nicht korrekt fragmentiert, &hellip; <a href=\"https:\/\/wordpress.boc.de\/watchguard-info-portal\/2010\/08\/fireware-xtm-ha-cluster-probleme-mit-mtu-size-im-bovpn-tunnel\/\" class=\"more-link\">Weiterlesen <span class=\"screen-reader-text\">Fireware XTM: HA Cluster Probleme mit MTU Size im BOVPN Tunnel<\/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":[11,86,146,282,283,129,296,140,273],"class_list":["post-2145","post","type-post","status-publish","format-standard","hentry","category-watchguard-technischer-blog","tag-bovpn","tag-cluster","tag-debugging","tag-fireware-11","tag-fireware-xtm","tag-high-availability","tag-ipsec-vpn","tag-policy-manager","tag-vpn"],"_links":{"self":[{"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/posts\/2145"}],"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=2145"}],"version-history":[{"count":1,"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/posts\/2145\/revisions"}],"predecessor-version":[{"id":2393,"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/posts\/2145\/revisions\/2393"}],"wp:attachment":[{"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/media?parent=2145"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/categories?post=2145"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/tags?post=2145"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}