OPNsense Forum
International Forums => German - Deutsch => Topic started by: don on November 07, 2017, 06:48:03 pm
-
Wir haben unseren Router von Fritzbox auf OPNSense (mit pcengines) gewechselt.
Hinter dem Router läuft ein Mailserver mit Dovecot/Postfix, der über SASL Authentication unsere internen Mails an unseren Webserver versendet (der läuft mit EXIM4 in einem Datencenter). Mit Fritzbox hat das prima funktioniert. Mit OPNsense scheint das nicht mehr zu laufen (in der Standard-Grundkonfiguration).
Der Rest läuft alles wie gewohnt (IP-Phone, LAN->WAN).
Fehlermeldung auf unserem Mailserver lautet: (host mail.xy.com[Public IP vom WAN] said: 421 mail.xy.com SMTP incoming data timeout - closing connection. (in reply to end of DATA command))
Woran liegt das? Müssen Ports won WAN->LAN offen sein? Welche und Wozu?
Danke für Eure Hilfe!
Don
-
Entweder der Status in der Firewall läuft ab oder du hast ein NAT-Problem.
Von außen muss eigentlich nur Port 25 (SMTP) offen sein, um Mails zu empfangen (es sei denn du arbeitest auch mit anderen Protokollen (zum Beispiel DIME).
-
Herzlichen Dank für die schnelle Rückmeldung.
Nun für mich ist OPNsense völlig neu. Daher werde ich ein paar "dumme" Fragen stellen.
Wir versenden nur Mails. Empfangen tun wir via fetchmail (wir holen die mails von einem Pop-Server ab). Das funktioniert auch prima. Daher muss der Port 25 wohl nicht geöffnet sein?
Was bedeutet ein NAT-Problem: OPNSense ist frisch aufgesetzt und in der Standardkonfiguration belassen. Wo könnte hier das Problem liegen?
Wo stellt man den Status in der Firewall ein? Ich denke, dass ein Connection-Timeout besteht und der Port vom senden schneller geschlossen wird, so dass der Server, wenn er zurückmeldet, bereits keine Verbindung mehr hat.
-
Hast du suricata im IPS Modus laufen?
-
Schließe mich NilsS an. Wenn IPS aktiv sein sollte - welche Rulesets wurden aktiviert? Vielleicht siehst Du Einträge, wenn Du in der Intrusion Detection unter Alerts nach der IP Adresse deines Servers im Datacenter suchst.
Gruß,
Fabio
-
> Wo stellt man den Status in der Firewall ein? Ich denke, dass ein Connection-Timeout besteht und der Port vom senden schneller geschlossen wird, so dass der Server, wenn er zurückmeldet, bereits keine Verbindung mehr hat.
Das halte ich ganz frech gesagt für ausgeschlossen. Die State Timeouts sind normalerweise wesentlich größer als jeder SMTP Timeout den du erreichen könntest. Das hört sich für mich ebenfalls eher danach an, als hättest du zusätzlich noch andere Pakete wie IPS oder dergleichen am Start. Bei einem reinen Filtering Setup nur mit Firewall Regeln sollte das Verhalten nicht auftreten. Ansonsten könntest du das State Handling in den Advanced Settings der Firewall auch testweise auf "konservativ" oder "high-latency" stellen, allerdings ist das wie gesagt nicht normal. Wir betreiben selbst multiple Mailserver vor und hinter *sensen und hatten da noch nie Probleme mit :)
Gruß
-
Danke für die Tipps,
Konnte letzten Freitag zusammen mit einem Netzwerkspezialisten zusammenarbeiten. Aber er hat es auch nicht hingekriegt :-(
Folgendes konnte abgeklärt werden:
1. IPS ist nicht aktiviert.
2. Die notwendigen Ports für Mailsversand sind alle offen.
3. Mails ab Konsole können versandt werden.
4. Unverschlüsselte Mails funktionieren zum Teil auch.
5. Verschlüsselte Mails hingegen nicht.
6. Der lokale Mailserver (Postfix) kann mit SASL auf Exim4 auch nicht versenden. Queue bleibt hängen.
Bin froh um weitere Tipps, weil wir sind ziemlich ratlos...
-
5: könnte daran liegen, dass der server ohne TLS Unterstützung kompilliert wurde.
-
Welchen Server meinst du nun? Bei der OPNSense habe ich ein Prebuild genommen, welches für die APU2 gemacht wurde.
-
Mails werden üblichwerweise über TCP/25 übertragen. Clients verwenden normalerweise was anderes (Submission). TLS wird über das Kommando STARTTLS aufgebaut (keine verschlüsselte Verbindung von Anfang an). Dies schließt einen Firewallfehler aus, weil es der selbe Port für verschlüsselte und unverschlüsselte Verbindungen ist.
-
Nicht bei dedizierten SSL Verbindungen, die laufen über SMTPS tcp/465 ab :)
-
Es ist unglaublich aber wahr. Der Wechsel zu einem anderen Anbieter hat das Problem gelöst. Unser externer Netzwerktechniker, hat diese Vermutung eines transparent Mailproxy ins Feld geführt, der wohl beim bisherigen Provider in Betrieb ist.
Wie es scheint, war hier tatsächlich das Problem. Weil nun sind die Probleme weg. Die Mails gehen raus.
Danke für alle Hilfe!
Gruss Don
-
...jetzt wüsste ich aber gerne, bei welchem eMailprovider sowas passiert :-)
STARTTLS ist besser als port 25, aber auch nicht wesentlich, oder? Eigentlich nur noch SMTPs...
-
Dann wurde geblockt weil der transparente Proxy pf nicht austricksen konnte. Hätte man mit anderem State Tracking Mode bestimmt beheben können, aber so herum ergibt es vielleicht langfristig mehr Sinn. ;)
Grüsse
Franco
-
> STARTTLS ist besser als port 25, aber auch nicht wesentlich, oder? Eigentlich nur noch SMTPs...
Ich verstehe die Frage nicht ganz :) STARTTLS via 25 (oder 587 Submission bei Maileinlieferung, was meist sinnvoller ist) sowie 465 für SMTPS geben sich eigentlich nicht viel. Der einzige Unterschied ist, dass STARTTLS zu Beginn die ersten zwei drei Infos zum Server unverschlüsselt austauscht. Also quasi der Vorgang mit EHLO/HELO (Vorstellen) und Abfragen, was der andere so kann. Sobald da STARTTLS zurückgegeben wird wechseln beide in den verschlüsselten Modus.
Viele Provider nutzen dafür aber eben explizit nicht 25 und erlauben da STARTTLS sondern Submission via 587 weil sie das dann für die Maileinlieferung anders behandeln können. Oftmals wird dann bei authentifizierter Verbindung (man loggt sich ja mit Credentials ein) dann bspw. kein Virenscan oder diverse Checks durchgeführt um Ressourcen zu sparen und die Mailannahme zu beschleunigen - sollte bspw. Spam gesendet werden, kann man dies durch andere Erkennung im Log feststellen UND hat bei der Einlieferung ja die direkte Kundenzuteilung via Username, somit eindeutig zu identifizieren wer da Mist baut :)
Bei normaler Mailannahme von Servern die bspw. kein TLS nutzen, wird dann auf Port 25 das volle Programm inkl. diverser Mechanismen wie Greylisting o.ä. abgefackelt. Das will man aber im Normalfall Kunden, die einfach nur senden wollen, ersparen :)
Gruß
-
...jetzt wüsste ich aber gerne, bei welchem eMailprovider sowas passiert :-)
Da muss ich vorsichtig sein, weil es nur eie Vermutung ist. Aber wir können es uns nicht anders erklären. Nur soviel: Es war ein kleiner Schweizer Provider aus Solothurn und wird daher wohl niemanden mehr betreffen.