galnar
Goto Top

Software über VPN zu starten macht Probleme

Hallo,
ich habe da mal eine Frage und hoffe darauf, dass irgendjemand mir einen Tipp geben kann wie ich mein momentanes Problem lösen kann. Es geht dabei um folgendes:

Ich möchte (muss) eine Software über eine VPN Verbindung zu laufen bekommen. Die Software ist lokal auf dem Rechner installiert. Lediglich wird beim Start der Software die Lizenz auf einem Lizenzserver bei uns im Haus abgefragt. Laut Hersteller der Software sollen der UDP Port 5093 offen sein und auf dem Client eine Umgebungsvariable mit der IP des Lizenzservers gesetzt werden. Das ist beides geschehen. Die Umgebungsvariable habe ich selber gesetzt und der Port ist auch geöffnet worden. Leider habe ich auf die Firewall keinen Zugriff, da diese von einem anderen Admin in den USA verwaltet wird. Daher kann ich das nicht wirklich überprüfen.

Der Lizenzserver hat 2 Netzwerkadapter verbaut und dementsprechend 2 IP Adressen. Beim Start der Software vor Ort gibt es gar keine Probleme. Wenn jedoch die Software über VPN gestartet werden soll, meldet diese meistens das der Lizenzserver nicht vorhanden oder offline sei. Auf Nachfrage beim Hersteller wurde mir nur mitgeteilt, dass ich besagten Port öffnen und die Variable vergeben soll (was schon längst geschehen war). Das kuriose ist aber, dass manchmal die Software gestartet werden kann (über VPN) ohne das an den Einstellungen etwas verändert wurde. Schließt man das Programm jetzt wieder und versucht es erneut dann kommt wieder die Meldung das der Lizenzserver nicht gefunden wurde. Irgendwann funktioniert es dann wieder einmalig. Die Tatsache das es meistens nicht funktioniert und dann hin und wieder doch, verwirrt mich dann schon etwas ;).

Also kurz gesagt der Admin für die Firewall sagt bei ihm sei alles korrekt, der Hersteller sagt mit ihren Hinweisen solltes es laufen und vor Ort finde auch keinen Fehler. Hat jemand eine Ahnung wo ich noch mit der Suche ansetzen kann?

Vielen Dank an alle.

Content-ID: 294219

Url: https://administrator.de/forum/software-ueber-vpn-zu-starten-macht-probleme-294219.html

Ausgedruckt am: 23.12.2024 um 13:12 Uhr

117643
117643 26.01.2016 um 09:08:41 Uhr
Goto Top
Zulange Paketlaufzeiten? Wir entwickeln Software und verbieten ausdrücklich die Nutzung via VPN, weil einfach zu viele Daten übertragen werden die viel zu lange brauchen.

Unseren Kunden empfehlen wir dann einen Terminalserver
aqui
aqui 26.01.2016 aktualisiert um 09:48:47 Uhr
Goto Top
Das ist natürlich sehr schwierig ein "Glaubensproblem" über ein Forum zu lösen, was dir vermutlich aber auch selber klar ist.
Einerseits beharrst du darauf das alles richtig ist, andererseits aber auch der FW Admin und wir hier sollen das nun verifizieren. Die Quadratur des Kreises...ist dir aber auch klar.
Gehe immer strategisch vor:
Was du machen kannst ist einen Wireshark Sniffer bei dir zu starten und zu checken op das UDP 5093 Paket auch wirklich rausgeht aus deinem Rechner mit der korrekten Absender IP und Ziel IP.
Ist das der Fall ist alles safe auf deiner Seite.
Wenn du kannst, dann fordere diesen Trace auch vom Lizenzserver an. Das verifiziert dann ganz sicher das das UDP Paket gesendet wird und auch ankommt am Ziel. Damit hört dann das Fingerpointing auf der beiden Parteien.
Sollte das so sein, das beidseitig das Paket ankommt, dann ist vermutlich die These vom Kollegen MichaelP08 oben die wahrscheinlichste.
Deine Clientsoftware hat einen Timeout Timer der getriggert wird wenn das UDP Paket losgeschickt wird.
Vermutlich ist die Wartezeit dieses Timeout Timers auf die Benutzung der SW im lokalen LAN optimiert, nicht aber über remote Verbindungen, sprich das Timeout Intervall ist viel zu kurz.
Die lange Laufzeit über die remote Strecke und die Verzögerung der En- und Decryption über das VPN, sowie die Gesamtlast auf dem VPN Tunnel bewirken vermutlich das der Timeout Timer zuschlägt.
Die Tatsache das du sagst "manchmal" klappt es, bestätigt diesen Verdacht nur. Denn dann ist vermutlich mal nichts los auf dem remoten VPN Zugang und wenig Traffic, die Laufzeit ist geringfügig kürzer und dann klappt es.
Fazit: Setze einfach den Timeout Timer höher und gut iss....
galnar
galnar 26.01.2016 um 10:17:43 Uhr
Goto Top
Vielen Dank an Euch beide.
Das mit dem Timeout klingt natürlich logisch, aber daran hatte ich gar nicht gedacht.
Natürlich verlange ich von keinem "Hellseherrische" Fähigkeiten. Mir ist schon klar das ich keine konkrete Lösung in diesem Fall erwarten kann und das war auch nicht meine Absicht. Vielmehr hatte ich gehofft neue Lösungsansätze zu bekommen, und eure beiden Posts erfüllen diese Hoffnung ziemlich gut ;).

Ich werde das jetzt alles mal in Ruhe durchgehen und versuchen der Sache auf den Grund zu gehen.
Also, vielen Dank schon mal für die Antworten. Sollte meine Problem gelöst sein, werde ich natürlich diesen Beitrag als gelöst markieren.
DerWoWusste
DerWoWusste 26.01.2016 um 13:03:37 Uhr
Goto Top
Hi.

Der erste Test ist, ob der UDP Port erreichbar ist. Dazu nimmt man portqry.exe/portqueryui.exe von Microsoft.
galnar
galnar 26.01.2016 um 15:48:08 Uhr
Goto Top
Habe mal mit Wireshark sowohl auf dem Server als auch auf dem Client auf den Port gelauscht. Aber bin ich jetzt schlauer?......gute Frage ;).
Wenn die Software mit dem Fehler den ich oben beschrieben habe abbricht, dann geht zwar von dem Client zu dem Server das UDP Paket raus, es kommt auf dem Server nichts an. Also soweit ok...konnte man mit rechnen.
Ab und zu gehen bei diesen Startversuchen auch Pakete raus die auf dem Server ankommen und auch beantwortet werden (Antworten kommen auf dem Client auch an). Allerdings startet die Software trotzdem nicht, als ob die Verbindung nicht stabil genug ist oder rasch wieder "blockiert" wird.

Wenn ich allerdings mit Port Query auf die IP des Servers und den Port abfrage, kommt die Anfrage jedesmal durch. Ebenso die Antwort vom Server zum Client.

Wie ich vorhin beschrieben habe, hat der Server 2 Netzwerkadapter und dementsprechend 2 IP Adressen. Wenn ich ein Port Query auf die erste IP mache ist alles gut. Mache ich das Gleiche auf die zweite IP bekomme ich folgende Meldung:

error:10040
A Winsock error has been encounterred

Da bin ich jetzt überfragt ob das Auswirkungen auf mein Problem hat oder nicht. Allerdings werden sämtliche UDP Anfragen von ebendieser zweiten IP beantwortet, wenn sie denn mal beantwortet werden.

Das Timeout Verhalten der Software kann man laut Hersteller aus Sicherheitsgründen nicht ändern, aber ich denke das würde eh keinen Unterschied machen, da die meiste Zeit sowieso die UDP Pakete nicht durchkommen ;)

Man kann gar nicht so Doof denken wie es manchmal kommt, ich werde heute Abend mal von zu Hause aus abwechselnd einen der beiden Netzwerkadapter abschalten und dann schauen ob das irgendwas ändert.
aqui
Lösung aqui 26.01.2016, aktualisiert am 27.01.2016 um 09:49:11 Uhr
Goto Top
Aber bin ich jetzt schlauer?......gute Frage
Das solltest du in jedem Falle !
Jedenfalls was die Frage anbetrifft das dein Traffic sein Ziel erreicht und nicht doch die FW dazwischenfunkt...
Wie ich vorhin beschrieben habe, hat der Server 2 Netzwerkadapter und dementsprechend 2 IP Adressen.
Das ist aber vollkommen egal. Relevant ist nur welcher Adapter die Anfrage bekommt und über welches Netzwerk er zu dir geroutet wird.
Jeder Adapter ist ja in einem separaten IP Netz.
Ein route print wenn es Winblows ist beantwortet dir diese Frage sofort !
Zusätzlich hast du aber scheinbar auch ein massives VPN Problem, denn wenn dort Paket gedroppt werden ist das ein sehr schlechtes Zeichen. Häufig passiert das durch Überlast oder einen MTU Mismatch.
UDP ist da natürlich dann tödlich, denn das hat keine Retransmission oder Sicherheitsmechanismen wie TCP.
Spricht dann wieder dafür das die Entwickler der SW nur einäugig lokale LAN User bedacht haben, nie aber an remote Benutzung face-sad
galnar
galnar 27.01.2016 um 09:50:38 Uhr
Goto Top
Super, danke das war es. Ohne diese Hilfestellungen wäre ich wohl erst viel später auf die Lösung gekommen.

Vielen lieben Dank an alle
aqui
aqui 27.01.2016 um 19:49:27 Uhr
Goto Top
Ooops...was war es denn nun ?? (Lösung ?) Oder haben wir jetzt irgendwas verpasst hier ?!