{"id":2217,"date":"2009-05-14T14:02:00","date_gmt":"2009-05-14T12:02:00","guid":{"rendered":"https:\/\/www.boc.de\/watchguard-info-portal\/ssl-vpn-bei-multi-wan-auf-einer-x-edge\/"},"modified":"2016-08-23T14:59:08","modified_gmt":"2016-08-23T12:59:08","slug":"ssl-vpn-bei-multi-wan-auf-einer-x-edge","status":"publish","type":"post","link":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/2009\/05\/ssl-vpn-bei-multi-wan-auf-einer-x-edge\/","title":{"rendered":"SSL-VPN bei Multi-WAN auf einer X Edge"},"content":{"rendered":"<p>Bei Vorhandensein der <strong>Edge Pro<\/strong> (Standard bei X55e, Nachr\u00fcst-Option bei X10e und X20e) k\u00f6nnen beide WAN-Anschl\u00fcsse der X Edge (WAN1 und WAN2) mit einem Internet-Anschluss belegt werden (z.B. zweimal aktives DSL f\u00fcr Multi-WAN oder einmal DSL und einmal UMTS als Fallback).<\/p>\n<p>Obwohl die GUI auch andere Einstellungen zul\u00e4sst, <strong>terminieren VPN-Verbindungen immer auf WAN1<\/strong>, solange WAN1 aktiv ist. Insofern handelt es sich bez\u00fcglich VPN bei WAN2 um ein reines Failover-Interface. Hat man die Konstellation, dass z.B. zun\u00e4chst auf WAN1 ein normaler ADSL-Anschluss liegt (z.B. T-DSL 6000 mit 512 kBit Upload) &#8211; und nach einiger Zeit kommt ein SDSL-Anschluss hinzu (2 Mbit symmetrisch), der gerade wegen des h\u00f6heren Upload f\u00fcr VPN-Verbindungen genutzt werden soll &#8211; sollte man die External Interface neu zuordnen, so dass der SDSL auf WAN1 und der ADSL auf WAN2 zu liegen kommt.<\/p>\n<p>Im Falle von Mobile User SSL-VPN kann man eine Primary IP und eine Secondary IP angeben. Hierbei sollte <strong>Primary immer die WAN1-IP<\/strong> sein (bzw. der DYNDNS-Hostname) und <strong>Secondary immer die WAN2-IP<\/strong>. Der Client ist zwar in der Lage, die Secondary IP zu connecten und bekommt von dort auch die VPN-Konfig zugewiesen, die eigentliche VPN-Verbindung wird dann aber zu der Primary IP (sprich WAN1) aufgebaut, solange dieses Interface aktiv ist. Sind die IPs vertauscht oder wird z.B. nur die WAN2-IP in die Konfiguration eingetragen, kommt keine Verbindung zustande. Der Client zeigt im Log die Fehlermeldung <strong>&#8220;Connection refused (WSAECONNREFUSED)&#8221;<\/strong> und steht im Logon-Fenster in einer Endlosschleife &#8220;Paused, waiting 5 seconds&#8221;.<\/p>\n<p>Support kennt hierzu auch \u00e4hnliche Berichte aus der Praxis:<br \/>BUG30110: Cannot construct SSL VPN and MOVPN on WAN2 while WAN1 is up und BUG23704: Cannot construct a tunnel on WAN2 while WAN1 is up. Diese wurden aber abgeschlossen mit dem Hinweis, dass dieses Verhalten &#8220;normal&#8221; und &#8220;by design&#8221; ist.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Bei Vorhandensein der Edge Pro (Standard bei X55e, Nachr\u00fcst-Option bei X10e und X20e) k\u00f6nnen beide WAN-Anschl\u00fcsse der X Edge (WAN1 und WAN2) mit einem Internet-Anschluss belegt werden (z.B. zweimal aktives DSL f\u00fcr Multi-WAN oder einmal DSL und einmal UMTS als Fallback). Obwohl die GUI auch andere Einstellungen zul\u00e4sst, terminieren VPN-Verbindungen immer auf WAN1, solange WAN1 aktiv ist. Insofern handelt es sich bez\u00fcglich VPN bei WAN2 &hellip; <a href=\"https:\/\/wordpress.boc.de\/watchguard-info-portal\/2009\/05\/ssl-vpn-bei-multi-wan-auf-einer-x-edge\/\" class=\"more-link\">Weiterlesen <span class=\"screen-reader-text\">SSL-VPN bei Multi-WAN auf einer X Edge<\/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":[64,317,290,74,309,304,319,273],"class_list":["post-2217","post","type-post","status-publish","format-standard","hentry","category-watchguard-technischer-blog","tag-dyndns","tag-edge-pro","tag-failover","tag-multi-wan","tag-muvpn","tag-ssl-vpn","tag-umts","tag-vpn"],"_links":{"self":[{"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/posts\/2217"}],"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=2217"}],"version-history":[{"count":1,"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/posts\/2217\/revisions"}],"predecessor-version":[{"id":2312,"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/posts\/2217\/revisions\/2312"}],"wp:attachment":[{"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/media?parent=2217"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/categories?post=2217"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/tags?post=2217"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}