SSL-VPN mit Watchguard XTM330 Problem
Hallo liebe Experten,
ich habe hier ein Problem mit dem ich einfach nicht weiter komme. Wir haben in der Firma bisher eine VDSL-Leitung mit einem Fritz!Box 3370 Router. Die Fritz!Box hatte unsere alte Firewall (Cisco ASA 5505) als Exposed Host angegeben. Damit haben wir Problemlos VPN per IPSec benutzen können.
Die Firewall wird nun durch eine Watchguard XTM330 ersetzt und wir wollen SSL-VPN nutzen. Nun habe ich am WE alles umgehängt und den VPN-Access per SSL-VPN-Client getestet. Der erste Eindruck war, alles läuft. Aber das war trügerisch. Zum Test habe ich mich per WLAN auf die Fritz!Box eingewählt, also ausseralb des geschützten Netzes. VPN-Client tut was er soll und verbindet. Remotezugang zu unserem Terminal-Server klappt.
Danach habe ich das ganze über das Internet probiert und diesmal scheitert es. Zum Test nahm ich einmal eine UMTS-Verbindung und Verbindungen von meinem Home Office aus und vom Home Office eines Angestellten. Dabei spuckte mir der Client im Log folgendes aus:
UMTS-Verbindung: "connection refused"
Mein HomeOffice: "network unreachable"
Angestellten-Home Office: "connection time out"
Das Notebook was ich aus meinem HomeOffice benutzt habe, war das was die Verbindung über das WLAN der Fritzbox herstellen konnte.
Des weiteren bleibt zu erwähnen, dass die Anmeldung über den Browser funtionierte. Ich konnte sowohl über das Internet den Client von der Firebox ziehen als mich auch dort authentifizieren.
Ich habe mittlerweile stark die Fritz!Box in verdacht. Ich habe gelesesn, dass die Fritz!Box VPN Passthrough für IPSec und PPTP bietet. SSL war nicht extra erwähnt.
Der Watchguard-Support wollte sich testweise gern ab Montag einwählen, aber ich musste ja wieder auf den Cisco zurückbauen, dass die Mitarbeiter Montag wieder arbeiten können.
Für Anregungen woran dieses Verhalten liegen kann wäre ich sehr dankbar. Falls der Verdacht der Fritz!Box Sinn macht, was gibt es für VDSL-Router die definitiv den SSL-VPN-Client durchlassen?
Mit freundlichen Grüßen
MLubrich
ich habe hier ein Problem mit dem ich einfach nicht weiter komme. Wir haben in der Firma bisher eine VDSL-Leitung mit einem Fritz!Box 3370 Router. Die Fritz!Box hatte unsere alte Firewall (Cisco ASA 5505) als Exposed Host angegeben. Damit haben wir Problemlos VPN per IPSec benutzen können.
Die Firewall wird nun durch eine Watchguard XTM330 ersetzt und wir wollen SSL-VPN nutzen. Nun habe ich am WE alles umgehängt und den VPN-Access per SSL-VPN-Client getestet. Der erste Eindruck war, alles läuft. Aber das war trügerisch. Zum Test habe ich mich per WLAN auf die Fritz!Box eingewählt, also ausseralb des geschützten Netzes. VPN-Client tut was er soll und verbindet. Remotezugang zu unserem Terminal-Server klappt.
Danach habe ich das ganze über das Internet probiert und diesmal scheitert es. Zum Test nahm ich einmal eine UMTS-Verbindung und Verbindungen von meinem Home Office aus und vom Home Office eines Angestellten. Dabei spuckte mir der Client im Log folgendes aus:
UMTS-Verbindung: "connection refused"
Mein HomeOffice: "network unreachable"
Angestellten-Home Office: "connection time out"
Das Notebook was ich aus meinem HomeOffice benutzt habe, war das was die Verbindung über das WLAN der Fritzbox herstellen konnte.
Des weiteren bleibt zu erwähnen, dass die Anmeldung über den Browser funtionierte. Ich konnte sowohl über das Internet den Client von der Firebox ziehen als mich auch dort authentifizieren.
Ich habe mittlerweile stark die Fritz!Box in verdacht. Ich habe gelesesn, dass die Fritz!Box VPN Passthrough für IPSec und PPTP bietet. SSL war nicht extra erwähnt.
Der Watchguard-Support wollte sich testweise gern ab Montag einwählen, aber ich musste ja wieder auf den Cisco zurückbauen, dass die Mitarbeiter Montag wieder arbeiten können.
Für Anregungen woran dieses Verhalten liegen kann wäre ich sehr dankbar. Falls der Verdacht der Fritz!Box Sinn macht, was gibt es für VDSL-Router die definitiv den SSL-VPN-Client durchlassen?
Mit freundlichen Grüßen
MLubrich
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 220593
Url: https://administrator.de/forum/ssl-vpn-mit-watchguard-xtm330-problem-220593.html
Ausgedruckt am: 13.05.2025 um 02:05 Uhr
16 Kommentare
Neuester Kommentar
Hallo,
verstehe ich das nun alles richtig und du kommst einfach nicht auf den SSL-Port der Watchguard?
Das kannst du einfach testen (Hilfetext der XTM):
1.Connect to this address with a web browser:
https://<IP address of an XTM device interface>/sslvpn.html
or
https://<Host name of the XTM device>/sslvpn.html
Wenn da nichts kommt, macht deine Fritzbox keine SSL (Port 443) Weiterleitung zur XTM.
Das ist kein Passthrough für IPSEC oder PPPTP, sondern einfach eine Portweiterleitung.
VG
Deepsys
verstehe ich das nun alles richtig und du kommst einfach nicht auf den SSL-Port der Watchguard?
Das kannst du einfach testen (Hilfetext der XTM):
1.Connect to this address with a web browser:
https://<IP address of an XTM device interface>/sslvpn.html
or
https://<Host name of the XTM device>/sslvpn.html
Wenn da nichts kommt, macht deine Fritzbox keine SSL (Port 443) Weiterleitung zur XTM.
Das ist kein Passthrough für IPSEC oder PPPTP, sondern einfach eine Portweiterleitung.
VG
Deepsys
Wie Deepsys schon sagt solltest du das prüfen.
Darauf aufbauend empfiehlt es sich die WatchGuard XTM330 nicht hinter einem Router zu betreiben, da dann genau sowas auftritt wie jetzt und du im Prinzip eine Fehlerquelle mehr hast. Wir nutzen unsere XTM330 immer hinter einfachen Modems.
Ansonsten wenn es unbedingt ein Router sein soll, musst du schauen das du ihn entweder als Bridge konfigurierst oder einfach alle Ports zur WatchGuard durchlässt. Was du dann in deinem Netz brauchst und weiterleitest stellst du dann ja eh nur mit deiner WatchGuard ein.
Darauf aufbauend empfiehlt es sich die WatchGuard XTM330 nicht hinter einem Router zu betreiben, da dann genau sowas auftritt wie jetzt und du im Prinzip eine Fehlerquelle mehr hast. Wir nutzen unsere XTM330 immer hinter einfachen Modems.
Ansonsten wenn es unbedingt ein Router sein soll, musst du schauen das du ihn entweder als Bridge konfigurierst oder einfach alle Ports zur WatchGuard durchlässt. Was du dann in deinem Netz brauchst und weiterleitest stellst du dann ja eh nur mit deiner WatchGuard ein.
Hallo,
ich hab ja geschrieben, dass es über den Browser funktioniert. Ich kann mir über "https://<IP address of an XTM device interface>/sslvpn.html" den client herunterladen oder mich über "https://<IP address of an XTM device interface>:443" authentifizieren. Einzig und allein der Zugriff per Client will nicht verbinden, wenn ich aus dem Internet komme. Um Remotedesktop zum Terminal-Server zu nutzen muss man aber mit dem Client arbeiten.
Ich habe die XTM330 jetzt mal mit nach Hause genommen und da alles nachgestellt. Wieder dasselbe Spiel, nur mit einer Fritzbox 7390.
Ich würde die Fritzbox gern als Router laufen lassen, da sie gute WLAN-Abdeckung macht, und wir das WLAN der FB als Gastzugang nutzen. Sollte ich die FB zum Modem degradieren und die Firebox das Verbinden übernehmen lassen, wo in der Firebox gebe ich denn die Zugangsdaten ein?
Vielen Dank
MLubrich
ich hab ja geschrieben, dass es über den Browser funktioniert. Ich kann mir über "https://<IP address of an XTM device interface>/sslvpn.html" den client herunterladen oder mich über "https://<IP address of an XTM device interface>:443" authentifizieren. Einzig und allein der Zugriff per Client will nicht verbinden, wenn ich aus dem Internet komme. Um Remotedesktop zum Terminal-Server zu nutzen muss man aber mit dem Client arbeiten.
Ich habe die XTM330 jetzt mal mit nach Hause genommen und da alles nachgestellt. Wieder dasselbe Spiel, nur mit einer Fritzbox 7390.
Ich würde die Fritzbox gern als Router laufen lassen, da sie gute WLAN-Abdeckung macht, und wir das WLAN der FB als Gastzugang nutzen. Sollte ich die FB zum Modem degradieren und die Firebox das Verbinden übernehmen lassen, wo in der Firebox gebe ich denn die Zugangsdaten ein?
Vielen Dank
MLubrich
Zitat von @MLubrich:
Hallo,
Einzig und allein der Zugriff per Client will nicht verbinden, wenn ich aus dem Internet
komme.
Und was sagt denn die XTM dazu (System Manager)?Hallo,
Einzig und allein der Zugriff per Client will nicht verbinden, wenn ich aus dem Internet
komme.
Sind es AD-Konten oder lokale XTM-Konten?
VG
Ich habe beide Anmeldearten probiert, sowohl FB-User also auch AD-User haben dasselbe Problem.
Im Syslog steht auch wenn ich mich über Internet anmelde:
Authentication of SSLVPN user [Username] from xxx.xxx.xxx.xxx accepted.
In der Authentication List steht der User dann drin, allerdings mit IP 0.0.0.0, statt der neu zugewiesenen.
Mit freundlichen Grüßen
MLubrich
Im Syslog steht auch wenn ich mich über Internet anmelde:
Authentication of SSLVPN user [Username] from xxx.xxx.xxx.xxx accepted.
In der Authentication List steht der User dann drin, allerdings mit IP 0.0.0.0, statt der neu zugewiesenen.
Mit freundlichen Grüßen
MLubrich
Bitte mal den kompletten Teil, und sicherheitshalber nicht vom Syslog, sondern wenn es geht aus dem System Manager.
Hier die Logs aus dem System Manager, zuerst die fehlgeschlagene Verbindung:
2013-10-28 14:59:44 admd Authentication of SSLVPN user [user] from xxx.xxx.xxx.xxx accepted id="1100-0004" Event
2013-10-28 14:59:44 sslvpn Received Session Status Change event, current state:0x400 Debug
2013-10-28 14:59:44 sslvpn sslvpn_event, delete entry, entry->virtual_ip=0, dropin_mode=0 Debug
2013-10-28 14:59:44 sessiond failed on wgapi_status_query(): xpath=/toSessionClient/delete session 28 Debug
2013-10-28 14:59:44 sslvpn Received Session Status Change event, current state:0x400 Debug
2013-10-28 14:59:44 sslvpn sslvpn_event, add entry, entry->virtual_ip=0, entry->real_ip=5792346d, dropin_mode=0 Debug
2013-10-28 14:59:44 wgcgi device_session_find, username=user, userId=user, auth domain=meine.domain Debug
2013-10-28 14:59:44 kernel [11020.114247] xt_session: Deleted session for 0.0.0.0 id 28 Debug
Und so sieht es aus wenn die Verbindung über einen PC hergestellt wird, der an der Fritzbox hängt:
2013-10-28 15:42:04 admd Authentication of SSLVPN user [user] from xxx.xxx.xxx.xxx accepted id="1100-0004" Event
2013-10-28 15:42:04 sslvpn auth: wgapi: rcved cmd=1 '/toAdmdClient/authResult' Debug
2013-10-28 15:42:04 sslvpn get into test_auth_prcs_status(): xpath=/toAdmdClient/authResult Debug
2013-10-28 15:42:04 sslvpn rcved auth reply: authResult=1 Debug
2013-10-28 15:42:04 sslvpn ---------<<<RESULT rcvd, [user] ACCEPTED. Debug
2013-10-28 15:42:04 sslvpn num_groups=1 Debug
2013-10-28 15:42:04 sslvpn group Id # 0 = VPN Debug
2013-10-28 15:42:04 sslvpn Other attributes: Debug
2013-10-28 15:42:04 sslvpn ip=0x0, ip_mask=0x0, dns_ip=0x0, wins_ip=0x0 , ip_lease_time=-1, idle_timeout=-1 Debug
2013-10-28 15:42:04 sslvpn User Authenticated Debug
2013-10-28 15:42:04 sslvpn sessClt: OK! wgUserSess_create_sess() Debug
2013-10-28 15:42:04 sslvpn th: curtime=1382971324 Debug
2013-10-28 15:42:04 sslvpn Received Session Status Change event, current state:0x400 Debug
2013-10-28 15:42:04 sslvpn sslvpn_event, add entry, entry->virtual_ip=0, entry->real_ip=a0a0a14, dropin_mode=0 Debug
2013-10-28 15:42:04 sslvpn sessiond: wgapi: rcved cmd=1 '/toSessionClient/createNotify' Debug
2013-10-28 15:42:04 sslvpn get into test_sess_prcs_status(): xpath=/toSessionClient/createNotify Debug
2013-10-28 15:42:04 sslvpn recved create sess notify, sessId=36 Debug
2013-10-28 15:42:04 sslvpn Session Creation For User Done Debug
Mit freundlichen Grüßen
MLubrich
2013-10-28 14:59:44 admd Authentication of SSLVPN user [user] from xxx.xxx.xxx.xxx accepted id="1100-0004" Event
2013-10-28 14:59:44 sslvpn Received Session Status Change event, current state:0x400 Debug
2013-10-28 14:59:44 sslvpn sslvpn_event, delete entry, entry->virtual_ip=0, dropin_mode=0 Debug
2013-10-28 14:59:44 sessiond failed on wgapi_status_query(): xpath=/toSessionClient/delete session 28 Debug
2013-10-28 14:59:44 sslvpn Received Session Status Change event, current state:0x400 Debug
2013-10-28 14:59:44 sslvpn sslvpn_event, add entry, entry->virtual_ip=0, entry->real_ip=5792346d, dropin_mode=0 Debug
2013-10-28 14:59:44 wgcgi device_session_find, username=user, userId=user, auth domain=meine.domain Debug
2013-10-28 14:59:44 kernel [11020.114247] xt_session: Deleted session for 0.0.0.0 id 28 Debug
Und so sieht es aus wenn die Verbindung über einen PC hergestellt wird, der an der Fritzbox hängt:
2013-10-28 15:42:04 admd Authentication of SSLVPN user [user] from xxx.xxx.xxx.xxx accepted id="1100-0004" Event
2013-10-28 15:42:04 sslvpn auth: wgapi: rcved cmd=1 '/toAdmdClient/authResult' Debug
2013-10-28 15:42:04 sslvpn get into test_auth_prcs_status(): xpath=/toAdmdClient/authResult Debug
2013-10-28 15:42:04 sslvpn rcved auth reply: authResult=1 Debug
2013-10-28 15:42:04 sslvpn ---------<<<RESULT rcvd, [user] ACCEPTED. Debug
2013-10-28 15:42:04 sslvpn num_groups=1 Debug
2013-10-28 15:42:04 sslvpn group Id # 0 = VPN Debug
2013-10-28 15:42:04 sslvpn Other attributes: Debug
2013-10-28 15:42:04 sslvpn ip=0x0, ip_mask=0x0, dns_ip=0x0, wins_ip=0x0 , ip_lease_time=-1, idle_timeout=-1 Debug
2013-10-28 15:42:04 sslvpn User Authenticated Debug
2013-10-28 15:42:04 sslvpn sessClt: OK! wgUserSess_create_sess() Debug
2013-10-28 15:42:04 sslvpn th: curtime=1382971324 Debug
2013-10-28 15:42:04 sslvpn Received Session Status Change event, current state:0x400 Debug
2013-10-28 15:42:04 sslvpn sslvpn_event, add entry, entry->virtual_ip=0, entry->real_ip=a0a0a14, dropin_mode=0 Debug
2013-10-28 15:42:04 sslvpn sessiond: wgapi: rcved cmd=1 '/toSessionClient/createNotify' Debug
2013-10-28 15:42:04 sslvpn get into test_sess_prcs_status(): xpath=/toSessionClient/createNotify Debug
2013-10-28 15:42:04 sslvpn recved create sess notify, sessId=36 Debug
2013-10-28 15:42:04 sslvpn Session Creation For User Done Debug
Mit freundlichen Grüßen
MLubrich
Hmm, das sagt mir nun auch nicht wirklich was ...
Du hast aber auch eine Firewall-Regel die von der betreffenden Schnittstelle aus SSL erlaubt?
Ansonsten mach einfach mal einen Support-Case auf, dann will Watchguard wahrscheinlich in deine Konfig gucken und dann sollte das schnell erledigt sein
VG
Deepsys
Du hast aber auch eine Firewall-Regel die von der betreffenden Schnittstelle aus SSL erlaubt?
Ansonsten mach einfach mal einen Support-Case auf, dann will Watchguard wahrscheinlich in deine Konfig gucken und dann sollte das schnell erledigt sein
VG
Deepsys
Das Log macht mich auch ratlos. Die Policy wird soweit ich das richtig verstanden habe automatisch erstellt, wenn man den Mobile VPN einrichtet. Ich werde heute mal den Workaround versuchen, die FB zum Modem zu degradieren und die XTM330 das Verbinden übernehmen zu lassen.
Mir freundlichen Grüßen
MLubrich
Mir freundlichen Grüßen
MLubrich
Zitat von @MLubrich:
Ich werde heute mal den Workaround versuchen, die FB zum Modem zu degradieren und die XTM330 das Verbinden übernehmen zu lassen.
Und warum nicht den Support um Hilfe bitten?Ich werde heute mal den Workaround versuchen, die FB zum Modem zu degradieren und die XTM330 das Verbinden übernehmen zu lassen.
Der ist wirklich nicht schlecht ...
Das habe ich schon, aber seit dem das Ticket erstellt habe ist nichts mehr passiert. Das einzige wie ich mit meinem Bearbeiter kommunizieren kann ist ja einen neuen Comment hinzuzufügen. Und da ist jedenfalls gestern im Laufe des Tages nichts passiert.
Mit freundlichen Grüßen
MLubrich
Mit freundlichen Grüßen
MLubrich
Zitat von @MLubrich:
Ich würde die Fritzbox gern als Router laufen lassen, da sie gute WLAN-Abdeckung macht, und wir das WLAN der FB als
Gastzugang nutzen. Sollte ich die FB zum Modem degradieren und die Firebox das Verbinden übernehmen lassen, wo in der Firebox
gebe ich denn die Zugangsdaten ein?
Ich würde die Fritzbox gern als Router laufen lassen, da sie gute WLAN-Abdeckung macht, und wir das WLAN der FB als
Gastzugang nutzen. Sollte ich die FB zum Modem degradieren und die Firebox das Verbinden übernehmen lassen, wo in der Firebox
gebe ich denn die Zugangsdaten ein?
Um deine Frage zu beantworten:
Im Policy Manager unter "Network" dann "Configuration..."
Wenn du dort ein neues Interface konfigurierst kannst du zum Beispiel eine PPPoE Einwahl steuern.
Hatte ich schon in der Anleitung gesehen mittlerweile, aber Danke trotzdem. Nur leider kann ich es nicht testen. Zu Hause habe ich hier eine FritzBox 7390. Die wurde genial von AVM verbessert. Die Modem-Funktion wurde abgeschafft. Das verkaufen die echt als Verbesserung, wenn sie den Funktionsumfang einschränken. Der Workaround den AVM vorschlägt ist: Die FritzBox als Router betreiben. Kopf--->Tisch
Ich hoff jetzt mal, dass sich der Watchguard-Support nochmal meldet heute...
Vielen Dank erstmal
MLubrich
Ich hoff jetzt mal, dass sich der Watchguard-Support nochmal meldet heute...
Vielen Dank erstmal
MLubrich
Ja das denke ich mir auch oft bei sowas. Aber gut dann melde dich mal zurück woran es gelegen hat.
So der Support hat sich gerade in die Firewall geklinkt und das Problem im handumdrehen gelöst.
Wenn man einen Router vor der Firewall betreibt, dann muss man bei der VPN-SSL Konfiguration nicht die externe IP der Firebox angeben, sondern die feste IP, die man vom Provider bekommt, obwohl die Firebox dann rummeckert und warnt, dass man das falsch konfiguriert. Ich habe mich blöder Weise erst von der Warnung beeindrucken lassen und die IP so angegeben wie er vorschlägt, was aber nur funktioniert, wenn man keinen Router vor der Firewall hat. Im nachhinein total logisch und ich geh jetzt in die Ecke mich schämen.
Danke für Eure Zeit und Tipps
MLubrich
Wenn man einen Router vor der Firewall betreibt, dann muss man bei der VPN-SSL Konfiguration nicht die externe IP der Firebox angeben, sondern die feste IP, die man vom Provider bekommt, obwohl die Firebox dann rummeckert und warnt, dass man das falsch konfiguriert. Ich habe mich blöder Weise erst von der Warnung beeindrucken lassen und die IP so angegeben wie er vorschlägt, was aber nur funktioniert, wenn man keinen Router vor der Firewall hat. Im nachhinein total logisch und ich geh jetzt in die Ecke mich schämen.
Danke für Eure Zeit und Tipps
MLubrich
Ach Quark, manchmal sieht man vor lauter IP den Anschluss nicht mehr 
Hauptsache, es löwt ...
Hauptsache, es löwt ...
