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.

  • Hallo,

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

  • In reply to LuCar Toni:

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

  • In reply to Philipp N.:

    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. 

  • In reply to LuCar Toni:

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

  • In reply to Philipp N.:

    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.

  • In reply to DouglasFoster:

    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. 

  • In reply to LuCar Toni:

    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 Sleep, 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.)

  • In reply to BAlfson:

    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. 

  • In reply to BAlfson:

    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!

  • In reply to BAlfson:

    Isn't it possible anymore to set the smtp_receive_timeout in the exim.conf?

    Where can I change the 5 minutes to something greater?

  • In reply to BAlfson:

    Hi Bob,

    in reply to the TLS thoughts:

    It is not a TLS problem. The issue with data timeout persists even after the sender disabled TLS for the communication to our mail server. I enabled debug mode for the smtp daemon and here is the smtp traffic that was logged from a mail without TLS:

     

    20083 SMTP>> 220 fw.theater-meissen.de ESMTP ready.
    20083 SMTP<< EHLO webserver.hfmdd.de
    20083 SMTP>> 250-fw.theater-meissen.de Hello mail.hfmdd.de [193.175.195.41]
    20083 SMTP<< MAIL FROM:<somebody@hfmdd.de> SIZE=4668 BODY=8BITMIME
    20083 SMTP>> 250 OK
    20083 SMTP<< RCPT TO:<somebody@theater-meissen.de>
    20083 SMTP>> 250 Accepted
    20083 SMTP<< DATA
    20083 SMTP>> 354 Enter message, ending with "." on a line by itself
     
    after 5 minutes:

    20083 SMTP>> 421 fw.theater-meissen.de SMTP incoming data timeout - closing connection.
     
  • In reply to Philipp N.:

    Interesting.  It appears that mail.hfmdd.de is not sending the final . to end the DATA stream.  I've not seen that before!

    MfG - Bob (Bitte auf Deutsch weiterhin.)

  • In reply to BAlfson:

    Ich habe von der Gegenseite die Logs bekommen. Der andere Mailserver sendet den .(dot) zum Beenden der Kommunikation. Dieser kommt jedoch nie bei unserer Firewall an. Ich habe auch schon unseren ISP angerufen. Dieser sagt jedoch "alles gut". :'(

  • In reply to Philipp N.:

    If a reboot doesn't fix this, Sophos Support will need to look at this.

    MfG - Bob (Bitte auf Deutsch weiterhin.)