Cisco ASA Syn timeout


   I've been wondering.

I keep getting syn timeout from the ASA logs when I try to reach a dmz network from the outside.

I have to ASA... It's actually a site-to-site VPN that's reaching the first ASA - on this one, I get, when i do the packet tracer " ipsec spoof packet" in the end at the Result.

I see in the log the TCP connection that being sent to the second ASA through an interconnection. Afterwards I see the TCP handshake like. syn sent to a Dmz interface and that is it and after 30 seocnds I only get Syn timeout.

I don't know what I can do with this problem.

I asked my system engineer to give me a tcp dump on both his server interfaces because I was suspecting the server reply would live though a different interface.

Unfortunately, all I could see from the dump through wireshark is .. syn sent to the server.. and nothing else.

I am not natting my requests. They come from the opposite site as is. The encryption domains are good - so are the SA.

no idea, no idea.

i mean, I should be able to see a deny or a drop or get some words from the ASA! Or else i asked my system engineer to drop all his iptables.

nothing else.

pain in the ass! :D
Who is Participating?
Syn timeout means that your source tries to establish a tcp session, sends a TCP SYN packet as the first packet, but no reply is received by the ASA. Generally this is because the end node is either blocking the packet or does not know how to route it. I always use packet capture to make sure which packets are exactly passing the ASA interface.
setup capture as follows:

lets assume the target server has ip address and it is located on interface inside, then capture setup would be as follows:

conf t
access-list capsyn permit ip any host
access-list capsyn permit ip host any

cap syncap interface inside access-list capsyn

then after some time, check the contents of the captur as follows

show cap syncap
Hi, yes check your capture log, and post your access-lists by doing a: sh run access-l

Be sure they are sanitized.  More than likely you just don't have an ACL to allow traffic in the DMZ interface from the outside interface.

There would be no reason for a route, but since your outside interface would most likely be of a lower security level than that of the DMZ interface (which it probably should be) then you would need to create an ACL and then bind it to the DMZ interface inbound like so:

access-list outside_in_DMZ permit ip host any host DMZ_SERVER_IP_HOSTname eq 80

then the access-group to bind it to the DMZ interface:
access-group outside_in_DMZ in interface DMZ

I used port 80 as an example, but it could be anything like telnet, ssh, ftp, etc.

Hi there, everything ok on this?  Just checking your status.

cheops01Author Commented:
The problem was indeed on the server side.

The system engineer found the problem.

Thank you very much
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.