frame 1 [syn] -> frame 2 [rst, ack] on port 25 of remote server

asked 2019-04-03 13:43:59 +0000

dogwood
1 ●2 ●1

My postfix smtp server suddenly stopped working for no apparent reason. I now find that I am getting a [rst, ack] packet back after the initial [syn] packet.

I'm trying to connect to port 25 on the remote server. This affects all outbound mail. I've checked all postfix configs, all inbound and local email works, dns and rdns all configured correctly, not on any blacklists and I don't relay through another server. I can understand one server not wanting to respond but I'm completely baffled. I can't see that all mail servers would deny access on port 25.

edit retag flag offensive close merge delete

Comments

Is your server a private one in your home\office connected to the Internet via an ISP? If so, it's likely that your ISP is blocking port 25 connections.

grahamb ( 2019-04-03 14:13:24 +0000 )edit

Yes, I'm on a home network and No I don't think they are. I am on a fixed ip addr (zen.co.uk) and they tell me that they don't block ports (apart from 2 related to xbox live).

This appeared in my mail log:eur.olc.protection.outlook.com[104.47.13.33]:25 Connection refused. That is just one example, another is alt4.gmail-smtp-in.l.google.com[74.125.195.26]:25: Connection refused. They all respond the same way with a [rst, ack]. I have the traces for those connections so I'm sure they are hittng the relevant servers.

dogwood ( 2019-04-03 14:36:13 +0000 )edit

add a comment

2 Answers

Sort by » oldest newest most voted

answered 2019-04-03 18:37:47 +0000

grahamb

flag of United Kingdom of Great Britain and Northern Ireland

23835 ●4 ●974 ●227 https://www.wireshark.org

From your capture, the connection attempt is definitely being reset, the question is who is doing it? As the TTL on the received packet is 63, I suspect the sender is only 1 hop away, i.e. your just the other side of the upstream connection from your email server.

edit flag offensive delete link

Comments

Yes, there is my network -> my isp network -> the world. Are the remote destination ip addrs the actual mail servers or are they routers or some other intermediate server that might be binning the connection?

dogwood ( 2019-04-03 19:18:47 +0000 )edit

"Are the remote destination ip addrs the actual mail servers or are they routers or some other intermediate server that might be binning the connection?"

The IP addresses should be the addresses of the actual mail servers. However, the RST/ACK packets are very likely coming from some other device that is spoofing the addresses of the mail servers. I agree with @grahamb that this device is probably only one hop away, based on the TTL. Also notice that the RST/ACK packets come back in only 0.3 milliseconds, which is further evidence that the device is very close.

My guess: Your ISP is (now) blocking port 25, regardless of what they say.

Jim Aragon ( 2019-04-03 20:23:00 +0000 )edit

Ok, here's a traceroute to what we're told is google's mail server:

traceroute alt4.gmail-smtp-in.l.google.com
traceroute to alt4.gmail-smtp-in.l.google.com (74.125.195.26), 30 hops max, 60 byte packets
 1  192.168.178.1 (192.168.178.1)  0.334 ms  0.484 ms  0.562 ms
 2  vt1.cor2.lond2.ptn.zen.net.uk (51.148.72.24)  15.418 ms  15.778 ms  15.953 ms
 3  ae-7.cor2.lond1.ptn.zen.net.uk (51.148.73.12)  122.952 ms  122.930 ms  123.025 ms
 4  * * *
 5  72.14.217.190 (72.14.217.190)  19.645 ms  20.248 ms  26.841 ms
 6  108.170.246.144 (108.170.246.144)  21.055 ms 74.125.242.115 (74.125.242.115)  16.836 ms 74.125.242.114 (74.125.242.114)  16.945 ...

(more)

dogwood ( 2019-04-03 20:37:51 +0000 )edit

"So by what you are saying I would expect a TTL of 42 if I was getting a [rst, ack] from the actual server, thereby further supporting your theory that it's my ISP blocking port 25. Does that make sense?"

That depends on the starting TTL. The initial TTL is set by the operating system (although it can be overridden by applications), so usually all packets leaving a device will have the same starting TTL. There are certain starting TTL values that are common: 32 (not so much any more), 60, 64, 128, and 255. The TTL will be decremented by one by each router that the packet passes through. (The actual rule is more complex, but that's what usually happens.) So a packet that arrives with a TTL of 63 probably started with an initial TTL of 64 and went through one router. If it started at ...(more)

Jim Aragon ( 2019-04-04 06:52:11 +0000 )edit

Ok, if we were playing nearest the bullseye then I think @grahamb would be the winner. I watched a video on TCP by Chris Greer that explained some of the fundamentals of TCP and hop count was one of the things he covered.

So going on the fact that the TTL was 63 for the [rst, ack] and the RTT was 3 microseconds pointed to...........MY OWN ROUTER. I haven't changed a thing on this router other than to close some ports for some time, so I start grubbing around as you do and lo and behold there is a filter that blocks outbound email on port 25. This option is a check box and does not appear in any acl or filter list, so I'm guessing all outbound connections are allowed by default (except port 25). Why it suddenly started to block port 25 I don't ...(more)

dogwood ( 2019-04-04 09:25:44 +0000 )edit

see more comments

answered 2019-04-03 14:55:23 +0000

Ross Jacobs
71 ●3 ●32 ●13

Take a packet capture on your remote server while you try to connect on port 25. It's possible to take a remote ssh capture if you have tcpdump installed on the server and then save it locally (something like this).

Then once you have the capture, search for your IP address and the RST/ACK frame. The filter will be something lie this:

$PUBLIC_IP = [the public IP you are accessing from]
ip.dst==$PUBLIC_IP and tcp.flags.ack and tcp.flags.rst

If you see traffic on this filter, that means that your server does not want to connect (and start doing server-side troubleshooting). On the other hand, if you see these RST/ACKs on your accessing computer but not the remote server, you should talk to your ISP.

edit flag offensive delete link

Comments

That's not possible. My smtp server is on my home network and I don't have access to any remote mail servers. How can I submit a capture file to show what's happening?

dogwood ( 2019-04-03 15:58:39 +0000 )edit

Just as clarificaion this is an smtp server to smtp server issue rather than an email client to server issue

dogwood ( 2019-04-03 16:18:51 +0000 )edit

Capture on your smtp server, filtering port 25, and then post the capture on a public share (Google Drive, DropBox etc.) and edit your question (or add a comment to it) with a link to the capture.

grahamb ( 2019-04-03 16:41:14 +0000 )edit

Just added link to dropbox - https://www.dropbox.com/s/6b9wuuhe6ml...

dogwood ( 2019-04-03 17:43:59 +0000 )edit

add a comment

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

frame 1 [syn] -> frame 2 [rst, ack] on port 25 of remote server

Comments

2 Answers

Comments

Comments

Your Answer

Question Tools

Stats

Related questions

frame 1 [syn] -> frame 2 [rst, ack] on port 25 of remote server edit

Comments

2 Answers

Comments

Comments

Your Answer

Question Tools

Stats

Related questions

frame 1 [syn] -> frame 2 [rst, ack] on port 25 of remote server