[SOLVED] Probleme mit Relay-Port hinter Loadbalancer

[TobiTobs]

Hi zusammen,

kurz zum Setup: 2 PMGs im Cluster hinter einem Loadbalancer (Round Robin).
Für eingehende Mails auf Port 25 habe ich in der main.cf

postscreen_upstream_proxy_protocol = haproxy

gesetzt.

Wenn jetzt über den Loadbalancer auf Port 26 (Relaying) Mails eingehen von meinen Mailservern, wird dort die Loadbalancer IP angezeigt. Wie bekomme ich hier die eigentliche IP der Gegenseite rein?

Hintergrund: wenn ich aktuell Relaying über die Konstellation versuche bekomme ich den folgenden SSL-Fehler

Aug 05 12:14:24 mx01 postfix/smtpd[2283290]: connect from mx.example.com [167.235.XXX.XXX]
Aug 05 12:14:24 mx01 postfix/smtpd[2283290]: improper command pipelining after EHLO from mx.example.com [167.235.XXX.XXX]: HELO mail01.example.com \r\n
Aug 05 12:14:24 mx01 postfix/smtpd[2283290]: SSL_accept error from mx.example.com [167.235.XXX.XXX]: -1
Aug 05 12:14:24 mx01 postfix/smtpd[2283290]: warning: TLS library problem: error:1408F10B:SSL routines:ssl3_get_record:wrong version number:../ssl/record/ssl3_record.c:331:
Aug 05 12:14:24 mx01 postfix/smtpd[2283290]: lost connection after STARTTLS from mx.example.com [167.235.XXX.XXX]
Aug 05 12:14:24 mx01 postfix/smtpd[2283290]: disconnect from mx.example.com [167.235.XXX.XXX] helo=1 ehlo=1 starttls=0/1 unknown=0/1 commands=2/4

Vielen Dank im Voraus und viele Grüße
Tobi

 

[Stoiko Ivanov]

kurz zum Setup: 2 PMGs im Cluster hinter einem Loadbalancer (Round Robin).

Prinzipiell funktioniert load-balancing bei SMTP recht gut auch ohne weiteren Loadbalancer (DNS-round-robin) - der ja auch redundant ausgeführt werden müsste... - vielleicht würde das die Sache leichter machen ...

Wenn jetzt über den Loadbalancer auf Port 26 (Relaying) Mails eingehen von meinen Mailservern, wird dort die Loadbalancer IP angezeigt. Wie bekomme ich hier die eigentliche IP der Gegenseite rein?

Wo wird die loadbalancer-ip angezeigt? (PMG log, haproxy,....)?

Hintergrund: wenn ich aktuell Relaying über die Konstellation versuche bekomme ich den folgenden SSL-Fehler

von welchem system stammen die gepasteten logs? (PMG?)

Die Fehlermeldung sieht auf den ersten Blick nach einem Konfigurationsproblem mit TLS aus (wahrscheinlich auf Sender-Seite - aber mit den Infos alleine lässt sich das schwer sagen)

Ich hoffe das hilft!

 

[TobiTobs]

Prinzipiell funktioniert load-balancing bei SMTP recht gut auch ohne weiteren Loadbalancer (DNS-round-robin) - der ja auch redundant ausgeführt werden müsste... - vielleicht würde das die Sache leichter machen ...

Was wäre denn die Empfehlung, ein MX-Record mit mehreren IPs? Bin als MSP unterwegs und bei Wartungen etc bei jedem Kunden die MX-Einträge anzupassen wäre nicht so optimal. Funktioniert das trotzdem gut mit mehreren A-/AAAA-Records anstelle von 2 10er Prio MX-Einträgen?

Wo wird die loadbalancer-ip angezeigt? (PMG log, haproxy,....)?

Im PMG Log

von welchem system stammen die gepasteten logs? (PMG?)

Logs sind vom PMG, richtig.

Die Fehlermeldung sieht auf den ersten Blick nach einem Konfigurationsproblem mit TLS aus (wahrscheinlich auf Sender-Seite - aber mit den Infos alleine lässt sich das schwer sagen)

Wenn ich als Relay direkt einen PMG-Host eintrage gibt es kein Problem. Kann das ein Problem mit der TLS-Aushandlung sein wegen der falschen IP?

Danke und viele Grüße
Tobi

 

[Stoiko Ivanov]

Funktioniert das trotzdem gut mit mehreren A-/AAAA-Records anstelle von 2 10er Prio MX-Einträgen?

Ja prinzipiell durchaus - siehe https://www.proxmox.com/en/proxmox-mail-gateway/features#nav-mod-scrollspy433-data4
und damit bleibt auch alles soweit bei euch - einfach bei IP-wechsel die A records zum MX record anpassen.

habe mich bisher nicht mit haproxy als postfix frontend beschäftigt (da DNS round-robin bisher immer ausgereicht hat) - deswegen ist folgendes nur theoretisch und nicht explizit getestet:
* postscreen wird bei PMG nur auf dem inbound port (25) verwendet - und nicht auf dem internen/outbound port (26) - sprich wahrscheinlich reicht:

postscreen_upstream_proxy_protocol = haproxy

nicht aus - sondern es muss zusätzlich beim internen smtpd (in der master.cf.in) noch 'smtpd_upstream_proxy_protocol ' gesetzt werden:
https://www.postfix.org/postconf.5.html#smtpd_upstream_proxy_protocol

Wenn ich als Relay direkt einen PMG-Host eintrage gibt es kein Problem. Kann das ein Problem mit der TLS-Aushandlung sein wegen der falschen IP?

Wüsste jetzt nicht direkt was die IP mit TLS bei SMTP zu tun hat
eine kurze Suche nach der Fehlermeldung führt u.A. zu:
https://groups.google.com/g/mailing.postfix.users/c/gTVBKQyd_Ho
Was für ein System scheitert denn beim Mailversand? (wenn es sehr alt ist (insbesondere Exchange), kann das die Ursache für den Fehler sein)

Ich hoffe das hilft!

 

[TobiTobs]

sondern es muss zusätzlich beim internen smtpd (in der master.cf.in) noch 'smtpd_upstream_proxy_protocol ' gesetzt werden:
https://www.postfix.org/postconf.5.html#smtpd_upstream_proxy_protocol

Wenn ich das setze wird zwar die richtige IP im Log angezeigt (vom Downstream-Mailserver), jedoch werden dann keine Mails mehr versandt, sondern bleiben in der Queue stehen

2023-08-07T10:57:01.523905+02:00 mgw02 postfix/smtpd[3108]: connect from mbx01.mail.example.com [148.251.XXX.XXX]
2023-08-07T10:57:01.564405+02:00 mgw02 postfix/smtpd[3108]: 89BAF20BDE: client=mbx01.mail.example.com [148.251.XXX.XXX]
2023-08-07T10:57:01.613956+02:00 mgw02 postfix/cleanup[3131]: 89BAF20BDE: message-id=<Wv6tcxL0oO2YdeACILzJhIcVN8eE4Zqz8tRRyJM@mbx01.mail.example.com >
2023-08-07T10:57:01.616620+02:00 mgw02 postfix/qmgr[3007]: 89BAF20BDE: from=<noreply@domain.de>, size=797, nrcpt=1 (queue active)
2023-08-07T10:57:01.619585+02:00 mgw02 postfix/smtpd[3108]: disconnect from mbx01.mail.example.com [148.251.XXX.XXX] ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1 commands=7
2023-08-07T10:57:06.731688+02:00 mgw02 postfix/lmtp[3132]: 89BAF20BDE: to=<recipient@gmail.com>, relay=127.0.0.1[127.0.0.1]:10023, delay=5.2, delays=0.05/0/0.05/5.1, dsn=4.4.0, status=deferred (host 127.0.0.1[127.0.0.1] said: 451 4.4.0 detected undelivered mail to <recipient@gmail.com> (in reply to end of DATA command))

Ja prinzipiell durchaus - siehe https://www.proxmox.com/en/proxmox-mail-gateway/features#nav-mod-scrollspy433-data4
und damit bleibt auch alles soweit bei euch - einfach bei IP-wechsel die A records zum MX record anpassen.

Ich denke mit der Variante werden wir langfristig weniger Schmerzen haben - wird ja bei eurer proxmox.com Domain auch so benutzt!

 

[Stoiko Ivanov]

Wenn ich das setze wird zwar die richtige IP im Log angezeigt (vom Downstream-Mailserver), jedoch werden dann keine Mails mehr versandt, sondern bleiben in der Queue stehen

bitte mal die ganzen logs von dem zeitraum posten - da sollte sich auch sehen lassen was hier nicht passt.

Wo wurde denn das smtpd_proxy_protocol gesetzt?
(vl. allgemein die postfix config Anpassungen hier mal teilen)

 

[TobiTobs]

Aug 07 10:57:06 mgw02 postfix/smtpd[3109]: warning: ignoring non-empty smtpd_upstream_proxy_protocol setting behind postscreen
Aug 07 10:57:06 mgw02 postfix/smtpd[3109]: connect from mx.mail.example.com [167.235.XXX.XXX]
Aug 07 10:57:06 mgw02 postfix/smtpd[3109]: lost connection after CONNECT from mx.mail.example.com [167.235.XXX.XXX]
Aug 07 10:57:06 mgw02 postfix/smtpd[3109]: disconnect from mx.mail.example.com [167.235.XXX.XXX] commands=0/0
Aug 07 10:57:06 mgw02 postfix/smtpd[3136]: warning: haproxy read: timeout error
Aug 07 10:57:06 mgw02 postfix/smtpd[3136]: connect from localhost.localdomain[127.0.0.1]
Aug 07 10:57:06 mgw02 postfix/smtpd[3136]: disconnect from localhost.localdomain[127.0.0.1] commands=0/0
Aug 07 10:57:06 mgw02 pmg-smtp-filter[922]: unable to connect to localhost at port 10025 at /usr/share/perl5/PMG/Utils.pm line 261.
Aug 07 10:57:06 mgw02 pmg-smtp-filter[922]: 20BDF64D0B1DDA1A32: reinject mail to <recipient@gmail.com> (rule: default-accept) failed
Aug 07 10:57:06 mgw02 pmg-smtp-filter[922]: 20BDF64D0B1DDA1A32: processing time: 5.064 seconds (0, 0.033, 0)
Aug 07 10:57:06 mgw02 postfix/lmtp[3132]: 89BAF20BDE: to=<recipient@gmail.com>, relay=127.0.0.1[127.0.0.1]:10023, delay=5.2, delays=0.05/0/0.05/5.1, dsn=4.4.0, status=deferred (host 127.0.0.1[127.0.0.1] said: 451 4.4.0 detected undelivered mail to <recipient@gmail.com> (in reply to end of DATA command))

Vermute mal das "ignoring non-empty smtpd_upstream_proxy_protocol setting behind postscreen" wird schon der Fehler sein?

In der main.cf.in unter /etc/pmg/templates/ habe ich nur folgende beide Zeilen hinzugefügt

postscreen_upstream_proxy_protocol = haproxy
smtpd_upstream_proxy_protocol = haproxy

 

[Stoiko Ivanov]

In der main.cf.in unter /etc/pmg/templates/ habe ich nur folgende beide Zeilen hinzugefügt

vs.

nicht aus - sondern es muss zusätzlich beim internen smtpd (in der master.cf.in) noch 'smtpd_upstream_proxy_protocol ' gesetzt werden:

sprich mal beim port 26 smtpd listener in der master.cf.in setzen - vielleicht funktioniert das.

 

[TobiTobs]

Sorry, hab die main und master vertauscht. Habe in der master.cf.in folgende Zeile abgeändert/ergänzt

[% pmg.mail.ext_port %]       inet  n -       -       -       1 postscreen -o smtpd_upstream_proxy_protocol=haproxy

und alternativ auch Folgendes:

smtpd       pass  - -       -       -       [% pmg.mail.max_smtpd_in %]      smtpd -o smtpd_upstream_proxy_protocol=haproxy

Das Proxy-Format wird aber nicht akzeptiert, der Log spuckt folgendes aus:

Aug 07 14:26:48 mgw02 postfix/smtpd[12460]: improper command pipelining after CONNECT from mx.mail.example.com[167.235.XXX.XXX]: PROXY TCP4 148.251.XXX.XXX 167.235.XXX.XXX 46672 26\r\n

Noch eine Idee?

 

[Stoiko Ivanov]

orry, hab die main und master vertauscht. Habe in der master.cf.in folgende Zeile abgeändert/ergänzt

[% pmg.mail.ext_port %] inet n - - - 1 postscreen -o smtpd_upstream_proxy_protocol=haproxy

das ist der postscreen listener auf dem externen port - dort muss nichts geändert werden...

nd alternativ auch Folgendes:

smtpd pass - - - - [% pmg.mail.max_smtpd_in %] smtpd -o smtpd_upstream_proxy_protocol=haproxy

ebenfalls der inbound listener...

[% pmg.mail.int_port %]       inet  n -       -       -       [% pmg.mail.max_smtpd_out %]      smtpd
[% IF pmg.mail.before_queue_filtering -%]
  -o smtpd_proxy_filter=127.0.0.1:10023
  -o smtpd_proxy_options=speed_adjust
  -o smtpd_client_connection_count_limit=[% pmg.mail.conn_count_limit div 5 %]
[%- ELSE -%]
  -o content_filter=scan:127.0.0.1:10023
[%- END %]
  -o smtpd_recipient_restrictions=permit_mynetworks,reject_unauth_destination
  -o smtpd_helo_restrictions=
  -o smtpd_client_restrictions=
  -o smtpd_sender_restrictions=

das ist die betreffende definition des outbound listeners auf port 26.
dort unten dran wuerde ich mal

 -o smtpd_upstream_proxy_protocol=haproxy

versuchen....

 

[TobiTobs]

Du hast Recht, intern mit extern verwechselt!

Nach der Änderung sieht es gut aus, wird jetzt alles zugestellt. Danke dir für deine Hilfe!
Allgemein: würdest du das Setup so empfehlen oder doch eher "einfacher" ohne den Loadbalancer?

 

[Stoiko Ivanov]

Allgemein: würdest du das Setup so empfehlen oder doch eher "einfacher" ohne den Loadbalancer?

Wie schon geschrieben - meiner Erfahrung nach funktioniert DNS-round-robin zum SMTP load-balancen recht gut - und bei den größeren Deployments, die ich kenne wurde es public auch so eingesetzt. Der Vorteil ist, dass es keine weitere Komponente gibt, die dann erst recht wieder redundant aufgebaut werden muss (auf einen ganz schnellen Blick bräuchte es bei haproxy keepalived oder ähnliches), bzw. für die Wissen aufgebaut werden muss.

Andererseits, weiß ich nicht ob es bei Euch vielleicht nicht dennoch Sinn macht - und haproxy dürfte schon recht robuste Software sein.

 

[TobiTobs]

Wir nutzen es aktuell nur zur Lastverteilung, das sollte wahrscheinlich per DNS round-robin genauso gut funktionieren - zumal du es ja bei größeren Deployments auch schon so gesehen hast.

Nehme ich mal als Gedankenanstoß mit, danke dir für deine super Unterstützung!