after tcp handshake done, no packets can be receieved on each other side,why??

Dear Experts,
Now, i have experienced one issue of smtp sending mail via outlook express.
The email server is linux, and resides behind firewall, the outlook express client also lives behind a firewall.
I caught the packets both on client and server side.
It shows that after tcp handshaking, none of tcp packets can be received from each other any more. It is very strange. Client is sending tcp ack, server side is resending syn/ack again and again.
Can you give me an idea how to figure it out?
I paste the packet trace here for your information.
Please unzip it and change the .doc to .pcap and open it with wireshark.
Who is Participating?

Improve company productivity with a Business Account.Sign Up

giltjrConnect With a Mentor Commented:
The client did receive everything that the server sent.  There is no final ACK, the next packet that should flow from the server is the SMTP 220 welcome message.

There are only 3 packets that flow in a handshake.

SYN from client to server
SYN,ACK from server to client
ACK from client to server.

So if you did the capture on the server, then there is something higher up than the NIC that is dropping/blocking the incoming ACK from the client.
I'm going to guess that your email server has iptables running. Try disabling iptables temporarily and see if the packets make it through after that.

iptables is notorious for causing bizarre TCP behavior if it's not configured properly.
matiascxAuthor Commented:
Dear gr8gonzo,
Thanks for your quick response.
The iptables is off. I have double checked it.
What is more, the client and server can talk to each other in the packet i caught.
The strange thing is after tcp seems setup, no packets can be received on each side any more, that is the problem.
[root@ip-10-136-13-206 ~]# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination        

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination        

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination        
[root@ip-10-136-13-206 ~]# chkconfig  |grep iptables
iptables        0:off   1:off   2:off   3:off   4:off   5:off   6:off
[root@ip-10-136-13-206 ~]#
What Kind of Coding Program is Right for You?

There are many ways to learn to code these days. From coding bootcamps like Flatiron School to online courses to totally free beginner resources. The best way to learn to code depends on many factors, but the most important one is you. See what course is best for you.

Have you disabled the client-side firewall?

Any hardware firewalls/routers that have security features?
Also, are you on a home internet connection, like Verizon FIOS or Cox Cable? Sometimes home internet providers will block SMTP sending unless it goes through their own SMTP server.
matiascxAuthor Commented:
Dear gr8gonzo,
The client side should work well. Becuase when i use another email account on another server. It works well.

Please know about that.

What is more, when I change another networking environment , it is the same.
I think, the problem should be on the server side which i currently do not know.

Best Regards,
Changing the network environment won't always fix the problem, if the new environment also has the same problem. Unless you're in an environment that you know 100% for sure does not restrict outbound SMTP...

Also, some mail accounts on other servers can work fine - it depends on the server. For example, from my home PC, I cannot connect to my own server on port 25 (because of my ISP's restriction), but I can connect to GMail's SMTP server on port 465 (secure SMTP).

Don't assume things ARE working well just because they SHOULD be working well. When things SHOULD be working well, they usually are, but sometimes the most mysterious problems are in the unexpected exceptions.
matiascxAuthor Commented:
Yes. In fact, the server is an EC2 instance. When I change to other ec2 instance in the same subnet environment. The server also works well. So it should not be issues on client side, or ISP block the smtp issue. It should be server configuration issue.
The work server is centos, while the not work server is red hat enterprise linux.

Please know that.
Was the capture on the server side done directly on the server?

The server is acting as if it never received the final ACK in the 3-way handshake.

If you look the the server side capture the server:

received a SYN request
sent SYN, ACK reqeust
received ACK
resent SYN,ACK over and over.

So somehow it appears something may be blocking the final ACK in the handshake.
matiascxAuthor Commented:
Dear giltjr,
Thanks for your investigation.
Yes, that is what i am willing to figure out.
It seems server side does not receive the ack from server side packets.
From the client side, the client also does not receive the final handshake ack from server side.
It is very strange.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.