This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Message abandoned bei Mails von bestimmter Domain

Hi Community,

wir haben seit eingier Zeit das Problem, dass Mails von einer bestimmten Domain in ein Timeout beim SMTP-Handling laufen. Zum Einsatz kommt eine SG135 (FW 9.510-5) als SMTp-Proxy konfiguriert.

SMTP-Proxy Log:

 

SMTP connection from [192.175.195.41]:54072 (TCP/IP connection count = 1)

... H=mail.hfmdd.de (webserver.hfmdd.de) [193.175.195.41]:54072 Warning: theater-meissen.de profile excludes SANDBOX scan

 

Einige Minuten später dann:

 

... SMTP data timeout (message abandoned) on connection from mail.hfmdd.de (webserver.hfmdd.de) [193.175.195.41]:53650 some.body@hfmdd.de

 

Zur Zeit des SMTP timeouts zeigt das Firewall Log dies:

 

2018:09:28-11:51:14 fw ulogd[7772]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60003" outitf="eth1" srcmac="00:1a:8c:6e:e1:19" srcip="192.168.1.250" dstip="193.175.195.41" proto="6" length="64" tos="0x00" prec="0x00" ttl="64" srcport="25" dstport="48886" tcpflags="ACK FIN"

 

Das Komische daran ist, dass vom external Interface (192.168.1.250) aus versucht wird, über Port 25 nach außen zu kommunizieren.

Ein TLS-Check des Senders auf unseren MX-Eintrag sagt "unable to get local issuer certificate, unable to verify the first certificate, Email is encrypted but recipient domain is not verified".

Im Log des Sender steht: 

 

timed out while sending email body

 

Hat jemand eine Idee? Ich bin mittlerweile ratlos, da es nur bei diesem Absender zu den Problemen kommt.



This thread was automatically locked due to age.
  • Hallo,

    bitte mal den IPS Log überprüfen. Das könnte die IPS oder ATP sein, die anschlägt und den Data Part killt. 

    __________________________________________________________________________________________________________________

  • ATP Logs sind leer und IPS Log des betroffenen Tages zeigt keine Drops an.

  • Ist das logging der IPS aktiv? 

    Also für mich klingt es so, als würde etwas den Datenstream killen. Und das wäre entweder die IPS der Appliance oder etwas zwischen dem Sender und der SG. 

    Mit einem Dump könnte man auf der Appliance wenigstens belegen, woran es liegt, bzw. sagen es liegt nicht an der SG. 

    __________________________________________________________________________________________________________________

  • Hm, ein tcpdump ist eine gute Idee. Werde ich mal durchführen und das Ergebnis hier posten.

  • Here is what I have about the built-in firewall rules:

    • 60001 Input Default Drop
    • 60002 Forward Default Drop
    • 60003 Output Default Drop

    I am not sure why the packet is being dropped during output processing unless:

    • The target machine mail server is misconfigured and consequently not reachable.
    • The target mail server is refusing to respond to verification lookups.

    I don't think UTM does any certificate verification, so CRL checks do not seem like a possible cause.

  • The Point is. 

    You build up a SMTP Transmission (Handshake). 

    If you miss the data part or at least nothing will come, UTM will try to kill this connection. Seems like this "packet" is dropped.

    2018:09:28-11:51:14 fw ulogd[7772]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60003" outitf="eth1" srcmac="00:1a:8c:6e:e1:19" srcip="192.168.1.250" dstip="193.175.195.41" proto="6" length="64" tos="0x00" prec="0x00" ttl="64" srcport="25" dstport="48886" tcpflags="ACK FIN"

     

    Look at the TCPFlag. 

    __________________________________________________________________________________________________________________

  • tcpdump:

     

    15:38:49.239341 In ec:1a:59:52:0b:78 ethertype IPv4 (0x0800), length 76: 193.175.195.41.55448 > 192.168.1.250.25: Flags [S], seq 2732048263, win 29200, options [mss 1460,sackOK,TS val 416004128 ecr 0,nop,wscale 7], length 0
    15:38:49.239883 Out 00:1a:8c:6e:e1:19 ethertype IPv4 (0x0800), length 76: 192.168.1.250.25 > 193.175.195.41.55448: Flags [S.], seq 3373316231, ack 2732048264, win 28960, options [mss 1460,sackOK,TS val 84649833 ecr 416004128,nop,wscale 7], length 0
    15:38:49.272187 In ec:1a:59:52:0b:78 ethertype IPv4 (0x0800), length 68: 193.175.195.41.55448 > 192.168.1.250.25: Flags [.],ack 1, win 229, options [nop,nop,TS val 416004136 ecr 84649833], length 0
    15:38:49.274948 Out 00:1a:8c:6e:e1:19 ethertype IPv4 (0x0800), length 108: 192.168.1.250.25 > 193.175.195.41.55448: Flags [P.], seq 1:41, ack 1, win 227, options [nop,nop,TS val 84649842 ecr 416004136], length 40
    15:38:49.306744 In ec:1a:59:52:0b:78 ethertype IPv4 (0x0800), length 68: 193.175.195.41.55448 > 192.168.1.250.25: Flags [.],ack 41, win 229, options [nop,nop,TS val 416004145 ecr 84649842], length 0
    15:38:49.307624 In ec:1a:59:52:0b:78 ethertype IPv4 (0x0800), length 93: 193.175.195.41.55448 > 192.168.1.250.25: Flags [P.], seq 1:26, ack 41, win 229, options [nop,nop,TS val 416004145 ecr 84649842], length 25
    15:38:49.307847 Out 00:1a:8c:6e:e1:19 ethertype IPv4 (0x0800), length 68: 192.168.1.250.25 > 193.175.195.41.55448: Flags [.],ack 26, win 227, options [nop,nop,TS val 84649850 ecr 416004145], length 0
    15:38:49.308155 Out 00:1a:8c:6e:e1:19 ethertype IPv4 (0x0800), length 205: 192.168.1.250.25 > 193.175.195.41.55448: Flags [P.], seq 41:178, ack 26, win 227, options [nop,nop,TS val 84649850 ecr 416004145], length 137
    15:38:49.341506 In ec:1a:59:52:0b:78 ethertype IPv4 (0x0800), length 174: 193.175.195.41.55448 > 192.168.1.250.25: Flags [P.], seq 26:132, ack 178, win 237, options [nop,nop,TS val 416004153 ecr 84649850], length 106
    15:38:49.377916 Out 00:1a:8c:6e:e1:19 ethertype IPv4 (0x0800), length 68: 192.168.1.250.25 > 193.175.195.41.55448: Flags [.],ack 132, win 227, options [nop,nop,TS val 84649868 ecr 416004153], length 0
    15:38:49.444015 Out 00:1a:8c:6e:e1:19 ethertype IPv4 (0x0800), length 146: 192.168.1.250.25 > 193.175.195.41.55448: Flags [P.], seq 178:256, ack 132, win 227, options [nop,nop,TS val 84649884 ecr 416004153], length 78
    15:38:49.477182 In ec:1a:59:52:0b:78 ethertype IPv4 (0x0800), length 799: 193.175.195.41.55448 > 192.168.1.250.25: Flags [P.], seq 3028:3759, ack 256, win 237, options [nop,nop,TS val 416004187 ecr 84649884], length 731
    15:38:49.477553 Out 00:1a:8c:6e:e1:19 ethertype IPv4 (0x0800), length 80: 192.168.1.250.25 > 193.175.195.41.55448: Flags [.],ack 132, win 238, options [nop,nop,TS val 84649892 ecr 416004153,nop,nop,sack 1 {3028:3759}], length 0

     

    Danach ist Funkstille. Der Drop in der Firewall kommt erst ein paar Minuten später. Sieht so aus, als ob es nicht an unserem Netz liegt, dass die TCP-Verbindung nicht weitergeführt wird. Oder wie seht ihr das?

     

    PS: Kann man Log und Code-Zeilen in dem Editor hier irgendwie sinnvoll formatieren?

  • Hallo Philipp,

    Erstmal herzlich willkommen hier in der Community !

    (Sorry, my German-speaking brain isn't creating thoughts at the moment.  )

    mail.hfmdd.de uses TLS 1.2.  The tool I use to see that isn't working with theater.Meissen.de.  Check that you have selected "TLS v1.2" on the 'Advanced' tab.

    Like you, I suspect a problem with your certificate. Try changing the 'TLS certificate' - also, if it has a different host name, change that in 'Advanced Settings' further down the page.  Any luck?

    MfG - Bob (Bitte auf Deutsch weiterhin.)

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Sorry - Du kannst den Dump wegspeichern.

    tcpdump -w /home/login/dump.pcap 

    Dann mit SCP herunterladen und in Wireshark eröffnen. 

    Es scheint mir jedoch so, als würde die Kommunikation einfach aufhören. Und dann wir die Verbindung abgebrochen. 

    __________________________________________________________________________________________________________________

  • Hallo Balfson,

    Ich die TLS-Einstellung im Advanced-Tab der SMTP-Proxy Einstellungen stand auf "TLS v1 or higher". Eine Umstellung auf "TLS v1.2" brachte keine Änderung.

    Als TLS-Zertifikat wird zur Zeit das Webadmin-Zertifikat genutzt und ist für fw.theater-meissen.de ausgestellt. Dies ist auch der SMTP-Hostname. Für einen Wechsel des Zertifikats hätte ich noch das admin user cert, client auth cert und local x509 cert zur Auswahl, jedoch bezweifle ich, dass sich da was am Problem ändert. Ein öffentlich ausgestelltes SSL-Zertifikat für unsere Domain/ den Mail-Host besitzen wir nicht.

    Vielen Dank an alle für die bisherige Unterstützung!