Synology Firewall blockiert Mailversand von OpenProject

[++++]

Hallo,

ich habe seit einiger Zeit OpenProject 10.3 in Docker auf meiner Diskstation laufen. Nach einem Update auf 10.3 konnte das System keine Mails mehr versenden.
Fehlermeldung getaddrinfo: Temporary failure in name resolution
Meine Firewall ist so eingestellt, dass sie nur den Zugriff von aussen auf den Containerport von OpenProject via https zulässt und per ReverseProxy an den internen Dockercontainer (http) weiterleitet.
Alle anderen Ports sind geblockt.

Wenn ich die interne Firewall doer die *blockiere alles-Regel* im DSM deaktiviere, funktioniert der Mailversand per SMTP (port 587) aus OpenProject heraus problemlos.
Ich nutze dazu einen deutschen Mailprovider.

Was ich bisher gestestet habe:

• SMTP Port 587 öffnen
• DNS Port 53 öffnen
• Port 443 öffnen
• Alle Ports von OpenProject öffnen

Ich weiss leider nicht mehr weiter und hoffe, eine Lösung zu finden. Es muss wohl ein oder mehrere Ports blockiert sein, die nicht in der Liste der Synology-Standardanwendungen aufgelistet sind.
Vielen Dank schon mal!

 

[blurrrr]

"Fehlermeldung getaddrinfo: Temporary failure in name resolution" sieht so aus, als könnte das System keine DNS-Auflösung durchführen (und somit den Mailserver ansprechen), dabei aber bitte die "Richtung" nicht vergessen: Das Quellsystem (vermutlich Dein Container) fragt nach "extern" einen DNS-Server auf Port 53 nach ausserhalb

 

[++++]

Hi blurrrr, danke für deine Antwort.

Ich werde daraus allerdings nicht so recht schlau. Port 53 nach aussen öffnen habe ich bereits versucht es brachte aber keine Besserung.

Was meinst du mit "Richtung"?
Sollte ich Port 53 mit ReverseProxy an den internen Port des Containers weiterleiten?

 

[blurrrr]

Nein, eben nicht, der Container muss in der Lage sein, seinen DNS-Server zu erreichen, damit der Name des Mailservers aufgelöst werden kann. Vermute ich jedenfalls...

"Fehlermeldung getaddrinfo: Temporary failure in name resolution"

-> getaddrinfo -> "The functions getaddrinfo() and getnameinfo() convert domain names, hostnames, and IP addresses between human-readable text representations and structured binary formats"

Es geht hier also um Namensauflösung und da Du keine Mails versenden kannst, verhärtet sich da eben der Verdacht, dass der externe Mailserver-FQDN eben nicht korrekt in eine IP aufgelöst werden kann.

Firewallregel-technisch sollte es irgendwas in Richtung "Container darf zum Router via Port 53/UDP" sein, oder ggf. "Container darf zum Google-DNS-Server (8.8,8,8) via Port53/UDP", je nachdem, welchen DNS-Server der Container halt nutzt. Kann auch sein, dass die Syno als DNS genutzt wird, bzw. bei der Syno eingetragene DNS-Server, k.a. ich bin da nicht so Container-firm, da ich sowas schlichtweg nicht nutze. Am einfachsten zum testen wäre wohl eine Regel á la: Container darf "überall" hin via Port 53/UDP. Wenn bei "darf alles" alles funktioniert, muss man nu eigentlich erstmal wieder alles verbieten und sich Schritt für Schritt voran tasten

 

[++++]

Ich habe das soweit verstanden, dass die Auflösung der SMTP-Serveradresse nicht funktioniert. War auch meine erste Vermutung nachdem ich die Fehlermeldung gelesen hatte.

Der bei Syno DSM eingetragene DNS server ist mein Router. Aber auch mit Google oder anderen DNS-Serveradressen hatte ich keinen Erfolg.

Dein Vorschlag, dass der Container über Port 53 überall hin darf ist für mich insofern auch logisch. Mir fehlt nur das Knowhow das über die GUI einzustellen oder müsste soetwas über iptables geregelt werden?

Vielleicht hilft das hier für eine Anleitung:
https://www.doktorerp.de/openproject-synology-nas/

Darüber habe ich OpenProject auf der Synology zum Laufen bekommen und ist bis auf einige Ports auch exakt so bei mir konfiguriert.

Wenn bei "darf alles" alles funktioniert, muss man nu eigentlich erstmal wieder alles verbieten und sich Schritt für Schritt voran tasten

Habe ich bereits mit allen vordefinierten Anwendungen in der Firewall ausprobiert. Da aber etwa 60.000 weitere Ports der Grund sein könnten, ist das ein sehr langwieriges Unterfangen.

Sorry, ich blick nicht mehr so ganz durch mit dem ganzen Firewallkram, ReverseProxy und Docker-Ports, die auf irgendwelche anderen Ports zeigen

 

[blurrrr]

Naja, es wird schon an Deiner einen Regel liegen (verbiete alles, was nicht explizit vorher erlaubt wurde), denn Du sagst ja selbst, dass es ohne diese dann auch funktioniert. Du musst - in der Theorie D) - also lediglich noch eine passende Regel zusammenbasteln. Ich weiss nicht, ob da irgendwas Docker-technisches vorgefertigt ist, aber ich "meine", dass es da ggf. auch ein eigenes Docker-Netz mit eigenen Adressen gibt, oder es geht alternativ direkt über die Syno. Wie dem auch sei, die richtige Regel macht's (denke ich). Versuch doch einfach mal ein "any -> 53/UDP -> any" (jegliche Quelle darf via DNS zu jeglichem Ziel) und aktiviere Deine "verbiete alles andere"-Regel wieder. Einfach mal schauen, ob das klappt, wenn ja, liegt es definitiv daran und man müsste primär nur erstmal die Quelle ausfindig machen (Container mit eigener IP, shared mit der Syno-IP, oder sonstwas). Halt einfach vorsichtig rantasten

EDIT: https://www.wdrmaus.de/filme/sachgeschichten/internet.php5 da wird es auch nochmal geklärt (vollumfänglich)

 

[++++]

Danke für deine Antwort.

Versuch doch einfach mal ein "any -> 53/UDP -> any"

Wie im Eingangspost erwähnt habe ich das schon versucht. und auch in so ziemlich allen anderen Varianten, die mir eingefallen sind.

Der Container läuft in einem eigenen Subnetz 172.17.0.0 /16
Gateway ist 172.17.0.1

Vielleicht ist das genau der Fehler. Die aufgelöste DNS-Anfrage kommt an die IP der Synology zurück, wird aber nicht in das Subnetz bzw. den Gateway des Containers weitergereicht. ?

 

[blurrrr]

Vielleicht, vielleicht auch nicht, das ist halt alles nicht so zielführend...

Vielleicht hilft Dir diese Übersicht ja weiter:

Anfrage - ausgehend:
Container (172.17.0.x/16) ---> Syno (172.17.0.1) ---> Router (LAN) ---> Internet ---> öffentlicher DNS-Server
(Port 53/UDP, 53/TCP)

Antwort - eingehend:
öffentlicher DNS-Server -> ---> Internet ---> Router (WAN!) ---> Syno (LAN!) --> Cotainer (172.17.0.x/16)
(Port grösser als 1024 TCP/UDP)

Hin- und Rückweg gesondert betrachten (vor allem bei den Interfaces der jeweiligen Stationen!). Die Pakete kommen irgendwo rein und gehen irgendwo raus. Ist wie bei DHL, wichtig ist halt nur, dass die Regel pro Interface auch stimmen und das man das ganze auch immer "pro Interface" betrachtet.

Wenn Du Deine any-any-deny-Regel ausschaltest und es funktioniert, weiss man ja schon, dass da eben etwas nicht stimmen kann. Grundsätzlich ist es aber auch so, dass die Firewall ("stateful") sich merkt was angefragt wurde und die Antworten auch entsprechend durchlässt (ausser natürlich sie werden nochmal explizit weggeschmissen(!)). In Deinem Fall - je nachdem, was dann als DNS-Sever zum Einsatz kommt, durchläuft die Anfrage mehrere Stationen, wobei sich jede Station auf dem Weg quasi merkt, dass Du diese Anfrage gestellt hast. Kommt die Antwort vom DNS-Server, wissen alle Stationen, dass Du darauf wartest - weil Du es eben "angfragt" hast - und werden das Paket zu Dir durch lassen.

Wenn man sich dann einfach mal o.g. Szenario anschaut, zusammen mit dem Fakt, dass alles funktioniert, wenn Du Deine any-any-deny-Regel rausnimmst, sieht es eben sehr schwer nach Firewall der Syno aus....

"Meine Firewall ist so eingestellt, dass sie nur den Zugriff von aussen auf den Containerport von OpenProject via https zulässt und per ReverseProxy an den internen Dockercontainer (http) weiterleitet.
Alle anderen Ports sind geblockt."

Das ist schön, denn so darf der Container mit dem Proxy reden und der Proxy mit der Aussenwelt, was aber wenn der Container nun mit der Aussenwelt sprechen will (DNS/Mailserver)? Zudem betrifft diese o.g. Regelung ja auch nur das LAN-Interface der Syno, nicht aber das interne Container-Interface der Syno, wo die DNS-Anfrage des Containers in erster Instanz ankommt. So gilt ja erstmal NUR: Was angefragt wurde, darf auch wieder raus. Wo ist die Regel die besagt: Der Container darf auch selbst raus (172.17.0.0/24 -> any (Dienst) -> any (Ziel))?

Container <-> Syno wird dann vermutlich auch noch ein NAT-Konstrukt sein? Oder ist es eine direkte Bridge ins LAN nur mit einem anderen IP-Netz? Ich kenn mich da nicht so aus mit dem was bei Docker so geht und was so typischerweise gemacht wird....

 

[++++]

Hallo blurrrr,

vielen herzlichen Dank für deine ausführliche Antwort. Der Emailversand funktioniert jetzt.

Es war nötig in der DSM Firewall eine neue Regel für das Containernetz (172.17.0.0) anzulegen
Port 53 und 587 für das gesamte 172.17.0.0- Subnetz (Maske 255.255.255.0) auf allen Protokollen (TCP, UDB und ICMP) freigeben, Regel speichern, fertig.

Nochmals vielen Dank für deine Geduld und Erläuterungen!

 

[blurrrr]

Freut mich zu hören, dass es funktioniert, wenn Du es noch "etwas" genauer haben willst:

53 / TCP+UDP
587 TCP
ICMP

Wünsche noch viel Spass damit