Sophos SG115 / UTM 9 / NAT - FTP nicht erreichbar extern

[PEASANT KING]

Moin moin,

ich mal wieder, ich weiß nicht ob ich einfach nur doof bin, allerdings würde ich gerne einen FTP Server nach außen hin verfügbar machen. Also was habe ich getan, FTP Server aufgesetzt, in der Sophos UTM 9 eine NAT Regel aufgestellt:
"Any IPv4 -> FTP -> External Interface, Zielpübersetzung -> Interner FTP Server"

Dann habe ich noch eine Firewall Regel erstellt:
"Any -> FTP -> Interner FTP Server"

Was habe ich übersehen, das es nicht funktioniert? Intern ist der FTP zuerreichen, von außen komme ich nicht drauf.
Ich muss doch eine Kleinigkeit übersehen haben. FTP Server ist FileZilla Server, Verbindung über Explizit over TLS, passiv Modus.

Die Software Firewall von ESET Entpoint Security ist es nicht auf dem Server, die habe ich schon getestet

 

[^R4iD]

maybe DNAT?

 

[PEASANT KING]

Sorry das ich es nicht erwähnt habe, aber die NAT Rule ist ne DNAT Rule.

 

[cloudman]

FTP wirklich - das ist ein Mist Protokoll aus der Steinzeit.

Das Problem ist passive FTP auf der Serverseite weil der Server für die Datenverbindung einen dynamischen Port öffnet was deiner FW natürlich nicht gefällt

Ich hab kein Sophos aber es gibt da wohl einen connection tracker um damit umzugehen.

https://community.sophos.com/utm-fi...orking-in-my-network-with-sophos-utm-9/342153

(Such mal FTP passive Firewall)

 

[PEASANT KING]

Der Connection Tracker ist vor dem Aufsetzen des FTP Servers aktiviert gewesen und ist es noch.
Kann ja dann nur an den passiven Ports liegen, aber dafür habe ich ja eine Firewall Regel, die diese Ports frei gibt.

Ich komme halt mit dem FileZilla Client nicht weiter als:

Heißt für mich, das hier einfach schon an der Firewall die Verbindung verworfen wird.

 

[Raijin]

Gegebenfalls ist auch die Firewall des Servers oder gar der FTP Dienst selbst so eingestellt, dass Verbindungen von außerhalb des lokalen Subnetzes abgelehnt werden. Also in den Einstellungen mal nach Optionen zur Source IP suchen.

 

[cloudman]

Solltest du das nicht in den Firewall logs sehen ?
Wenn die Verbindung zu port 21 schon nicht funktioniert sind es nicht die dataport.
Eigentlich sollte filezilla auch etwas mehr zeigen.
Es wird es eine Verbindung zu port 21 ausgebaut und dann schickt der client PASV bzw. PORT
Im Zweifel mit Wireshark tracen ist eh alles im Klartext (incl. Passwort )

 

[Raijin]

Heißt für mich, das hier einfach schon an der Firewall die Verbindung verworfen wird.

Nein, das heißt, dass der Server nicht antwortet, das ist alles. Ob die Verbindung an der Firewall des Routers, an der Firewall des Servers, am Dienst selbst oder aber auf dem Rückweg blockiert wird, steht in den Sternen.

An dieser Stelle würde man beispielsweise im Router und/oder am Server mit tcpdump, WireShark oder vergleichbaren Tools (ggfs auch ein Webfrontend in der GUi, das im Hintergrund tcpdump nutzt) prüfen welche Datenpakete reinkommen und rausgehen. Tut man das am Server, würde man also prüfen können ob die Portweiterleitung im Router weiterleitet oder nicht.
Auch könnte man sehen ob der Server eine Antwort rausschickt und am
Router könnten man sehen ob diese Antwort auch tatsächlich ankommt, etc.

Mit diesen Informationen kann man anschließend eingrenzen an welcher Stelle der Verbindungsaufbau konkret fehlschlägt, beispielsweise weil im Router die ausgehenden Verbindungen auf surfen und email only eingestellt sind.

 

[PEASANT KING]

Ich habe das Problem gefunden, von zu Hause aus ist der FTP erreichbar... Allerdings wenn ich von intern aus dem Netzwerk auf den FTP zugreifen will über die externe IP dann nicht, also muss ich wohl wieder in den DNS Einstellungen hier intern rum fummeln... Ich glaube es nennt sich Split Brain DNS.

 

[Raijin]

Ne, mit DNS hat das nichts zu tun. DNS macht aus "computerbase.de" die dazugehörige IP, das ist alles. Die tatsächliche Verbindung erfolgt immer und ausschließlich über diese IP. Wenn du also direkt eine IP eingibst, erfolgt auch keinerlei DNS-Auflösung, weil die IP ja bereits bekannt ist.

Das Problem liegt an anderer Stelle. Wenn man von innerhalb des Netzwerks auf die WAN-IP des Routers zugreift, muss der Router NAT-Loopback unterstützen. Dabei dreht der Router im allerletzten Moment, kurz vorm abschicken der Verbindung an den Provider, die Verbindung innerhalb des WAN-Ports um und leitet sie in seine eigene NAT-Pipeline. Entweder der Router kann das - man muss das ggfs einschalten - oder nicht.

DNS kommt dann ins Spiel, wenn man auf den eigenen Server nicht per IP, sondern per Domain zugreift. peasant.king.ddns würde auf die WAN-IP des Routers zeigen und dann erfolgt der Verbindungsaufbau inkl. NAT-Loopback wie beschrieben. Kann der Router aber kein NAT-Loopback, muss man im lokalen DNS einen manuellen Eintrag hinzufügen, der peasant.king.ddns eben nicht mit der WAN-IP des Routers auflöst, sondern mit der lokalen IP des Servers. Die Verbindung geht dann direkt vom PC zum Server, ganz ohne Router (abgesehen von der DNS-Auflösung).

 

[PEASANT KING]

Danke für die ausführliche Erklärung. So meinte ich es auch, allerdings ist das doch ein Split Brain DNS oder nicht, da wenn ich intern im Netz bin der interne DNS Server die Adresse übersetzt mit der internen IP des Servers anstatt die WAN IP zu nutzen und zu scheitern.

Ich glaube das Problem würde nicht bestehen, wenn ich ein Full NAT in der Sophos anlegen würde ohne am DNS Server zu fummeln.

 

[Raijin]

Wie gesagt, das sind zwei Paar Schuhe. Du sprachst explizit davon, auf die von zu Hause auf die "externe IP" zuzugreifen. Das hat nix mit DNS zu tun. Aber ich denke mal, dass das nur eine ungenaue Formulierung war

Ich glaube das Problem würde nicht bestehen, wenn ich ein Full NAT in der Sophos anlegen würde ohne am DNS Server zu fummeln

Jein. Ich kenne mich mit Sophos nicht aus, aber grundsätzlich ist der Weg über die WAN-IP zu vermeiden. Dadurch entsteht ein Umweg im Netzwerk, weil jedes einzelne Paket vom lokalen Client zum lokalen Server durch die NAT-Pipeline des Routers geht - ebenso wie die Antworten des Servers zum Client. Darüber hinaus taucht der vermeintlich lokale Client beim Server auch unter der WAN-IP auf, weil die Verbindung bei NAT-Loopback wie eine externe Verbindung gehandhabt wird, inkl. NAT der Source-IP. Deswegen geht eben auch die Antwort durch den Router, weil der Server ja seinerseits an die WAN-IP antwortet und das ganze Prozedere von vorne anfängt.

Nicht nur, dass man am Server dann Schwierigkeiten bekommt, lokale Verbindungen von externen Verbindungen zu unterscheiden, man kann auch Probleme mit der Performance bekommen. Einerseits ganz banal dadurch, dass die Verbindung im worst case einmal quer durchs Haus und wieder zurück läuft, obwohl Server und Client an ein- und demselben Switch hängen, andererseits weil der Router dann eben auch mit 1 Gbit/s NAT und Firewall stemmen können muss. Je nach WAN-LAN-Performance des Routers kann das also dazu führen, dass zB nur noch 700 Mbit/s möglich sind, weil dem Router da die Puste ausgeht. Das sollte man also zumindest einmal testen.

Ergänzung (8. März 2021)

Nachtrag:

Das Problem mit dem NAT der Source-IP bei NAT-Loopback kann sich zum Beispiel darin äußern, dass man am Server vielleicht auch rein lokale Dienste nutzen möchte, für die es gar keine Portweiterleitung im Router gibt, geben soll oder geben darf. Bei einem manuellen DNS-Eintrag kann man beispielsweise gefahrlos auch SMB über die Domain nutzen und dies im Server auch nur für das lokale Netzwerk erlauben. Würde man über eine Domain samt WAN-IP gehen, müsste man passend dazu eine SMB-Portweiterleitung anlegen, was eher keine gute Idee ist. SMB kann man mit allem möglichen ersetzen, beispielsweise mit einem Drucker-Server oder dergleichen. Eben Dienste, die rein lokal und explizit nicht öffentlich sein sollen. Ansonsten müsste man in der Firewal dafür sorgen, dass etwaige Portweiterleitungen ausschließlich von der eigenen WAN-IP getriggert werden, weil sonst SMB, Drucker und Co offen im Internet hängen.