OPNsense Forum
International Forums => German - Deutsch => Topic started by: Mats62 on June 08, 2021, 04:01:28 pm
-
Hallo zusammen
Ich habe letzte Woche eine Fortigate durch OPNsense (v21.4.1) ersetzt. Eigentlich keine grosse Sache mit LAN und WAN Anschluss, that's it. Hat auch soweit funktioniert, bis der Kunde eine einem selbst programmierten VB-Programm die aktuellen Webshop-Daten per ftp auf den Server laden wollte: Keine Verbindung. Leider kann das Tool aktuell nicht so einfach ersetzt werden und mit Fortigate hat beides funktioniert.
Alle anderen ftp Clientverbindungen haben problemlos funktioniert.
Nach einigem Analyse-Aufwand war klar, das Programm macht eine ACTIVE Verbindung, alle anderen Tools eine passiv: ftp-proxy ist die Lösung (https://forum.opnsense.org/index.php?PHPSESSID=uqvvs0qebb6fgsfjtjofnvd6ps&topic=3868.0).
Installation und Konfiguration absolut kein Problem, hat auch wunderbar funktioniert, dafür funktionieren alle anderen ftp Verbindungen nicht mehr. Durch aktivieren/deaktivieren der NAT Regel, die Port 21 auf den ftp-proxy umleitet kann ich wählen, was funktioniert ACTIVE oder PASSIV.
Sowohl FileZilla als auch Debian wget kommen zur gleichen Fehlermeldung:
AUTH TLS ... GnuTLS: The TLS connection was non-properly terminated.
Gefühlt habe ich schon das ganze Internet abgesucht und nichts gefunden. Ich bin nicht ganz sicher, aber ich glaube bei hat es mit OPNsense 20.7 und ftp-proxy noch funktioniert, mit 21.4.1 nun definitiv nicht mehr.
Hat jemand einen Tipp.
Im voraus besten Dank.
-
Eine direkte Lösung habe ich nicht aber eine Idee für einen "schnellen Bypass":
Wenn es ein selbsterstelltes Programm ist besteht evlt. die Möglichkeit den FTP Port zu ändern. Damit kannst Du Deine NAT Regel in zwei auspalten - aktive und passiv. Eine andere Idee wäre, das Programm auf einem anderen Rechner auszulagern - damit könntest Du über die IP die NAT Regel steuern.
-
Das Problem mit FTP ist, dass der 2. Kanal (Data Connection) im 1. Kanal (Control Connection) ausgemacht wird.
Wenn du den Control Channel verschlüsselst, sieht der FTP-Proxy nicht, ob du aktiv oder passiv und über welche Ports du reden willst.
-
Eine direkte Lösung habe ich nicht aber eine Idee für einen "schnellen Bypass":
Wenn es ein selbsterstelltes Programm ist besteht evlt. die Möglichkeit den FTP Port zu ändern. Damit kannst Du Deine NAT Regel in zwei auspalten - aktive und passiv. Eine andere Idee wäre, das Programm auf einem anderen Rechner auszulagern - damit könntest Du über die IP die NAT Regel steuern.
Danke, aber diese Idee hatte ich auch schon. Das Problem ist, dass sowohl das Spezial-Tool (Upload Artikeldaten und einarbeiten der Artikeldaten im Shop) als auch FileZilla (Upload von Bildern etc.) auf den gleichen PCs genutzt werden.
-
Bei FZ kannst du aber aktiv/passiv einstellen.
-
Hallo zusammen
Besten Dank für die Ideen und Hinweise. Hier noch eine kurze Replik:
- FZ ist nicht das Problem, das kann alle Varianten. Aber wir haben leider keinen Einfluss auf die Server beim Provider.
- Das mit dem anderen Zielport und diesen dann im ftp Proxy wieder umbigen hätte evtl. eine Lösung sein können.
- @fabian: Meine Erwartung an den ftp-proxy wäre gewesen, dass dieser, genau wie der Web Proxy, für den Client Server spielt, und gegenüber dem Server den Client spielt. Damit wäre für den ftp-proxy alles unverschlüsselt.
Effektive Lösung: Umbau des VB-Programms auf eine andere Library (nicht mehr winet, sondern PyroBatch ftp). PyroryBatch ftp ein ein sehr starkes Tool um in Windows ftp-Jobs zu automatisieren (Aufgabenplanung) und hat auch eine vb Schnittstelle.
Irritierend ist und leibt die Tatsache, dass es mit der Fortigate funktioniert hat, und das ohne grosses gefummel.
Nochmals Danke für die Ideen
-
- @fabian: Meine Erwartung an den ftp-proxy wäre gewesen, dass dieser, genau wie der Web Proxy, für den Client Server spielt, und gegenüber dem Server den Client spielt. Damit wäre für den ftp-proxy alles unverschlüsselt.
Tut er auch aber er versteht kein TLS. Das bedeutet, dass ab starttls alles durchgeleitet wird. Ansonsten würdest du ein CA-Zertifikat brauchen. Die Fortigate kann das vermutlich (TLS inspection in FTP).
Effektive Lösung: Umbau des VB-Programms auf eine andere Library (nicht mehr winet, sondern PyroBatch ftp). PyroryBatch ftp ein ein sehr starkes Tool um in Windows ftp-Jobs zu automatisieren (Aufgabenplanung) und hat auch eine vb Schnittstelle.
Generell sollte weg von VB auch eine Option sein. Ich kenne das Tool jetzt nicht aber in der .NET Welt hat sich C# durchgesetzt und VB wird meines Wissens nach eigentlich nicht mehr weiterentwickelt (wird noch unterstützt im Sinne von Sicherheitsupdates, ist aber Feature frozen). Außerdem gibt es noch ne Menge an anderen Sprachen, die genutzt werden können.