13
Watchguard VPN: Unerklärliche Verbindungsabbrüche
Hallo,
ich wollte den Case eigentlich an Watchguard selbst weiter geben, aber deren nicht vorhandener Support lässt die Erstellung von Cases ganz am Ende des Prozesses nicht zu.
Zum Problem:
Wir haben 2 XTM330 Devices, die via Branch Office VPN verbunden sind. Beide Seiten haben eine feste IP, einer ist ein VDSL50, einer ein 400/50 Anschluss von Vodafone.
Der VPN steht permanent, und ich kann unterbrechnungsfrei alles auf der Gegenseite anpingen. Wir haben Antwortzeiten von 60ms, sporadisch auch mal mehr.
Auf 4250 Pakete habe ich aktuell 5 verlorene.
Wenn wir nun via RDP auf einer entfernten Maschine arbeiten habe ich sporadisch das Verhalten, dass der Bildschirm nicht mehr aktualisiert. Manchmal kommt dann recht fix ein Reconnect, manchmal steht minutenlang "Verbindungsversuch 1 von 20" da, bis ein Reconnect statt findet. RDP schließen und neu verbinden funktioniert kurioserweise zumeist, aber eben nicht immer.
Ein FTP Transfer, den ich mal testweise nebenhe laufen hatte brach zur gleichen Zeit ab. Ping läuft währenddessen durch, ohen Auffälligkeiten.
Wir haben schon die MTU angepasst, nachdem ich einen Artikel fand der das empfohlen hat, weil zuviele Pakete verloren gehen und der Tunnel daher instabil wird: https://www.boc.de/watchguard-info-portal/2010/08/fireware-xtm-ha-cluste ...
Wir dachten auch an Probleme mit dem ReKey-ing und haben das mal hoch gesetzt, aber das war es nicht. Da das Latein von mir und dem anderen mit dem Problem betrauten Kollegen leicht am Ende ist wollte ich einmal hier anfragen.
MfG Maik
ich wollte den Case eigentlich an Watchguard selbst weiter geben, aber deren nicht vorhandener Support lässt die Erstellung von Cases ganz am Ende des Prozesses nicht zu.
Zum Problem:
Wir haben 2 XTM330 Devices, die via Branch Office VPN verbunden sind. Beide Seiten haben eine feste IP, einer ist ein VDSL50, einer ein 400/50 Anschluss von Vodafone.
Der VPN steht permanent, und ich kann unterbrechnungsfrei alles auf der Gegenseite anpingen. Wir haben Antwortzeiten von 60ms, sporadisch auch mal mehr.
Auf 4250 Pakete habe ich aktuell 5 verlorene.
Wenn wir nun via RDP auf einer entfernten Maschine arbeiten habe ich sporadisch das Verhalten, dass der Bildschirm nicht mehr aktualisiert. Manchmal kommt dann recht fix ein Reconnect, manchmal steht minutenlang "Verbindungsversuch 1 von 20" da, bis ein Reconnect statt findet. RDP schließen und neu verbinden funktioniert kurioserweise zumeist, aber eben nicht immer.
Ein FTP Transfer, den ich mal testweise nebenhe laufen hatte brach zur gleichen Zeit ab. Ping läuft währenddessen durch, ohen Auffälligkeiten.
Wir haben schon die MTU angepasst, nachdem ich einen Artikel fand der das empfohlen hat, weil zuviele Pakete verloren gehen und der Tunnel daher instabil wird: https://www.boc.de/watchguard-info-portal/2010/08/fireware-xtm-ha-cluste ...
Wir dachten auch an Probleme mit dem ReKey-ing und haben das mal hoch gesetzt, aber das war es nicht. Da das Latein von mir und dem anderen mit dem Problem betrauten Kollegen leicht am Ende ist wollte ich einmal hier anfragen.
MfG Maik
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 384234
Url: https://administrator.de/forum/watchguard-vpn-unerklaerliche-verbindungsabbrueche-384234.html
Ausgedruckt am: 23.12.2024 um 05:12 Uhr
13 Kommentare
Neuester Kommentar
Hallo Maik,
zumindest ich nutze RDP sehr intensiv, nur haben wir keinen festen Tunnel, sondern wählen uns per NCP-Client auf unserer XTM330 ein. Die von Dir beschriebenen Spässe kenne ich in dem Ausmass NICHT, nur sporadisch treten ähnliche Fehler auf. Und diese konnte ich in den meisten Fällen auf dem Weg der Pakete durchs Netz lokalisieren : Das von mir benutzte WLAN am Wohnort, früher der Übergang von Telekom zu Vodafone (fällt mittlerweile weg, da ich privat Vodafone nutze und auch der Arbeitgeber mit Vodafone arbeitet). Immer dann habe ich an meinem lokalen PC ein "traceroute <öffentliche IP meines Arbeitgebers>" eingegeben und erhielt, wenn die Störung nicht sehr schnell wieder weg war und ich eine gewisse Geduld aufbrachte, die Information, WO es hakte. Und zusätzlich sollten die Logdateien auf beiden XTM330 etwas erzählen. Wir überwachen die mit einer virtuellen Appliance "Dimension" von Watchguard, da können wir etwas mehr als einen Monat in die Vergangenheit sehen.
mfg/Wolfgang
zumindest ich nutze RDP sehr intensiv, nur haben wir keinen festen Tunnel, sondern wählen uns per NCP-Client auf unserer XTM330 ein. Die von Dir beschriebenen Spässe kenne ich in dem Ausmass NICHT, nur sporadisch treten ähnliche Fehler auf. Und diese konnte ich in den meisten Fällen auf dem Weg der Pakete durchs Netz lokalisieren : Das von mir benutzte WLAN am Wohnort, früher der Übergang von Telekom zu Vodafone (fällt mittlerweile weg, da ich privat Vodafone nutze und auch der Arbeitgeber mit Vodafone arbeitet). Immer dann habe ich an meinem lokalen PC ein "traceroute <öffentliche IP meines Arbeitgebers>" eingegeben und erhielt, wenn die Störung nicht sehr schnell wieder weg war und ich eine gewisse Geduld aufbrachte, die Information, WO es hakte. Und zusätzlich sollten die Logdateien auf beiden XTM330 etwas erzählen. Wir überwachen die mit einer virtuellen Appliance "Dimension" von Watchguard, da können wir etwas mehr als einen Monat in die Vergangenheit sehen.
mfg/Wolfgang
Moin,
Das scheint ein anderes Thema als der Tunnel zu sein.
Wenn der Ping durchläuft ist die Strecke ja nicht weg!
Wenn du einen Case aufmachen möchtest, dann über euren Dienstleister!
Wir haben immer sofort jemanden von WA am Hörer. Der Endkundensupport läuft hier meine ich nur über einen Service Vertrag. Da bin ich mir allerdings nicht sich.
Habt ihr ne Dimension im Einsatz und somit einen Überblick was passiert?
Ansonsten installiert den Server und schau dir dann die Logs an.
Nebenbei, hol den Dienstleister mit ins Bot welche die WA verkauft hat.
Gruß
Spirit
Das scheint ein anderes Thema als der Tunnel zu sein.
Wenn der Ping durchläuft ist die Strecke ja nicht weg!
Wenn du einen Case aufmachen möchtest, dann über euren Dienstleister!
Wir haben immer sofort jemanden von WA am Hörer. Der Endkundensupport läuft hier meine ich nur über einen Service Vertrag. Da bin ich mir allerdings nicht sich.
Habt ihr ne Dimension im Einsatz und somit einen Überblick was passiert?
Ansonsten installiert den Server und schau dir dann die Logs an.
Nebenbei, hol den Dienstleister mit ins Bot welche die WA verkauft hat.
Gruß
Spirit
1
Moin moin!
hast du mal an den Leistungseinstellungen am Client versucht, etwas anderes einzustellen?
Einfach mal auf Modem runterstellen wäre mein erster Versuch...
Für mich klingt das mehr nach RDP als nach VPN Problem.
VG
Buc
hast du mal an den Leistungseinstellungen am Client versucht, etwas anderes einzustellen?
Einfach mal auf Modem runterstellen wäre mein erster Versuch...
Für mich klingt das mehr nach RDP als nach VPN Problem.
VG
Buc
N'Abend,
Wenn ihr Support habt, solltet ihr den auch nutzen. Der Support ist OK, notfalls dann per Telefon in englisch.
Den System Manager mitlaufen laufen und gucken was der sagt, notfalls die Debugging Einstellungen für IKE mal hochstellen.
Für längeres Logging die Dimension einfach flott als VM-Image installieren (umsonst für WG Kunden) und in der Firewall einstellen.
Vielleicht ist euer VDSL auch einfach überlastet, sieht du auch beim System Manager ...
VG,
Deepsys
Zitat von @RottenSon667:
ich wollte den Case eigentlich an Watchguard selbst weiter geben, aber deren nicht vorhandener Support lässt die Erstellung von Cases ganz am Ende des Prozesses nicht zu.
???ich wollte den Case eigentlich an Watchguard selbst weiter geben, aber deren nicht vorhandener Support lässt die Erstellung von Cases ganz am Ende des Prozesses nicht zu.
Wenn ihr Support habt, solltet ihr den auch nutzen. Der Support ist OK, notfalls dann per Telefon in englisch.
Der VPN steht permanent, und ich kann unterbrechnungsfrei alles auf der Gegenseite anpingen. Wir haben Antwortzeiten von 60ms, sporadisch auch mal mehr.
Dann würde ich auch mal sagen, der Tunnel ist es nicht.Auf 4250 Pakete habe ich aktuell 5 verlorene.
Hmm, das ist doch nicht permanent, wie hoch ist die Auslastung der Strecke?Wir dachten auch an Probleme mit dem ReKey-ing und haben das mal hoch gesetzt, aber das war es nicht. Da das Latein von mir und dem anderen mit dem Problem betrauten Kollegen leicht am Ende ist wollte ich einmal hier anfragen.
Etwas wichtiges fehlt hier, was sagen die Logs?Den System Manager mitlaufen laufen und gucken was der sagt, notfalls die Debugging Einstellungen für IKE mal hochstellen.
Für längeres Logging die Dimension einfach flott als VM-Image installieren (umsonst für WG Kunden) und in der Firewall einstellen.
Vielleicht ist euer VDSL auch einfach überlastet, sieht du auch beim System Manager ...
VG,
Deepsys
Hallo,
erstmal vielen Dank für die Tipps. Ich werde schon mal den ersten Rat befolgen und mir den Logserver installieren.
Zu euren Fragen:
Wie gesagt, danke erstmal, wir lesen mal Logs und melden uns wieder.
MfG Maik
erstmal vielen Dank für die Tipps. Ich werde schon mal den ersten Rat befolgen und mir den Logserver installieren.
Zu euren Fragen:
- Der Tunnel steht gut, es liegt also nicht an den externen Leitungen. Die sind auch weit entfernt von ausgelastet.
- Settings im RDP Client bringen keinerlei Verbesserung, das war mein erster Versuch, bevor ich bemerkte dass auch andere Dienste diese "hänger" haben. FTP läuft ja auch gut, aber bricht eben auch sporadisch ab.
- Wir können keinen Case auf machen. Ich habe mich bei denen eingeloggt, den Case gestartet, ewig Zeit in die Beschreibung des Problems und die Angabe aller meiner Kontaktdaten investiert, und am Ende wurde mir gesagt der Case kann nicht erstellt werden weil wir keine live Security gekauft haben: "The database cannot associate an active support contract for this serial number. If you believe this is in error, please contact Customer Care at +1(206)613-0456 Option #1."
Wie gesagt, danke erstmal, wir lesen mal Logs und melden uns wieder.
MfG Maik
Zitat von @RottenSon667:
Tja, dann ist das wohl so, oder?- Wir können keinen Case auf machen. Ich habe mich bei denen eingeloggt, den Case gestartet, ewig Zeit in die Beschreibung des Problems und die Angabe aller meiner Kontaktdaten investiert, und am Ende wurde mir gesagt der Case kann nicht erstellt werden weil wir keine live Security gekauft haben: "The database cannot associate an active support contract for this serial number. If you believe this is in error, please contact Customer Care at +1(206)613-0456 Option #1."
Ohne Live Security hast du aber auch keine anderen Abo-Dienste wie Antivirus, IDS, ...
Ach ja, ohne die Live Security kannst du auch kein Update installieren.
Ich traue mich kaum zu fragen, welche Fireware Version hast du?
Wenn die zu alt ist, kann das schon der Fehler sein ...
Das hast Du gut erkannt, Deepsys. Ohne Live Security (320€ / Jahr) reden die nicht mit einem, und ihre (laut Change Notes wirklich UNGLAUBLICH VIELEN) Softwarefehler weden nicht im Zuge einer Nachbesserung behoben, so wie das bei ordentlichen Herstellern wie LANCOM üblich ist.
Wir haben auf einer der beden WG die
11.7.3.B419164
und auf der Anderen die
12.0.B540035.
Ich habe auch schon daran gedacht, dass die Firmwares zu alt sein könnten. Das Dumme ist, dass mir Niemand garantiert, dass der Kram nach Invest von 640€ ordentlich läuft. Genau das ist ja der Knackpunkt. Es KANN daran liegen, und wenn es das täte wäre ich auch nicht unglücklich mit dem Invest. Nur, um das mal eben zu testenisses eben doch zuviel Geld, und da mir der WG Support das nicht garantieren kann (die reden ja nicht mit einem), und man mir beim Distributor der neueren WG auch ohne 120€ Analyse nicht sagen möchte, dass es danach geht habe ich eben keinen Anhaltspunkt.
Wir haben uns jetzt mal mit dem Changelog der Firmwares beschäftigt, und das Ganze ist (gelinde gesagt) schon krass. Die Masse an kritischen Fehlern is schon irre.
MfG Maik
Wir haben auf einer der beden WG die
11.7.3.B419164
und auf der Anderen die
12.0.B540035.
Ich habe auch schon daran gedacht, dass die Firmwares zu alt sein könnten. Das Dumme ist, dass mir Niemand garantiert, dass der Kram nach Invest von 640€ ordentlich läuft. Genau das ist ja der Knackpunkt. Es KANN daran liegen, und wenn es das täte wäre ich auch nicht unglücklich mit dem Invest. Nur, um das mal eben zu testenisses eben doch zuviel Geld, und da mir der WG Support das nicht garantieren kann (die reden ja nicht mit einem), und man mir beim Distributor der neueren WG auch ohne 120€ Analyse nicht sagen möchte, dass es danach geht habe ich eben keinen Anhaltspunkt.
Wir haben uns jetzt mal mit dem Changelog der Firmwares beschäftigt, und das Ganze ist (gelinde gesagt) schon krass. Die Masse an kritischen Fehlern is schon irre.
MfG Maik
Ach so, Zwischeninfos:
Wir haben den Logserver installiert und uns für die Zeiten wo die RDP Abbrüche waren Logfiles gelesen. Da ist nichts ersichtlich, trotz Loglevel DEBUG auf beiden Appliances.
Wir haben den Logserver installiert und uns für die Zeiten wo die RDP Abbrüche waren Logfiles gelesen. Da ist nichts ersichtlich, trotz Loglevel DEBUG auf beiden Appliances.
Wir haben auf einer der beden WG die
11.7.3.B419164
und auf der Anderen die
12.0.B540035.
Das ist beides schon recht alt.
Ab irgend einem Releasestand gibt es auch kein support mehr soweit ich das im Kopf habe.
Wir haben uns jetzt mal mit dem Changelog der Firmwares beschäftigt, und das Ganze ist (gelinde gesagt) schon krass. Die Masse an kritischen Fehlern is schon irre.
Es wurde von Seiten WA gerade in der letzten Zeit ordentlich Hand angelegt, wenn man mal von TDR absieht.
Ich weiß, dass das relativ alt ist. Ich wollte nun die ältere XTM auf den Stand der Neueren heben, und habe beim Bestellvorgang einen Fehler bei der Angabe der S/N begangen. Uns wurde dann gesagt, dass sich die Live-Securty eh immer an das Ablaufdatum koppelt, und man auch wenn es einen Schlüssel zur Vergünstigung gibt müssten wir auf Jahre Livesecurity kaufen. Das ist nun der Gipfel der Frechheit seitens des Herstellers.
Zusammenfassend kann man sagen die Geräte wurden untauglich geliefert, Nachbesserung in Sachen Software muss auf Jahre zurück gezahlt werden (2014 ist die ältere ausgelaufen) und somit fliegen die Geräte dahin wo sie hin gehören: Auf den Müll.
Wir stellen das Ganze auf LANCOM um und haben dann Ruhe.
Danke für Eure Unterstützung, Jungs!
Zusammenfassend kann man sagen die Geräte wurden untauglich geliefert, Nachbesserung in Sachen Software muss auf Jahre zurück gezahlt werden (2014 ist die ältere ausgelaufen) und somit fliegen die Geräte dahin wo sie hin gehören: Auf den Müll.
Wir stellen das Ganze auf LANCOM um und haben dann Ruhe.
Danke für Eure Unterstützung, Jungs!
BTW: Mal als kleine Übersicht dessen, was da nur von der ganz alten auf die etwas weniger alte FW von unseren Boxen gefixt wurde:
11.7.4
The ability to download the OVPN file for use with the iOS and Andriod OpenVPN app is now available. [72237]
The authentication page to download the Mobile VPN with SSL client now sends a “do not remember password” message to the browser. Note that not all browsers honor this message. [73644]
The correct source IP address is now shown in the log file when a Mobile VPN with IPSec user authenticates. [71951]
This release resolves an issue that caused Mobile VPN with IPSec connections to fail to pass traffic due to incomplete route deletion. [72115]
This release resolves an issue that caused Branch Office VPN tunnels to fail after a Multi-WAN failover event when host-based 1-to-1 NAT is also configured. [72480]
This release resolves a crash in the IKED process. [70577]
The option to enable TOS for IPSec now works correctly. [72975]
This release resolves an issue that prevented the XTM 800, XTM 1500, and XTM 2500 Series devices from correctly using the IPSec encryption chipset under certain conditions. [74785]
11.7.5
This release resolves an issue that occurred during Phase 1 negotiation with a third-party IPSec device that caused a missing Phase 1 Security Association on the XTM device. [79260]
A Branch Office VPN failover no longer occurs when one endpoint has a dynamic IP address and the VPN was configured with Command-Line Interface. [73506]
This release resolves an issue that caused branch office VPN traffic to fail because the Global DNAT policy was incorrectly applied. [78840]
A problem that caused a crash in the IKED process has been resolved. [75131]
A kernel crash issue related to high BOVPN traffic has been resolved. [73505]
11.8
The addition of Branch Office VPN Virtual Interface support in this release resolves these issues:
The XTM device can now redistribute its configured BOVPN routes to internal routers. [64553]
You can now use multiple BOVPN peers with overlapping networks.
A configuration error in a Branch Office VPN tunnel no longer causes all VPN traffic to fail. [73387]
Branch Office VPN no longer fails if you have Multi-WAN configured but only one interface selected in the interface group. [57153]
You can now use the same name for both a VPN Gateway and a VPN Tunnel. [66412]
Managed branch office VPN tunnels can now be established when the CRL distribution point (for example, the WatchGuard Management Server or a third-party CRL distribution site you use) is offline. [55946]
This release resolves an issue that caused the IKED process to crash. [75131]
This release resolves a kernel crash associated with L2TP. [76580, 72593]
You can now make an L2TP connection with an IPSec pre-shared key when the L2TP tunnel passes through a device configured for static NAT. [69350]
Mobile VPN with PPTP connections from Android v2.2 mobile devices now work consistently on 3G mobile networks. [63451]
Mobile VPN with SSL now works correctly when bridged to a wireless interface. [70267]
You can now configure the Mobile VPN with SSL client to not remember passwords. [71111]
The Mobile VPN with SSL installation no longer warns Windows users that the Tap Driver is not signed. [43072]
11.8.1
Mobile VPN with SSL connections no longer constantly fail when you use a RADIUS or LDAP authentication server. [77118]
You can now use Mobile VPN with SSL correctly in a bridged network configuration with no kernel crash and reboot. [77237]
This release resolves several issues that prevented the XTM device from correctly releasing virtual IP addresses to Mobile VPN with IPSec clients. [76952, 76087]
This release resolves a kernel crash that occurred when saving a configuration using a branch office VPN virtual interface. [77336]
DHCP relay now works correctly through a BOVPN virtual interface. [76816]
11.8.3
When using the updated WatchGuard IPSec Mobile VPN Client v11.32 (released on 3/19), users no longer experience a connection failure in Phase 1 negotiations, with the log message: “Peer proposes phase one dh_group 2, expecting 1 Debug”. [78813]
Virtual IP address assigned to an IPSec Mobile User are now correctly released after a mobile user disconnects. [76952]
A short traffic disruption for established Mobile VPN with SSL connections no longer occurs when another SSLVPN user connects or disconnects from the firewall. [70152]
An IKED process crash has been resolved. [78692]
This release resolves an issue that caused IPSec VPN traffic to stop passing on XTM 5 Series, 8 Series, and XTM 1050 devices until the device was rebooted, because of a stall on the encryption chip. [77290, 74887, 73784, 78594, 78815, 78029]
11.8.4
Mobile VPN with SSL connections using WatchGuard’s SSLVPN client or OpenVPN client are no longer blocked by the HTTPS proxy. [77969]
11.9
Firebox T10, XTM 25, 26, 33, and 330 devices now proactively start branch office VPN tunnel negotiations whenever the connection to a remote gateway is down. [79959]
The L2TP configuration now syncs correctly from a master XTM device to a backup XTM device in an active/passive FireCluster. [69776]
In a Branch Office VPN virtual interface configuration, if both the local and remote gateways are configured to use policy-based routing (with no zero route), traffic now routes correctly through the tunnel. [76779]
Manual Branch Office VPNs now work correctly when the pre-shared key exceeds 50 characters. [65215]
When a VPN tunnel is first initiated, the XTM device now correctly sends an "icmp destination unreachable" message back to the computer that initiated the tunnel. [72199]
You cannot configure Mobile VPN with SSL to bridge network traffic to a bridged interface. [61844]
11.9.1
When you configure a 1-to-1 NAT rule with a NAT Base IP address that matches the IP address of the external interface, inbound traffic across any VPN that uses that external interface may fail. [64766]
A branch office VPN tunnel no longer appears to be down after a Phase 1 rekey until traffic is sent through the tunnel. [80609]
The Mobile VPN with SSL Mac client now supports the option to remember the user’s password between sessions. [80194]
Traffic now routes correctly through a BOVPN virtual interface when multiple external interfaces are configured. [79026, 79948, 79791]
When a BOVPN virtual interface zero route has a routing metric lower than the default route, policy-based routing no longer sends traffic through the BOVPN virtual interface instead of the configured external interface. [79339]
Firebox System Manager and the Web UI now display warning messages when the active Branch Office VPN tunnel count or current Mobile VPN with IPSec user count reaches the licensed maximum. [71380]
The Mobile VPN with SSL client fails to connect on a Windows 8.1 client computer due to a failure of the TAP driver. [79060]
Workaround
Install the free OpenVPN Portable VPN client, which includes the TAP driver that works with Windows 8.1. Then reinstall the WatchGuard Mobile VPN with SSL client without the TAP driver. See this Knowledge Base article for more information about the workaround.
The certificate used for Mobile VPN with SSL is no longer corrupted after you upgrade from v11.8.3 or older releases. [80910]
If you have Mobile VPN with SSL configured to bridge to the FireCluster Interface for Management IP Address, the FireCluster backup master now correctly joins the cluster after reboot. [80464]
DNS now works correctly after using the Mobile VPN with SSL Mac client on a computer that was not shut down correctly. [75670]
The ability to disable allowed traffic logging is now available for the auto-created DVCP-Allow-SSLVPN-Mgmt policy created for SSLVPN management tunnels. [79366]
11.9.3
You can now configure the Management Server to exclude IPSec certificates as the preferred authentication option for VPN tunnels and instead restrict the authentication method to shared keys. This prevents unnecessary certificate creation and preserves bandwidth for devices that will not use a certification for BOVPNs. [80994]
When you use the v11.9.1 Mobile VPN with SSL client to connect with a Mac client system, you can now resolve VPN network resources by DNS name. [81529]
When a Firebox or XTM device is configured with multiple external interfaces, Mobile VPN with PPTP sessions now connect correctly. [81585, 81498]
A path MTU issue that prevented traffic from successfully passing through a zero route branch office VPN tunnel has been resolved. [77129]
An issue has been resolved that prevented traffic from passing through proxy policies on a central site when traffic was generated from a remote site through a zero route branch office VPN tunnel using 1-to-1 NAT. [81006]
ECMP now works correctly with two Virtual Interface BOVPN tunnels. [81158]
This release resolves an issue that prevented PPTP connections from working correctly with a device configured to use multi-WAN. [81585]
The default setting for Branch Office VPN Phase 2 Force Key Expiration has been updated to rekey only based on time. [74937]
This release resolves an issue that prevented SSLVPN connections after a FireCluster failover event occurred. [76878]
Traffic now routes through the correct branch office VPN tunnel, when the tunnel is configured with 1-to-1 NAT in a multi-WAN environment when the interface used for the VPN was not included in the multi-WAN load balancing configuration. [80389]
11.9.4.1
The Mobile VPN for SSL Mac client has been improved to allow the DNS server setting to stay in use after shutdown or hibernate events. [75670]
VPN failover now works correctly when an IPSec Management Tunnel and a Branch Office VPN tunnel exist between two devices. [82867]
11.9.5
You can now enable TCP MTU Probing to allow VPN traffic to pass through proxy policies on a central site when traffic was generated from a remote site through a zero route VPN tunnel. [81006, 77129]
This release resolves that caused the IKED process to crash and all BOVPN tunnels to fail. [83584]
This release resolves a crash in the oss-daemon that caused all Mobile VPN with SSL tunnels to disconnect. [83885]
11.9.6.1
11.10.
VPN diagnostic messages now appear below the branch office VPN gateway in WatchGuard System Manager, Firebox System Manager, and in the VPN Statistics page in the Fireware Web UI. The VPN diagnostic messages include information about why a VPN tunnel failed, and suggest an action to take to resolve the error. [81287]
The VPN Diagnostic Report now shows the policy checker results for policies that apply to each tunnel route. [81575]
The VPN Diagnostic report now performs more checks to identify the most common VPN issues and includes a new Conclusion section that summarizes errors and suggests actions to take to resolve the error. The VPN Diagnostic report is also available in the VPN Statistics page in the Fireware Web UI. [81286]
SSL Management tunnels now display correctly in Firebox System Manager and WatchGuard System Manager when connected to a FireCluster. [79696]
The VPN Diagnostic Report now shows the address pairs configured for the tunnel. [79705]
This release resolves a crash in the IKED process. [83089]
This release resolves an issue that caused inbound ESP packets for a branch office VPN to be forwarded by a static NAT rule for an IPSec or ANY policy, instead of being accepted by the VPN process on the device. [41822]
The Mobile VPN with SSL client has been updated with a new tap driver to improve compatibility with Windows 8.1 and other new Windows operating systems. [79060, 81204]
Users that authenticate to the Firebox at /sslvpn.html with 2-factor authentication are now correctly redirected to the SSL VPN client download page. [82394]
11.10.1
When Mobile VPN with SSL is bridged to an interface, any secondary networks on that interface are now correctly converted when upgrading to v11.10.1 from a release earlier than v11.9. [84013]
This release resolves an issue that prevented changes to the Mobile VPN with IPSec settings when using the Japanese language Web UI. [85346]
11.10.2
This release resolves several issues that prevented Branch Office VPN tunnels from working correctly after a FireCluster failover. [85800, 86381, 86380, 86534]
Mobile VPN with IPsec connections now work correctly when the user connects from behind a Firebox with a Branch Office VPN to the same remote gateway IP address as the Mobile VPN connection. [86229]
11.10.4
This release includes an updated Mobile VPN with SSL Mac client that supports Mac OS X v10.11 (El Capitan). [87413]
Resolved an issue that caused the BOVPN Virtual Interface to fail when the FireCluster Master reboots. [85957]
Managed BOVPN tunnels and Management Tunnels are now correctly configured for VPN failover when both Firebox devices use Multi-WAN. [83771]
The Mobile VPN with SSL client now correctly updates the DNS server addresses on German and Finnish versions of Windows. [86629]
The Mobile VPN with SSL uninstaller for Mac OS X now correctly removes the Mobile VPN with SSL application directory [87566]
11.10.7
Policy Manager now correctly requires an authentication value other than None in an IPSec proposal when you select the AH proposal Type. [88707]
In Policy Manager, you can now enable NAT-Traversal on a Phase 2 proposal after you change the proposal Type from AH to ESP. [88710]
To avoid confusion, Policy Manager no longer appears to allow you to edit default Phase 2 Proposals. [86597]
This release resolves an issue that caused BOVPN tunnel names that included a special character, such as "&", to fail to display in WatchGuard System Manager and Firebox System Manager. [82642]
The BOVPN Gateway Names are now displayed correctly for Managed BOVPNs within Policy Manager when the device name on the Management Server contains the parentheses characters, such as VPN (seattle). [89237]
Branch Office VPN Phase 1 logic has been improved to accept more variety in 3rd aggressive mode responses. This provides better interoperability with routers such as those from Cybertec. [88626]
An issue that prevented devices managed by a Dimension server from having multiple managed VPNs to remote devices with dynamic external IP addresses has been resolved. [88946]
11.11
This releases resolves a crash of the iked process which caused VPN status to disappear and prevented VPN traffic from passing. [88500]
BOVPNs with PFS enabled now correctly rekey when remote third party endpoints pad the Diffie Hellman Key. [90411]
DNS traffic from the Firebox to a remote DNS server through a BOVPN tunnel now uses an internal interface IP address that matches the tunnel route. [89919]
The Firebox T10-W can now send wireless traffic through a BOVPN virtual interface tunnel. [88580]
The native IPsec VPN clients for Windows and IOS devices can now successfully configure the Domain Suffix information during the client IPSec negotiations with Firewall. [66372][ 65109]
11.11.1
The Mobile VPN with SSL client, when installed on Windows 7 OS, now remembers the default Firebox Web Server Certificate past the initial connection. [89873]
A problem that caused the iked process to crash when Mobile VPN with IPSec is configured has been resolved. [90869]
11.11.2
With this release, we add support for IKEv2 in Branch Office VPN gateways and BOVPN Virtual Interfaces to provide better compatibility with third-party products and greater VPN reliability. [86934]
SNMP counters for BOVPN tunnels will now present the more useful 64-bit integer. [85551]
From Web UI, VPN statistics now display correctly in BOVPN gateways that contain a space in the name. [91254]
This release resolves an issue in which a Branch Office VPN with a space in the name and Broadcast Routing enabled would cause network connections on the Firebox to fail after reboot. [91715]
Dynamic NAT is no longer incorrectly applied to BOVPN connections when the L2TP-IPSec alias is used in the Global DNAT table. [88790]
11.12
You can now configure a Branch Office VPN to Microsoft Azure with IKEv2 and a dynamic tunnel configuration. [89072]
The Firebox now supports Branch Office VPNs that connect to a Cisco Virtual Tunnel Interface, or VTI. [88140]
You can now successfully build a VPN tunnel initiated from AWS Cloud. [92196]
The maximum length of Pre-Shared Keys has been increased from 63 characters to 79 characters. [92275]
An issue that resulted in a memory allocation error that caused low memory and tunnel traffic to fail has been resolved. [92374]
The cookies used to store user credentials for the Mobile VPN with SSL and manual user authentication portal now correctly set the HTTPONLY and Secure attributes. [88687]
Mobile VPN with SSL now uses SHA-1 for authentication and AES-256 for encryption by default. [91506]
The Mobile VPN with IPSec UI now prevents unnecessary tunnel routes from being added when you use the Force All Traffic Through Tunnel option. [90530]
The Firebox no longer automatically adds Any-External to the WatchGuard Authentication policy when you enable Mobile VPN with SSL. [67543]
When you allow access to the Authentication Portal for Mobile VPN with SSL, external hosts are no longer automatically able to also access the Firebox Authentication Portal. [67545]
When you use the Mobile VPN with IPSec NCP client, Policy Manager now generates the client profile with the configured value for the Phase 1 lifetime instead of it always being set to 8 hours. [91678]
11.12.1
PPPoE external interfaces no longer need to restart when you change the NTP, Log Server, or multi-WAN settings on your Firebox. [90146]
PPPoE Link Monitor now works correctly when you use both Link Monitor Ping and TCP with domain names selected.[92506]
The BOVPN New Gateway Endpoint menu now correctly displays the local External interface drop-down list as the first option, and includes a tooltip to indicate that only the primary IP address of the selected External interface will be used for tunnel negotiations. [87940]
The BOVPN Gateway Endpoints list now displays columns in the correct order. [92708]
NAT rules now work correctly when you configure a BOVPN tunnel host route using a /32 subnet mask and 1-to-1 NAT configured. [92700]
This release resolves an issue that caused a Firebox to become unresponsive after a secondary IP address configured as part of a Dynamic NAT rule was removed from the Firebox configuration. [92727]
DWM-221 modem interoperability has been improved. [92809]
BOVPN IKEv2 tunnels to CheckPoint devices now establish correctly. [92707]
11.12.2
BOVPN Virtual Interface now supports an IPSec VPN tunnel to an Amazon AWS virtual private cloud (VPC). [FBX-110, 41534]
You can now specify a different pre-shared key for each gateway endpoint for the same branch office VPN gateway. [FBX-1290, FBX-1292]
In Fireware Web UI, the VPN Statistics System Status page has a new Statistics tab that shows bandwidth and tunnel statistics over time. [FBX-1728]
The Global VPN setting Enable TOS for IPSec is now correctly applied to BOVPN traffic configured to use a Virtual Interface (VIF). [FBX-2349]
Mobile VPN with IPSec no longer fails to reconnect after a non-graceful disconnection. [92935, FBX-2195]
The use of many BOVPN Virtual Interfaces no longer causes a kernel crash. [93193, FBX-2755]
This release resolves an issue with Mobile VPN with SSL that caused incorrect DNS resolution on Windows 10 clients. [88918]
This release updates the Mobile VPN with IPSec client for Mac OS X to add support for Mac OS Sierra.
This release updates the Mobile VPN with IPSec client to resolve an issue related to missing DNS server IP address information. [90324]
11.12.4
This release resolves an IKE process crash that occurred when IKEv2 VPN negotiation fails. [FBX-7050]
The Firebox no longer unexpectedly fragments ESP packets. [FBX-6307]
11.7.4
The ability to download the OVPN file for use with the iOS and Andriod OpenVPN app is now available. [72237]
The authentication page to download the Mobile VPN with SSL client now sends a “do not remember password” message to the browser. Note that not all browsers honor this message. [73644]
The correct source IP address is now shown in the log file when a Mobile VPN with IPSec user authenticates. [71951]
This release resolves an issue that caused Mobile VPN with IPSec connections to fail to pass traffic due to incomplete route deletion. [72115]
This release resolves an issue that caused Branch Office VPN tunnels to fail after a Multi-WAN failover event when host-based 1-to-1 NAT is also configured. [72480]
This release resolves a crash in the IKED process. [70577]
The option to enable TOS for IPSec now works correctly. [72975]
This release resolves an issue that prevented the XTM 800, XTM 1500, and XTM 2500 Series devices from correctly using the IPSec encryption chipset under certain conditions. [74785]
11.7.5
This release resolves an issue that occurred during Phase 1 negotiation with a third-party IPSec device that caused a missing Phase 1 Security Association on the XTM device. [79260]
A Branch Office VPN failover no longer occurs when one endpoint has a dynamic IP address and the VPN was configured with Command-Line Interface. [73506]
This release resolves an issue that caused branch office VPN traffic to fail because the Global DNAT policy was incorrectly applied. [78840]
A problem that caused a crash in the IKED process has been resolved. [75131]
A kernel crash issue related to high BOVPN traffic has been resolved. [73505]
11.8
The addition of Branch Office VPN Virtual Interface support in this release resolves these issues:
The XTM device can now redistribute its configured BOVPN routes to internal routers. [64553]
You can now use multiple BOVPN peers with overlapping networks.
A configuration error in a Branch Office VPN tunnel no longer causes all VPN traffic to fail. [73387]
Branch Office VPN no longer fails if you have Multi-WAN configured but only one interface selected in the interface group. [57153]
You can now use the same name for both a VPN Gateway and a VPN Tunnel. [66412]
Managed branch office VPN tunnels can now be established when the CRL distribution point (for example, the WatchGuard Management Server or a third-party CRL distribution site you use) is offline. [55946]
This release resolves an issue that caused the IKED process to crash. [75131]
This release resolves a kernel crash associated with L2TP. [76580, 72593]
You can now make an L2TP connection with an IPSec pre-shared key when the L2TP tunnel passes through a device configured for static NAT. [69350]
Mobile VPN with PPTP connections from Android v2.2 mobile devices now work consistently on 3G mobile networks. [63451]
Mobile VPN with SSL now works correctly when bridged to a wireless interface. [70267]
You can now configure the Mobile VPN with SSL client to not remember passwords. [71111]
The Mobile VPN with SSL installation no longer warns Windows users that the Tap Driver is not signed. [43072]
11.8.1
Mobile VPN with SSL connections no longer constantly fail when you use a RADIUS or LDAP authentication server. [77118]
You can now use Mobile VPN with SSL correctly in a bridged network configuration with no kernel crash and reboot. [77237]
This release resolves several issues that prevented the XTM device from correctly releasing virtual IP addresses to Mobile VPN with IPSec clients. [76952, 76087]
This release resolves a kernel crash that occurred when saving a configuration using a branch office VPN virtual interface. [77336]
DHCP relay now works correctly through a BOVPN virtual interface. [76816]
11.8.3
When using the updated WatchGuard IPSec Mobile VPN Client v11.32 (released on 3/19), users no longer experience a connection failure in Phase 1 negotiations, with the log message: “Peer proposes phase one dh_group 2, expecting 1 Debug”. [78813]
Virtual IP address assigned to an IPSec Mobile User are now correctly released after a mobile user disconnects. [76952]
A short traffic disruption for established Mobile VPN with SSL connections no longer occurs when another SSLVPN user connects or disconnects from the firewall. [70152]
An IKED process crash has been resolved. [78692]
This release resolves an issue that caused IPSec VPN traffic to stop passing on XTM 5 Series, 8 Series, and XTM 1050 devices until the device was rebooted, because of a stall on the encryption chip. [77290, 74887, 73784, 78594, 78815, 78029]
11.8.4
Mobile VPN with SSL connections using WatchGuard’s SSLVPN client or OpenVPN client are no longer blocked by the HTTPS proxy. [77969]
11.9
Firebox T10, XTM 25, 26, 33, and 330 devices now proactively start branch office VPN tunnel negotiations whenever the connection to a remote gateway is down. [79959]
The L2TP configuration now syncs correctly from a master XTM device to a backup XTM device in an active/passive FireCluster. [69776]
In a Branch Office VPN virtual interface configuration, if both the local and remote gateways are configured to use policy-based routing (with no zero route), traffic now routes correctly through the tunnel. [76779]
Manual Branch Office VPNs now work correctly when the pre-shared key exceeds 50 characters. [65215]
When a VPN tunnel is first initiated, the XTM device now correctly sends an "icmp destination unreachable" message back to the computer that initiated the tunnel. [72199]
You cannot configure Mobile VPN with SSL to bridge network traffic to a bridged interface. [61844]
11.9.1
When you configure a 1-to-1 NAT rule with a NAT Base IP address that matches the IP address of the external interface, inbound traffic across any VPN that uses that external interface may fail. [64766]
A branch office VPN tunnel no longer appears to be down after a Phase 1 rekey until traffic is sent through the tunnel. [80609]
The Mobile VPN with SSL Mac client now supports the option to remember the user’s password between sessions. [80194]
Traffic now routes correctly through a BOVPN virtual interface when multiple external interfaces are configured. [79026, 79948, 79791]
When a BOVPN virtual interface zero route has a routing metric lower than the default route, policy-based routing no longer sends traffic through the BOVPN virtual interface instead of the configured external interface. [79339]
Firebox System Manager and the Web UI now display warning messages when the active Branch Office VPN tunnel count or current Mobile VPN with IPSec user count reaches the licensed maximum. [71380]
The Mobile VPN with SSL client fails to connect on a Windows 8.1 client computer due to a failure of the TAP driver. [79060]
Workaround
Install the free OpenVPN Portable VPN client, which includes the TAP driver that works with Windows 8.1. Then reinstall the WatchGuard Mobile VPN with SSL client without the TAP driver. See this Knowledge Base article for more information about the workaround.
The certificate used for Mobile VPN with SSL is no longer corrupted after you upgrade from v11.8.3 or older releases. [80910]
If you have Mobile VPN with SSL configured to bridge to the FireCluster Interface for Management IP Address, the FireCluster backup master now correctly joins the cluster after reboot. [80464]
DNS now works correctly after using the Mobile VPN with SSL Mac client on a computer that was not shut down correctly. [75670]
The ability to disable allowed traffic logging is now available for the auto-created DVCP-Allow-SSLVPN-Mgmt policy created for SSLVPN management tunnels. [79366]
11.9.3
You can now configure the Management Server to exclude IPSec certificates as the preferred authentication option for VPN tunnels and instead restrict the authentication method to shared keys. This prevents unnecessary certificate creation and preserves bandwidth for devices that will not use a certification for BOVPNs. [80994]
When you use the v11.9.1 Mobile VPN with SSL client to connect with a Mac client system, you can now resolve VPN network resources by DNS name. [81529]
When a Firebox or XTM device is configured with multiple external interfaces, Mobile VPN with PPTP sessions now connect correctly. [81585, 81498]
A path MTU issue that prevented traffic from successfully passing through a zero route branch office VPN tunnel has been resolved. [77129]
An issue has been resolved that prevented traffic from passing through proxy policies on a central site when traffic was generated from a remote site through a zero route branch office VPN tunnel using 1-to-1 NAT. [81006]
ECMP now works correctly with two Virtual Interface BOVPN tunnels. [81158]
This release resolves an issue that prevented PPTP connections from working correctly with a device configured to use multi-WAN. [81585]
The default setting for Branch Office VPN Phase 2 Force Key Expiration has been updated to rekey only based on time. [74937]
This release resolves an issue that prevented SSLVPN connections after a FireCluster failover event occurred. [76878]
Traffic now routes through the correct branch office VPN tunnel, when the tunnel is configured with 1-to-1 NAT in a multi-WAN environment when the interface used for the VPN was not included in the multi-WAN load balancing configuration. [80389]
11.9.4.1
The Mobile VPN for SSL Mac client has been improved to allow the DNS server setting to stay in use after shutdown or hibernate events. [75670]
VPN failover now works correctly when an IPSec Management Tunnel and a Branch Office VPN tunnel exist between two devices. [82867]
11.9.5
You can now enable TCP MTU Probing to allow VPN traffic to pass through proxy policies on a central site when traffic was generated from a remote site through a zero route VPN tunnel. [81006, 77129]
This release resolves that caused the IKED process to crash and all BOVPN tunnels to fail. [83584]
This release resolves a crash in the oss-daemon that caused all Mobile VPN with SSL tunnels to disconnect. [83885]
11.9.6.1
11.10.
VPN diagnostic messages now appear below the branch office VPN gateway in WatchGuard System Manager, Firebox System Manager, and in the VPN Statistics page in the Fireware Web UI. The VPN diagnostic messages include information about why a VPN tunnel failed, and suggest an action to take to resolve the error. [81287]
The VPN Diagnostic Report now shows the policy checker results for policies that apply to each tunnel route. [81575]
The VPN Diagnostic report now performs more checks to identify the most common VPN issues and includes a new Conclusion section that summarizes errors and suggests actions to take to resolve the error. The VPN Diagnostic report is also available in the VPN Statistics page in the Fireware Web UI. [81286]
SSL Management tunnels now display correctly in Firebox System Manager and WatchGuard System Manager when connected to a FireCluster. [79696]
The VPN Diagnostic Report now shows the address pairs configured for the tunnel. [79705]
This release resolves a crash in the IKED process. [83089]
This release resolves an issue that caused inbound ESP packets for a branch office VPN to be forwarded by a static NAT rule for an IPSec or ANY policy, instead of being accepted by the VPN process on the device. [41822]
The Mobile VPN with SSL client has been updated with a new tap driver to improve compatibility with Windows 8.1 and other new Windows operating systems. [79060, 81204]
Users that authenticate to the Firebox at /sslvpn.html with 2-factor authentication are now correctly redirected to the SSL VPN client download page. [82394]
11.10.1
When Mobile VPN with SSL is bridged to an interface, any secondary networks on that interface are now correctly converted when upgrading to v11.10.1 from a release earlier than v11.9. [84013]
This release resolves an issue that prevented changes to the Mobile VPN with IPSec settings when using the Japanese language Web UI. [85346]
11.10.2
This release resolves several issues that prevented Branch Office VPN tunnels from working correctly after a FireCluster failover. [85800, 86381, 86380, 86534]
Mobile VPN with IPsec connections now work correctly when the user connects from behind a Firebox with a Branch Office VPN to the same remote gateway IP address as the Mobile VPN connection. [86229]
11.10.4
This release includes an updated Mobile VPN with SSL Mac client that supports Mac OS X v10.11 (El Capitan). [87413]
Resolved an issue that caused the BOVPN Virtual Interface to fail when the FireCluster Master reboots. [85957]
Managed BOVPN tunnels and Management Tunnels are now correctly configured for VPN failover when both Firebox devices use Multi-WAN. [83771]
The Mobile VPN with SSL client now correctly updates the DNS server addresses on German and Finnish versions of Windows. [86629]
The Mobile VPN with SSL uninstaller for Mac OS X now correctly removes the Mobile VPN with SSL application directory [87566]
11.10.7
Policy Manager now correctly requires an authentication value other than None in an IPSec proposal when you select the AH proposal Type. [88707]
In Policy Manager, you can now enable NAT-Traversal on a Phase 2 proposal after you change the proposal Type from AH to ESP. [88710]
To avoid confusion, Policy Manager no longer appears to allow you to edit default Phase 2 Proposals. [86597]
This release resolves an issue that caused BOVPN tunnel names that included a special character, such as "&", to fail to display in WatchGuard System Manager and Firebox System Manager. [82642]
The BOVPN Gateway Names are now displayed correctly for Managed BOVPNs within Policy Manager when the device name on the Management Server contains the parentheses characters, such as VPN (seattle). [89237]
Branch Office VPN Phase 1 logic has been improved to accept more variety in 3rd aggressive mode responses. This provides better interoperability with routers such as those from Cybertec. [88626]
An issue that prevented devices managed by a Dimension server from having multiple managed VPNs to remote devices with dynamic external IP addresses has been resolved. [88946]
11.11
This releases resolves a crash of the iked process which caused VPN status to disappear and prevented VPN traffic from passing. [88500]
BOVPNs with PFS enabled now correctly rekey when remote third party endpoints pad the Diffie Hellman Key. [90411]
DNS traffic from the Firebox to a remote DNS server through a BOVPN tunnel now uses an internal interface IP address that matches the tunnel route. [89919]
The Firebox T10-W can now send wireless traffic through a BOVPN virtual interface tunnel. [88580]
The native IPsec VPN clients for Windows and IOS devices can now successfully configure the Domain Suffix information during the client IPSec negotiations with Firewall. [66372][ 65109]
11.11.1
The Mobile VPN with SSL client, when installed on Windows 7 OS, now remembers the default Firebox Web Server Certificate past the initial connection. [89873]
A problem that caused the iked process to crash when Mobile VPN with IPSec is configured has been resolved. [90869]
11.11.2
With this release, we add support for IKEv2 in Branch Office VPN gateways and BOVPN Virtual Interfaces to provide better compatibility with third-party products and greater VPN reliability. [86934]
SNMP counters for BOVPN tunnels will now present the more useful 64-bit integer. [85551]
From Web UI, VPN statistics now display correctly in BOVPN gateways that contain a space in the name. [91254]
This release resolves an issue in which a Branch Office VPN with a space in the name and Broadcast Routing enabled would cause network connections on the Firebox to fail after reboot. [91715]
Dynamic NAT is no longer incorrectly applied to BOVPN connections when the L2TP-IPSec alias is used in the Global DNAT table. [88790]
11.12
You can now configure a Branch Office VPN to Microsoft Azure with IKEv2 and a dynamic tunnel configuration. [89072]
The Firebox now supports Branch Office VPNs that connect to a Cisco Virtual Tunnel Interface, or VTI. [88140]
You can now successfully build a VPN tunnel initiated from AWS Cloud. [92196]
The maximum length of Pre-Shared Keys has been increased from 63 characters to 79 characters. [92275]
An issue that resulted in a memory allocation error that caused low memory and tunnel traffic to fail has been resolved. [92374]
The cookies used to store user credentials for the Mobile VPN with SSL and manual user authentication portal now correctly set the HTTPONLY and Secure attributes. [88687]
Mobile VPN with SSL now uses SHA-1 for authentication and AES-256 for encryption by default. [91506]
The Mobile VPN with IPSec UI now prevents unnecessary tunnel routes from being added when you use the Force All Traffic Through Tunnel option. [90530]
The Firebox no longer automatically adds Any-External to the WatchGuard Authentication policy when you enable Mobile VPN with SSL. [67543]
When you allow access to the Authentication Portal for Mobile VPN with SSL, external hosts are no longer automatically able to also access the Firebox Authentication Portal. [67545]
When you use the Mobile VPN with IPSec NCP client, Policy Manager now generates the client profile with the configured value for the Phase 1 lifetime instead of it always being set to 8 hours. [91678]
11.12.1
PPPoE external interfaces no longer need to restart when you change the NTP, Log Server, or multi-WAN settings on your Firebox. [90146]
PPPoE Link Monitor now works correctly when you use both Link Monitor Ping and TCP with domain names selected.[92506]
The BOVPN New Gateway Endpoint menu now correctly displays the local External interface drop-down list as the first option, and includes a tooltip to indicate that only the primary IP address of the selected External interface will be used for tunnel negotiations. [87940]
The BOVPN Gateway Endpoints list now displays columns in the correct order. [92708]
NAT rules now work correctly when you configure a BOVPN tunnel host route using a /32 subnet mask and 1-to-1 NAT configured. [92700]
This release resolves an issue that caused a Firebox to become unresponsive after a secondary IP address configured as part of a Dynamic NAT rule was removed from the Firebox configuration. [92727]
DWM-221 modem interoperability has been improved. [92809]
BOVPN IKEv2 tunnels to CheckPoint devices now establish correctly. [92707]
11.12.2
BOVPN Virtual Interface now supports an IPSec VPN tunnel to an Amazon AWS virtual private cloud (VPC). [FBX-110, 41534]
You can now specify a different pre-shared key for each gateway endpoint for the same branch office VPN gateway. [FBX-1290, FBX-1292]
In Fireware Web UI, the VPN Statistics System Status page has a new Statistics tab that shows bandwidth and tunnel statistics over time. [FBX-1728]
The Global VPN setting Enable TOS for IPSec is now correctly applied to BOVPN traffic configured to use a Virtual Interface (VIF). [FBX-2349]
Mobile VPN with IPSec no longer fails to reconnect after a non-graceful disconnection. [92935, FBX-2195]
The use of many BOVPN Virtual Interfaces no longer causes a kernel crash. [93193, FBX-2755]
This release resolves an issue with Mobile VPN with SSL that caused incorrect DNS resolution on Windows 10 clients. [88918]
This release updates the Mobile VPN with IPSec client for Mac OS X to add support for Mac OS Sierra.
This release updates the Mobile VPN with IPSec client to resolve an issue related to missing DNS server IP address information. [90324]
11.12.4
This release resolves an IKE process crash that occurred when IKEv2 VPN negotiation fails. [FBX-7050]
The Firebox no longer unexpectedly fragments ESP packets. [FBX-6307]
Zitat von @RottenSon667:
Zusammenfassend kann man sagen die Geräte wurden untauglich geliefert, Nachbesserung in Sachen Software muss auf Jahre zurück gezahlt werden (2014 ist die ältere ausgelaufen) und somit fliegen die Geräte dahin wo sie hin gehören: Auf den Müll.
Dann sende mir die Kisten zu, ich nehme die Zusammenfassend kann man sagen die Geräte wurden untauglich geliefert, Nachbesserung in Sachen Software muss auf Jahre zurück gezahlt werden (2014 ist die ältere ausgelaufen) und somit fliegen die Geräte dahin wo sie hin gehören: Auf den Müll.
Wir stellen das Ganze auf LANCOM um und haben dann Ruhe.
Na dann noch mehr Spaß, ich habe das mal bei einer Firewall probiert und die Syntax nicht verstanden. Das fand ich bei WG besser.Aber OK, eure Entscheidung.
Es gibt übrigens etliche Hersteller wo du neue Versionen nur nach Support bekommst.
Übrigens, finde ich das die Kisten was taugen, klar sind das viele Fehler. Aber WG gibt die wenigsten zu, andere packen unter "others errors" oder so.
Ich bin damit jedenfalls zufrieden und die allermeisten Fehler merkst du nicht, und wenn du einen Fehler hast, wird der wohl gefixt.
Schon öfter gehabt.
Wir hatten mal einen defekten Cisco-Router vor Jahren, da wollte uns Cisco auch nicht helfen, da der 3 Tage aus der Garantie war ...
