donderdag 12 april 2012 0:22
Telnet to port 25 Not working
Last week I was helping a good colleague of mine troubleshoot a frustrating problem. She is in the process of merging two companies and one of the first thing they would like to achieve is to directly connect the two mail servers to get traffic running internally.
To achieve this the first step was to get IP connectivity running between the two companies and ping from one mail server to the other. Once this was successful all that needed doing was a quick Telnet from ServerA <=> ServerB on port 25.
Sure enough this failed however not with a connection refused type but the connection seemed to work and than dropped off, so the search was on.
1. First thing to do was check with the network providers and admins on both sides to ensure no ACLS where blocking the traffic. When this came back negative there is only one place to look for this type of issues and that’s on the wire.
2. Fired up wireshark on the ServerB side and ran a little trace for packets on tcp.port==25
The traffic seemed to start normally with the 3-way TCP handshake kicking in with Syn > Syn,ACK > ACK
Clearly we had outgoing and incoming packets on port 25 between the two servers so a simple Layer4 firewall could not be causing the problem.
Looking a bit lower in the trace, however you start seeing Retransmits for the data packet with relative Seq=1 Ack=1 len=21 (Wireshark helps us track sequence numbers by showing relative seq nr’s instead of the actual numbers) coming from ServerB. And a bit lower down the trace you start seeing retransmit request for the Syn,Ack packets coming from ServerA.
This should trigger you mind, the Syn and Syn,Ack packets are flowing from ServerB to ServerA and from ServerA back to ServerB but the first data packet sent from ServerB to ServerA is never ack’ed and ServerA starts retransmitting the Syn,Ack packet (second packet in the trace). Clearly for some reason the third packet of the three way handshake did not register well on ServerA’s side.
The best way to view this type of traffic in wireshark is to use the Flow Graph Statistic tool. This view realy gives you a single birds eye overview of the traffic flow and you realy see the retransmissions following each other.
of course to confirm this issue we needed to trace on the ServerA end of the communication to see if it ever received the 3de handshake Ack packet
Again packets and flow graphs show all. You can clearly see he Syn Packet arrive and then the 3 consecutive Syn,ack packets being sent to ServerB and the final RST packet when no ACK packet is received.
So the summary was easily made:
- Packets where flowing between the two servers, the Ack packet left the ServerB but never arrived on ServerA => the packet must have gotten lost in transit. A call to the network provider resolved this as being a symmetric routing going belly up and sure enough after their intervention the situation was resolved and mail started flowing.