Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 27 subscribers
  • Views 11902 views
  • Users 0 members are here
Options
Suggested
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

Invalid TCP RST. Mails from one IP address would not come in. Showing Invalid TCP RST every ten minutes.

Big_Buck

We have Symantec Brigthmail Mail Gateway.  No DNAT rule SMTP in allowed to that appliance.

Mails from some customer would not show up in Exchange - obviously - and not on the Mail gateway.

 

Any clue ?



This thread was automatically locked due to age.
  • 0

    Can you explain the mail flow? 

    Maybe IPS, ATP is blocking the mail. 

  • 0 in reply to LuCar Toni

    Customer is somewhere in the USA.

    I believe he is using Office 365.  His account ends with outlook.com.

    He send mails to mail.granicor.com, which onced NATed is a Symantec Brigthmail Mail Gateway appliance.

    I have a very simple inbound NAT rule.

     

    Paul Jr

  • 0 in reply to Big_Buck

    The problem is, Email communication includes 2 people. 

    So basically you should do a tcpdump while somebody is sending you a mail.

    tcpdump -ni any port 25 

    Should be enough. At the current state, i am not able to see any issue on XG. 

     

    *edit* 

    i am betting the RST drops in logviewer are because the Mail gateway is refusing the mail and sending multiple RST packets. 

     

  • 0 in reply to LuCar Toni

    Hello ManBearPig

     

    The problem is ... the mail gateway (antispam or whatever else name we can call it) NEVER sees request from that particular IP address.  Let's start.  The customer mail is mbushert@wilsonarch.com.  I received 3 mails from him.  But I should have received maybe 20.  A screen shot at the log in Symantec Brigthmail gives this: 

    In other words, "list all mails received from senders containing "wilsonarch" in their e-mail since 2008.  I get this report:

    Accept From Accept Time Message ID Sender Recipient Subject Scanner Actions Deliver Time
    63.128.21.176 Monday, Jul 30, 2018 10:04:16 AM EDT <bl0pr12mb24996a0644cd676cbe31a779af2f0@bl0pr12mb2499.namprd12.prod.outlook.com> mbushert@wilsonarch.com vedran.vanic@granicor.com re: cad files Deliver message normally Monday, Jul 30, 2018 10:04:35 AM EDT
    216.205.24.176 Saturday, Jul 28, 2018 10:46:28 AM EDT <bl0pr12mb249989e6751772124400b868af2a0@bl0pr12mb2499.namprd12.prod.outlook.com> mbushert@wilsonarch.com vedran.vanic@granicor.com re: cad files Deliver message normally Saturday, Jul 28, 2018 10:46:46 AM EDT
    216.205.24.176 Thursday, Jul 26, 2018 04:53:14 PM EDT <bl0pr12mb24990d5505c120ffa0752bb7af2b0@bl0pr12mb2499.namprd12.prod.outlook.com> mbushert@wilsonarch.com vedran.vanic@granicor.com re: cad files Deliver message normally Thursday, Jul 26, 2018 04:53:16 PM EDT

    It may be a moving target, but lets say I received mail from IP 63.128.21.176 and IP 216.205.24.176.  In Sophos XG logs I get this:

    ... and this ...

    And this:

    Sophos XG says it is forwarding towards Symantec Brigthmail valid IP adress 207.134.161.13.  But Brigthmail says it receives nothing from those address.  At least, nothing with "wilsonarch" in the mail address.  We also see "Invalid TCP RST" every 10 minutes for both addresses.  If Brigthmail had dropped anything, it would tell, and for what reasons.

     

    Paul Jr

  • 0 in reply to Big_Buck

    What's rejected by the MTA are mails with no "from"or "to".  A search from IP address 216.205.24.176 instead of email name gives this:

    A search from the other ip 63.128.21.176 gives the same result. Most likely those mails without "from" and "to" originate from our customer.

    Paul Jr

  • 0 in reply to Big_Buck

    Tested with Checkpoint yesterday.  It works.  So these "Invalid TCP RST" coupled with Symantec's Connection classification may be mutually allergic after all ...

    Some reading about Symantec Connection classification: https://support.symantec.com/en_US/article.HOWTO53532.html  and https://www.symantec.com/connect/forums/high-connection-classification-bad-reputation-count

    Paul Jr Robitaille

  • 0 in reply to Big_Buck

    Hi,

    sorry forgot to respond.

    Would lovely to see a dump of those connections. 

     

  • 0 in reply to LuCar Toni

    Hello

    I am not sure how to dump it ... First because on the WEB interface TCP dump are quite short.  They last few hundreds of KB.  So, I will need to do it in CLI.  But then, I'll need a cook-up CLI command tailored to catch traffic from few IP addresses only, otherwise the TCP dump will get horribly huge ...  I'll need to have this command active for many hours.  I do not have much control over that particular client.  He is very hard to catch over the phone ...  And not that cooperative ...

    I'm totally rusted at CLI.

    Paul Jr 

  • 0 in reply to Big_Buck

    You should do the dump in the background for many "hours" running.

    Just need to know how to tailor the command. 

    would be something like:

    tcpdump -ni any port 25 and host Sender_IP -b -w /tmp/dump.pcap 

    (to explain this: it will dump on any interface and write all matched packets, which hits the sender IP and port 25 into a PCAP on /tmp/dump.pcap.)

    If you keep up the SSH session, this command will run without any output on shell itself. 

    But if you get the sender finally on the phone and resend the mail, you can stop the command with STRG + C.

    Afterwards copy the file to your windows machine with PSCP. (putty scp: Windows Command: C:\pscp.exe -scp admin@172.16.16.16:/tmp/dump.pcap C:\    <-- Alter this paths as you need)

    https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html 

    PSCP = Putty SCP = https://en.wikipedia.org/wiki/Secure_copy

    And open this pcap with wireshark, which is nice to read. 

    Now you should be able to post me (DM) the Screenshot of the file. Basically we should be able to see everything, which is going on in the SMTP Handshake. 

    Make sure, you dont have any SNAT to the Server (In your Case Full NAT = Rewrite Source Address in the DNAT rule).

  • 0 in reply to LuCar Toni

    I will go tru this this week end.  Stay tuned.