Nach Umstellung auf neuen TCP Proxy keine Zustellung ausgehender Mails mehr

[BenKr]

Hallo zusammen,

Setup:
- 2 NoSpamProxy-Server in HA-Konfiguration in Azure
- Nutzung des TCP Proxy über Konfigurationsdatei
- Ports sind nach außen offen (443, Port 25 wird bekanntermaßen von Azure blockiert)

Ich habe gemäß der Dokumentation versucht, den TCP Proxy auf die neue Variante umzustellen. Das Entfernen aus der Konfigurationsdatei klappt ebenso wie das Absetzen der PowerShell-Befehle.
Sobald ich dies tue, stoppt jedoch die Zustellung externer Mails, sie stehen im Message Tracking dann alle mit dem Status "Delivery Pending". Sobald ich wieder auf die alte Variante zurückschwenke, läuft die Zustellung nach und nach wieder an. Es wirkt so, als könnten die NSP-Server den TCP Proxy nicht erreichen.

Haben wir noch irgendwas beim Setup vergessen oder hat jemand eine Idee, was das sein könnte?

VG
Ben

 

[869288141]

Hallo Ben,

Sobald ich dies tue, stoppt jedoch die Zustellung externer Mails, sie stehen im Message Tracking dann alle mit dem Status "Delivery Pending".

hast du

• Punkt 1 ( Root CA Zertifikat ablegen)
• Punkt 3 (Servername auf outboundproxy.nospamproxy.com ändern)

aus der verlinkten Dokumentation auch durchgeführt?

Es wirkt so, als könnten die NSP-Server den TCP Proxy nicht erreichen.

Kannst du ganz simpel mit dem Powershell cmdlet Test-Netconnection von beiden VMs verifizieren. Klappt das?


Gruß,
Daniel

 

[BenKr]

Hi Daniel,

ja, alle Schritte gemäß Anleitung wurden durchgeführt und geprüft.

Der PowerShell-Test schlägt fehl (TcpTestSucceeded: False). Wir haben jedoch keinerlei Beschränkungen für ausgehenden Netzwerkverkehr auf diesen VM. Es könnte aber auch sein, dass der TCP Proxy nicht auf solche Anfragen reagiert, da die Verbindung mW von NoSpamProxy getunnelt wird (vielleicht sind da noch andere Mechanismen beteiligt?).

VG
Ben

 

[869288141]

Hallo Ben,

Der PowerShell-Test schlägt fehl (TcpTestSucceeded: False).

aus deiner Rückmeldung geht leider nicht hervor, welchen FQDN du verwendet hast. Nachstehend ein Beispiel, damit wir alle vom Gleichen sprechen.

Test-NetConnection -ComputerName "proxy.nospamproxy.com" -Port 443

ComputerName     : proxy.nospamproxy.com
RemoteAddress    : 3.126.187.89
RemotePort       : 443
InterfaceAlias   : Ethernet
SourceAddress    : 192.168.87.78
TcpTestSucceeded : True

Wenn das bei dir nicht funktioniert, blockiert ein Proxy/Firewall den Request. Weil ein TCP Handshake muss funktionieren.

Gruß,
Daniel

 

[BenKr]

Hi,
ich habe den Namen outboundproxy.nospamproxy.com verwendet.

Dann probiere ich es Morgen nochmal mit proxy.nospamproxy.com.

Allerdings ist dieser Eintrag aktuell in der Konfigurationsdatei gesetzt (= alte Konfigurationsvariante). Daher nehme ich an, dass die Verbindung an sich eigentlich passt.

Was ist denn technisch der Unterschied zwischen der Konfiguration in der config-Datei und dem Connector?

VG
Ben

 

[869288141]

Hallo Ben,

Allerdings ist dieser Eintrag aktuell in der Konfigurationsdatei gesetzt (= alte Konfigurationsvariante). Daher nehme ich an, dass die Verbindung an sich eigentlich passt.

das sehe ich von hier aus nicht. Du kannst es aber natürlich gerne ausprobieren. Das Ergebnis kennen wir vermutlich beide schon.
Ich würde an deiner Stelle nun einen Support Case erstellen. Ich bin mit meinem Ideen am Ende.


Gruß,
Daniel