Timout trotz korrekt definierter Policy? Ist das ein Layer 8 Problem?

    Hallo, ich habe bisher nur eine Policy hinzugefügt, alles andere ist default. Der Port ist jedoch aktuell nicht 22 sondern das ist jetzt nur zu aufnahmezwecken auf 22 gelegt. Meine Erwartung wäre dass ich mich jetzt immer noch über SSH anmelden könnte. Versuche ich das erhalte ich jedoch einen Timeout. Nachdem Anwenden der Policy habe ich natürlich den Server neu gestartet. Entferne ich die Policy geht der SSH Login wieder normal. Ich habe es so umgesetzt wie es in der Dokumentation erkärt wurde aber es ist möglich das ich etwas missversatnden habe. Vom Support kommt im Grunde ein "It's a you problem", daher dachte ich vielleicht gibt es hier ein paar erfahrene Admins die mir helfen können:

    Fehlermeldung: ssh: connect to host 152.53.134.153 port 22: Connection timed out

    image.png

    Mein Ziel mit dieser Policy wäre es alles zu schließen außer 22, 80, 443.

    Wende ich sie an ändern sich die Impliziten Regeln auf folgendes:

    image.png

    Die Default Regeln sehen wie folgt aus:

    image.png

    Zitat von netcupuser1234

    Nachdem Anwenden der Policy habe ich natürlich den Server neu gestartet.

    Ist eigentlich nicht nötig.

    Zitat von netcupuser1234

    Wende ich sie an ändern sich die Impliziten Regeln auf folgendes:

    Das ist so ausdrücklich in der Dokumentation zur Firewall beschrieben, also richtig.

    Eventuell bezieht dein Server seine IP-Adresse per DHCP und ist deswegen gar nicht mehr erreichbar. Außerdem könnte die DNS-Auflösung nicht mehr funktionieren, sobald Du die Firewall aktivierst und auch NTP dürfte ein Thema sein.

    Lies Dir mal diesen Beitrag zum Thema UDP stateless, insbesondere den letzten Absatz durch: RE: Ab sofort: Firewall für netcup vServer verfügbar

    Um Layer 8 auszuschließen: Hast Du evtl. einen Zahlendreher in der IP-Adresse oder Portnummer?

    Den Server musst Du übrigens nicht neustarten, wenn Du an der netcup-Firewall schraubst.

    P. S.: Es gibt ein Subforum für die Firewall, wo der Beitrag besser aufgehoben wäre.

    Du kannst über die Webconsole auf den Server zugreifen. Mit tcpdump kannst du sehen, ob Pakete an deinem Server ankommen, also beispielsweise sollte tcpdump -n -i eth0 port 22 ankommende Verbindungsversuche zeigen. Das funktioniert auch, wenn auf dem Server irgendwas schiefläuft, z.B. der SSH-Server die Verbindung nicht annimmt, gar nicht läuft, keine IP-Adresse zugewiesen ist (dann allerdings nicht für Port 22, sondern eher für DHCP und Broadcasts), eine Firewall auf dem Server die Pakete verwirft oder ähnliches. Mit ip address siehst du, ob das Interface eine Adresse hat.

    Wahrscheinlich funktioniert irgendetwas auf deinem Server nicht, weil du nicht genug freigegeben hast, dass die Default-Policy auf DROP wechseln kann. Du musst dich dann auch um DNS und ggf. DHCP kümmern. Für UDP ist die Firewall nicht stateful. Es reicht also nicht, dass die Anfragen von deinem Server rausgehen. Die Antworten müssen auch explizit durch die Firewall gelassen werden.

    Wenn du es per trial-and-error angehen möchtest, leg eine Policy an, die UDP ohne Einschränkungen reinlässt. Wenn es dann funktioniert, weißt du, dass es an einem geblockten UDP-Protokoll liegt. Dann kannst du das weiter eingrenzen und diese Policy wieder rausnehmen.

    3 Mal editiert, zuletzt von NaN (21. August 2026 um 08:47)

    Zitat von terence

    Um Layer 8 auszuschließen: Hast Du evtl. einen Zahlendreher in der IP-Adresse oder Portnummer?

    Den Server musst Du übrigens nicht neustarten, wenn Du an der netcup-Firewall schraubst.

    P. S.: Es gibt ein Subforum für die Firewall, wo der Beitrag besser aufgehoben wäre.

    Hi danke für den Tipp. Das war das erste was ich geprüft habe. Nein die Portnummer ist korrekt. Genau genommen läuft das bei mir so ab:

    Ich aktiviere Policy teste ssh login -> Timeout. Deaktiviere Policy -> Teste ohne Policy geht. Gleiche Portnummer alles identisch. Gerade nochmal sicherheitshalber geprüft, Portnummer ist korrekt.

    Zitat von NaN

    Du kannst über die Webconsole auf den Server zugreifen. Mit tcpdump kannst du sehen, ob Pakete an deinem Server ankommen, also beispielsweise sollte tcpdump -n -i eth0 port 22 ankommende Verbindungsversuche zeigen. Das funktioniert auch, wenn auf dem Server irgendwas schiefläuft, z.B. der SSH-Server die Verbindung nicht annimmt, gar nicht läuft, keine IP-Adresse zugewiesen ist (dann allerdings nicht für Port 22, sondern eher für DHCP und Broadcasts), eine Firewall auf dem Server die Pakete verwirft oder ähnliches. Mit ip address siehst du, ob das Interface eine Adresse hat.

    Wahrscheinlich funktioniert irgendetwas auf deinem Server nicht, weil du nicht genug freigegeben hast, dass die Default-Policy auf DROP wechseln kann. Du musst dich dann auch um DNS und ggf. DHCP kümmern. Für UDP ist die Firewall nicht stateful. Es reicht also nicht, dass die Anfragen von deinem Server rausgehen. Die Antworten müssen auch explizit durch die Firewall gelassen werden.

    Wenn du es per trial-and-error angehen möchtest, leg eine Policy an, die UDP ohne Einschränkungen reinlässt. Wenn es dann funktioniert, weißt du, dass es an einem geblockten UDP-Protokoll liegt. Dann kannst du das weiter eingrenzen und diese Policy wieder rausnehmen.

    du bist tatsächlich ein Profi. Danke.

    Diese Regel hinzuzufügen hat einfach das Problem gelöst:

    Beschreibung: DHCP
    Richtung: EINGEHEND
    Protokoll: UDP
    Aktion: ACCEPT
    Quellen: leer
    Src Ports: 67
    Ziele: leer
    Dst Ports: 68

    Wenn das alles ist, was du hinzugefügt hast, dann solltest du noch eine Regel für NTP hinterherschieben, denn sonst weicht irgendwann die Uhr deines Servers zu sehr ab. Da du die Adresse per DHCP beziehst, tust du das wahrscheinlich auch mit den Nameservern. Andere als die Netcup-Nameserver kannst du jetzt aber nur per TCP erreichen. Wenn du andere verwendest, funktioniert es jetzt vielleicht, aber besser wäre, du lässt auch DNS über UDP zu. Oben wurde schon der Spickzettel zur Netcup-Firewall verlinkt. Wirf mal einen Blick drauf.