Nach Update auf 15.4 - Proxy muss neu konfiguriert werden

[Tim321]

Hi,

ich habe das Update auf 15.4 gemacht, nun bekomme ich die Meldung



ein Klick auf "Dokumentation" fördert dann folgendes zutage:



Was bestenfalls ein Hinweis, aber, zumindest für mich, keine Hilfe ist.

Außerdem habe ich folgende Fehlermeldung in der Ereignisanzeige

Ereigniskennung 1, enQsig Web Portal

An unexpected error occurred in the controller Account, action LogOn: Value cannot be null.
Parameter name: array


Message:
Value cannot be null.
Parameter name: array
Error type:
System.ArgumentNullException

Error code: 2147500035
Program location:
at System.ArraySegment`1..ctor(T[] array)
at Netatwork.NoSpamProxy.Security.SecureDataService.DecryptAndAuthenticateWithoutPasswordGeneration(Byte[] input, Byte[] statePassword)
at Netatwork.NoSpamProxy.WebPortal.EncryptedFileId.DecryptDataWithFallback(Byte[] encryptedData, ISecureDataService secureDataService)
at Netatwork.NoSpamProxy.WebPortal.EncryptedFileId..ctor(Byte[] data, ISecureDataService secureDataService)
at Portal.Controllers.AccountController.LogOn(String id)
at lambda_method(Closure , ControllerBase , Object[] )
at System.Web.Mvc.ControllerActionInvoker.InvokeActionMethod(ControllerContext controllerContext, ActionDescriptor actionDescriptor, IDictionary`2 parameters)
at System.Web.Mvc.Async.AsyncControllerActionInvoker.<>c.<BeginInvokeSynchronousActionMethod>b__9_0(IAsyncResult asyncResult, ActionInvocation innerInvokeState)
at System.Web.Mvc.Async.AsyncResultWrapper.WrappedAsyncResult`2.CallEndDelegate(IAsyncResult asyncResult)
at System.Web.Mvc.Async.AsyncControllerActionInvoker.EndInvokeActionMethod(IAsyncResult asyncResult)
at System.Web.Mvc.Async.AsyncControllerActionInvoker.AsyncInvocationWithFilters.<>c__DisplayClass11_0.<InvokeActionMethodFilterAsynchronouslyRecursive>b__0()
at System.Web.Mvc.Async.AsyncControllerActionInvoker.AsyncInvocationWithFilters.<>c__DisplayClass11_2.<InvokeActionMethodFilterAsynchronouslyRecursive>b__2()
at System.Web.Mvc.Async.AsyncControllerActionInvoker.AsyncInvocationWithFilters.<>c__DisplayClass11_2.<InvokeActionMethodFilterAsynchronouslyRecursive>b__2()
at System.Web.Mvc.Async.AsyncControllerActionInvoker.EndInvokeActionMethodWithFilters(IAsyncResult asyncResult)
at System.Web.Mvc.Async.AsyncControllerActionInvoker.<>c__DisplayClass3_5.<BeginInvokeAction>b__4()
at System.Web.Mvc.Async.AsyncControllerActionInvoker.<>c__DisplayClass3_0.<BeginInvokeAction>b__1(IAsyncResult asyncResult)


Weder mit dem Einen noch dem Anderen kann ich irgendwas anfangen. Kann mir jemand weiterhelfen bzw. kennt die Lösung?

 

[StefanCink]

Bzgl. des TCP Proxy-Eintrags nutze bitte diese Beschreibung hier. https://docs.nospamproxy.com/Server...xy-on-a-cloud-service.htm?Highlight=tcp proxy
Dort ist genau beschrieben, wie der Eintrag in der Konfig-Datei aussehen muss.
Bzgl der Fehlermeldung warte ich mal auf den Input der Kollegen.
Gruß Stefan

 

[JanJäschke]

Behalte deine TCP Proxy Konfiguration erstmal bei, die Konfiguration bleibt vorerst gültig, musst dir also nicht umgehend sorgen machen.
Da ist die Doku anscheinend noch nicht aktuell, danke für den Hinweis
Wenn diese aktualisiert ist kannst du entsprechen die Änderung vornehmen

 

[Tim321]

Diese Einstellungen waren bei mir bereits vorhanden. Nachdem ich nun das Zertifikat in den Vertrauenswürdigen Speicher geladen habe, ist die Fehlermeldung für den TCP-Proxy weg.

 

[869288141]

Diese Einstellungen waren bei mir bereits vorhanden. Nachdem ich nun das Zertifikat in den Vertrauenswürdigen Speicher geladen habe, ist die Fehlermeldung für den TCP-Proxy weg.

Habt ihr einen Outbound Proxy mit SSL/TKS Inspection/Interception im Einsatz?

 

[Tim321]

Habt ihr einen Outbound Proxy mit SSL/TKS Inspection/Interception im Einsatz?

Nein, eine "Standardinstallation" von NSP auf einem Azure-Server

 

[869288141]

Hm. Was hat es dann mit dem TCP Proxy auf sich? @JanJäschke, @StefanCink

 

[StefanCink]

Das ist eine Möglichkeit, um das Problem zu lösen, dass die IP-Adressen von Azure nicht gut für den E-Mail-Versand geeignet sind (aufgrund der schlechten IP-Reputation) und der Port 25 ausgehend immer gesperrt ist in Azure. Wir betreiben mit dem TCP Proxy eine Infrastruktur die vom Gateway aus über 443 erreicht wird und wir tunneln auf TCP-Ebene dann den SMTP Strom weiter auf den Port 25 des Zielhosts. Dieser sieht unsere IP als absendende IP aber der einliefernde NoSPamProxy hat eine direkte TCP Verbindung dorthin.

 

[869288141]

Danke für die Erklärung Stefan. Allerdings habe ich nun Gänsehaut...

 

[StefanCink]

Weil?

 

[JanJäschke]

Vlt noch zur Ergänzung:
Wir tunneln hier zu 100%.
Das heißt sobald der NSP TLS zum Ziel Server des Empfängers macht können wir auch nichts mehr vom Traffic sehen.
Die Verbindung wird also nicht aufgebrochen und wir sind auch kein Hop.
Plaintext ist natürlich etwas anderes aber dieser Umstand sollte jedem Bewusst sein wenn er diesen Service nutzt.
Bei TLS sehen wir also sogar weniger von einer E-Mail als die NoSpamProxy Instanz bei unseren NoSpamProxy Cloud Kunden. (Wir lesen ja auch da nicht mit )

Ich kann nur ergänzend sagen, dass die TCP Proxy Systeme sehr stark abgeschottet sind.
Auf die Instanzen kann kein Kollege bei uns im Haus einfach so zugreifen und Code Seitig findet keinerlei Logging des Verbindunginhalts statt.


Beste Grüße,
Jan

 

[869288141]

Hallo Stefan,
hallo Jan,

Weil?

es sind mehrere Themen, die nichts mit der Frage zu tun habe. Evtl. könnt ihr das in einen eigenen Beitrag auslagern.

• Warum hostet man eine NSP Instanz in Azure wenn man weiß, dass
  • die Reputation der Subnetze/AS bekanntlich schlecht ist.
  • der technische Support (Basis) im Vergleich zu anderen Cloud Anbietern oftmals unterirdisch ist.
  • ausgehenden Port 25/tcp gesperrt ist und nur auf explizite Nachfrage freigeschaltet wird (letzteres bin ich mir nicht sicher)
• Die Komplexität der Mail Plattform nimmt deutlich zu. Zumal ich mit dem TCP Proxy neben NSP noch eine weitere Blackbox habe. D.h. bei einer möglichen Fehlersuche bin mehr den je auf euch angewiesen. Und wie Jan es bestätigt hat, ad-hoc auch kein Zugriff möglich ist.
• Jan kann wohl meine Gedanken lesen... was langsam etwas unheimlich wird.

Aber vllt. werde ich einfach nur alt und verstehe die heutigen Trends nicht...

Ich kann nur ergänzend sagen, dass die TCP Proxy Systeme sehr stark abgeschottet sind.

Das letzte Mal als ich den Satz von einem Hersteller gehört habe, habe ich ein Jahr später dessen Produkt bei uns für immer verbannt. Was ich damit sagen möchte ist, dass muss heute Standard sein. Genauso dass die Abschottung/Sicherheit kontinuierlich geprüft, hinterfragt und verbessert wird.


Gruß,
Daniel